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).
- Re: Opportunities for D Bienlein via Digitalmars-d
-
