ML and relpatseht, thanks for looking that up. Nice to know it has multi-threaded capability as well. Maybe I'll try to build a game with it some time in the future.

I'm with Thomas. Matter of fact, I just made a first release of a QT app I was working on. Has some features to go before a 1.0 release however.

The two show stoppers for me are speed and library support. My understanding is that C++ tries to go as high level as possible without sacrificing speed. That is to say, a well-written C++ program should be 99% as fast as a C program.

Can D get the speed without the ugly syntax? It takes quite a bit of skill to use C++ well, and a mediocre programmer is going to pooch it. The hideous things my eyes have seen, modifying other people's programs. To me, a simpler language equals more robust code, because it takes less thinking to make good design decisions.

In fact, Bjarne Stroustrup seems to agree with ML.

If D can give me the semantics and speed of C++ with cleaner style, I'd consider switching.

[EDIT] Erm, the Digital Mars compiler is proprietary, that will slow adoption in the Linux realm. Plus, it only supports 32-bit systems. The GDC compiler is version 0.23 alpha, and only has one developer. I guess I'll give D a few years to mature.

Walter Bright's official D compiler is post version 1.0 and quite stable. I think it's about 10 years in the making. He has even a longer history with developing compilers, as the author of Zortech/Symantec C++. In fact, most languages have been the works of a single individual. The Java and .NET stuff are pretty much exceptions to that.

His compiler already performs basically as good as C++ (sometimes better, sometimes worse - depends on the benchmark), so I really don't think it's a good reason to avoid the language altogether.

I really suggest that curious people read the D overview, as it's quite informative and honest.

Oh, and Python fans might want to look at pyd. It lets you run compiled D modules from within Python.

I hate half ass-ed languages. Either its hidden all the time, or never. Either its completely high level, or as low level a high level language can get (ie: C). I find C++ tries to be too much, and fails miserably.

Heh, along with the C++ operation, C++ evaluates to C, making it a no-op as far as the useable return result is concerned. It tries to be more, but didn't quite make it

No, I'm with you.

Me as well.

64-bit support is obviously a valid issue, but it being "proprietary" is just an excuse.

Honestly, I don't care if someone is too stuck up to download a free, open-source compiler because it's not part of their precious GPL commune. Those aren't the type of people likely to buy software anyway, so it's not like your commercial success will be hampered.

I think that is spoken like a true C/C++ fan. I don't mean that in a bad way, but using a certain method for a while makes you start thinking it's the best way. If C++ and D both came out yesterday, I think basically everybody would choose D. However, now that you've used C/C++ for a while, you become partial to it and anything D does differently seems wrong.

Personally, I think that D's system is far less confusing than C++'s. It works the way I expect it to, without all the ugly pointer syntax. (In fact, even C++ tries to hide away pointers ... that's what references do.) But D's system wasn't as big of a shock to me, coming from language (like PHP) that automatically handle pointers as well. Obviously if the language does a poor, inconsistent job with replacing pointers, then it's something to be concerned about.

Edit: An example to show how D handles it:

That would print "1 Hello, World Foo".

If I wanted the code to "work," I'd have to explicitly use the ref keyword, similar to C++'s & symbol.

However, dynamic arrays and objects are always pointers. That behavior is constant, so you never "don't know." For instance:

The above would output "Test", because all objects are pointers. If you really wanted to pass a copy of an object you have to explicitly do so on either end using the 'dup' property.

changeFoo(z.dup, "Test"); // wouldn't change z

  char[] y = "Hello, World";
  Foo z = new Foo("Foo");

  setNullInt(x);
  setNullString(y);
  setNullObj(z);

I think I'm confused...

To be honest, the only thing I really have against D is the name... If I'm gonna start using it the language needs to be renamed...

What I meant was that Linux distributions won't be able to package the D compiler and include it in their repository. Therefore, they won't package any software written with D.

Compiling software from source in binary-package distributions can be hit or miss because of missing dependencies. For example, if Allegro were written in D, the average user wouldn't be able to install it in Ubuntu*. You'd have to make a list of all the dependencies and tweaks for every Linux distribution separately.

However, this issue only affects Linux users. Windows and Mac folk can get the executable.

• See here for more.

Reading the docs would help you from looking like a fool, but because I know you won't, here you go:

string[] = someotherstring;

And as I mention, using non-const &/references makes it confusing too, since there's no indication in the function that you're doing "more permanent" changes. With a proper pointer you'd have to do
*foo = blah;
which makes it clear that you're modifying memory from somehwhere else and not that specific variable (assuming no operator overloads). If you do
foo = blah;
are you modifying a variable specific to the function, or are you also modifying the variable that the calling function passed? In C++ you'd have & at the declaration to tell you (which is still a bit too transparent for my tastes), where as in D, you have the ref keyword, but also the implicitness of objects (are typedef'd enums and basic types also implicitly references? if not, then that's more room for confusion).

If you have a large-ish function where you can't easilly check the variable's declaration, it's easy to miss or not know. Having to be explicit about dereferencing makes it easier to see that you're modifying memory from elsewhere.