Yes. In my opinion the biggest win comes from goroutines and Go's runtime, which essentially allow you to write asynchronous non-blocking multi-threaded(!)code that looks like synchronous code and is as easy to read and reason about.
This leads to a huge reduction in complexity compared to the callback spaghetti you often get in other async frameworks. Basically putting concurrency first in the language and not relying on libraries seems to really pay off.
You don't have to build goroutines into the language to have lightweight multithreaded tasks. TBB does this for C++, for example. (Edit: I was mistaken about Java here -- apparently it does use OS threads.)
If you want to show that the JVM can do that, a better link is probably Akka: http://akka.io/ Your link appears to be a guy's personal project, which is great, but akka is from what I gather an industrial-strength implementation.
Though as the Node people occasionally point out, it is advantageous to have this sort of thing baked into the language, so that everything done in the language supports the concepts, rather than having a relatively small corner support it. Plus you get Go, instead of Java, which I for one would find an improvement.
Actually if one wants to use Akka, one should be using Scala. Akka using Java is a total pain in comparison. Atleast with Scala, one seldom gets the feeling that the library is far from the language semantics.
Comments
Yes. In my opinion the biggest win comes from goroutines and Go's runtime, which essentially allow you to write asynchronous non-blocking multi-threaded(!)code that looks like synchronous code and is as easy to read and reason about. This leads to a huge reduction in complexity compared to the callback spaghetti you often get in other async frameworks. Basically putting concurrency first in the language and not relying on libraries seems to really pay off.
You don't have to build goroutines into the language to have lightweight multithreaded tasks. TBB does this for C++, for example. (Edit: I was mistaken about Java here -- apparently it does use OS threads.)
This is not true, regarding Java.
The Java language specification does not require the use of OS threads for Java threads.
It all depends which JVM you refer to.
The JVMs that make use of green threads follow a similar threading model to Go.
Don't mix languages with implementations.
goroutines are lighter than Java threads, though, so it's still an improvement.
Lightweight Threads, Channels and Actors for the JVM: http://blog.paralleluniverse.co/post/49445260575/quasar-puls...
If you want to show that the JVM can do that, a better link is probably Akka: http://akka.io/ Your link appears to be a guy's personal project, which is great, but akka is from what I gather an industrial-strength implementation.
Though as the Node people occasionally point out, it is advantageous to have this sort of thing baked into the language, so that everything done in the language supports the concepts, rather than having a relatively small corner support it. Plus you get Go, instead of Java, which I for one would find an improvement.
Actually if one wants to use Akka, one should be using Scala. Akka using Java is a total pain in comparison. Atleast with Scala, one seldom gets the feeling that the library is far from the language semantics.
C# 5 also has this, with the async/await keywords. The nice thing is that it works with older plain Task-based code (which was callback spaghetti).
Tasks are still OS threads, though they get lumped into a threadpool so a lot of the overhead is mitigated (in most cases).
The async/await model does not create new threads.
http://msdn.microsoft.com/en-us/library/vstudio/hh191443.asp...
TPL(Task parallel library) does use additional threads, and that's a different programming model.
The async/await model in C# is essentially from F#'s async workflows:
http://msdn.microsoft.com/en-us/library/dd233250.aspx
I realize that, what I was referring to was the old model (TPL), which wasn't terrible to begin with.
The "new" model is just syntactic sugar over the "old" TPL, so you're wrong anyway ;-)
Thanks for the thorough yet concise explanation.