Why I (Still) Won't Use D

[Sean Kelly]

== Quote from Tim Burrell (tim at timburrell.net)'s article
> Sean Kelly wrote:
> > == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> >> Sean Kelly wrote:
> >>> It's been shown fairly conclusively that STL-conformant COW strings
> >>> are incompatible with multithreaded programs,
> >> This is what I was alluding to when I said that the C++ community knows
> >> there are fundamental problems with C++ and multithreading, and that C++
> >> const is one of the culprits. I don't think C++0x addresses this at all.
> >
> > It doesn't.  Frankly, I think the multithreading features in C++ 0x are too
> > little too late.  They'll probably make maintaining old code a bit easier, and
> > perhaps buy the language an extra five years of mainstream relevance while
> > people struggle to make it work, but the changes still only bring C++ up to
> > where Java was when JSR-133 was published some five (?) years ago.  And
> > by the time compilers are 0x compliant I wouldn't be half surprised for the
> > average PC to contain 8 cores and for lock-based programming to be well
> > on its way out.
> Everyone here seems quick to point the finger at C++0x for not doing
> more with working toward good parallel support.  But we're not really
> addressing the point that even disregarding C++0x, C++ _already_ has WAY
> better parallel support than D does via OpenMP (which is available on
> nearly every C++ compiler).

Hogwash.  C++ has no in-language support for multithreading at all.  OpenMP
is simply a library built on top of C++.  It doesn't count.  One could create the
exact same thing for D.  Heck, D already has futures, DSCP, a good collection
of synchronization primitives (tango.core.sync), etc.

> When C++0x comes out, combined with OpenMP, D won't even be close to
> being a viable language for parallel development... unless of course gdc
> can leverage some of gcc's (>= 4.2) OpenMP support maybe?

I disagree.  D already has basically everything C++ 0x will have in terms of
multithreaded support and it has them now.  The only advantage C++ will
have is a well-defined multithreaded memory model, and by the time anyone
actually supports it for C++ 0x I suspect we'll have something equivalent in
D.  Also, D does have a "volatile" statement which accomplishes much the
same thing as the multithreaded memory model in C++.  It's much more low-
level, but does allow a library writer to create correct, language-conformant
lock-free code.  See tango.core.Atomic, for example.  Tango has had the Atomic
module since its release over a year ago, and it's much the same as what the
C++ committee has decided upon for 0x even with the language changes.

That said, I should qualify the above by saying that I don't consider the state
of C++ to be at all reflective of the abilities or the desire of anyone on the
committee, but rather an artifact of the glacially slow standardization process
as well as a basic requirement of backwards-compatibility.  The combination
of these factors pretty much guarantees that C++ will never look very different
than it does today regardless of what would be best for its ability to solve new
problems in the future.  By contrast, if Walter decided to morrow that he wanted
D to become a purely functional language with write-once variables then he
could do so, even if it meant breaking every program ever written for D.


Sean