5 ms·
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
by rkrzr 13y ago
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.
- irtefa 13y agoThanks for the thorough yet concise explanation.
- pcwalton 13y agoYou 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.)
- skybrian 13y agogoroutines are lighter than Java threads, though, so it's still an improvement.
- hugoc 13y agoLightweight Threads, Channels and Actors for the JVM: http://blog.paralleluniverse.co/post/49445260575/quasar-pulsar http://blog.paralleluniverse.co/post/49445260575/quasar-puls...
- jerf 13y agoIf you want to show that the JVM can do that, a better link is probably Akka: http://akka.io/ 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.
- karterk 13y agoActually 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.
- pjmlp 13y agoThis 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.
- cmircea 13y agoC# 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).
- bigdubs 13y agoTasks are still OS threads, though they get lumped into a threadpool so a lot of the overhead is mitigated (in most cases).
- balakk 13y agoThe async/await model does not create new threads. http://msdn.microsoft.com/en-us/library/vstudio/hh191443.aspx 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 http://msdn.microsoft.com/en-us/library/dd233250.aspx