Opportunities for D

[Bienlein via Digitalmars-d]

I think Walter is exactly right with the first 7 points he is 
listing in his starting post of this thread. Nullable types are 
nice, but don't get too much distracted by them. The first 7 
points are far more important. Go takes absolutely no effort to 
get rid of nil and they are very successful in despite of this 
nil thing.

IMHO goroutines and channels is really the key. D might be a 
better C++. But languages need a use case to make people change. 
I don't see why D can't do for cloud computing and concurrent 
server-side software what Go is doing. Go's GC is also not that 
advanced, but it is precise so 24/7 is not a problem. Making the 
D GC precise is more important than making it faster.

Actually, you get the strange situation now that to make D a 
language for the cloud a quick approach would be to make 
everything GC and let people have pointers as well as in Go. Of 
course, no good approach for the long run prospects of D. But let 
all memory management be handled by the GC should remain easy in 
D. Otherwise, D will be for the systems people only as with Rust.

>Much of the froth about Go is dismissed by serious developers, 
>but they nailed the goroutine thing. It's Go's killer feature.

I think so, too. Along with channels and channel selects to 
coordinate all those goroutines and exchange data between them. 
Without them goroutines would be pointless except for doing 
things in parallel. I'm not sure you can do selects in the 
library with little lock contention, but I'm not an expert on 
this.

>Think of it from the perspective of attracting Erlang 
>programmers, or Java/Scala programmers who use Akka.

Not wanting to be rude, but you don't stand a chance with that. 
Java has Hadoop, MongoDB, Hazelcast, Akka, Scala, Cassandra and 
MUCH more. No way you can beat all that. Hordes of average Java 
developers that will be against you, because they know Java and 
nothing else and don't want to loose their status.

But Go also does not have these things. It's success is huge, 
though, and it seems mostly to be attributed to goroutines and 
channels. This made Go the "language for the cloud" (at least 
other people say so), which is what there is a need for now. 
Other than that Go is drop dead simple. You can start coding now 
and start your cloud software start-up now. There is nothing 
complicated you need to learn. D cannot compete with that (thank 
goodness it is also no minimalistic language like Go).

>Akka similarly uses its own lightweight threads, not heavyweight 
>JVM threads.

Akka uses some approach like Apple's Grand Central Dispatch. As I 
understand it so does vibe.d (using libevent). A small number of 
threads is serving queues to which tasks are added. This works 
fine as long as those tasks are short runners. You can have 
50.000 long runners in Go. As long as they aren't all active the 
system is well responsive. You can't have 50.000 long-runners in 
Akka, because they would block all kernel threads that serve the 
task queues. The 50.000 and first long running task will have to 
wait a long time till it will be served. This is why they have 
special worker threads in Vert.x for Java: threads that are 
reserved for long-runners (and you can't have many of them).