This is the missing second reply to Andrei. I'm posting parts of it because it my help understand my position better.
I wouldn't dismiss Scala out of hand. The main threading model in Scala is (library-supported) actor model. Isn't that what you're proposing for D? Except that Scala has much better support for functional programming. The languages [C++ and Java] may be dead in the water (altough still the overwhelming majority of programmers use them), but I don't see the idea of shared-memory concurrency dying any time soon. I bet it will be the major programming model for the next ten years. What will come after that, nobody knows. The complexity argument: My proposal looks complex because I am dropping the whole comprehensive solution on the D community all at once. I would be much wearier of the kind of creeping complexity resulting from incremental ad-hoc solutions. For instance, the whole complexity of immutability hasn't been exposed yet. If it were, there would be a much larger insurgency among D users. You know what I'm talking about--invariant constructors. My proposal goes into nooks and crannies and, of course, it makes it look more complex than it really is. Not to mention that there could be a lot of ideas that would lead to simplifications. I sometimes discuss various options for discussion. Take my proposal for unique objects. I could have punted the need for "lent". Maybe nobody would ask for it? Compare "unique" with "scope"--nobody knows the target semantics of "scope". It's a half-baked idea, but nobody's protesting. Try to define the semantics of array slices and you'll see eyes glazing. We know we have to fix them, but we don't know how (array[new]?). Another half-baked idea. Are slices simple or complex? Define the semantics of "shared". Or should we implement it first and hope that the complexity won't creep in when we discover its shortcomings. > Why wouldn't we think of making message passing a language feature in D? Well, we could, but why? We don't have to add any new primitives to the language to implement message queues. We would have to *eliminate* some features to make message passing safe. For instance, we'd have to eliminate "shared". Is that an option? > Why does message passing need erlangization to support message passing? The power of Erlang lies in guaranteed process isolation. If we don't guarantee that, we are in the same league as Java or C++. > What I discussed was a holistic approach in which language + standard > library provides a trusted computing base. I like that very much. But I see the library as enabling certain useful features, while the type system as disabling the dangerous ones. You can't disable features through a library.
