Constructs like concurrency should not be granted their own syntax, especially when they can be cleanly implemented using the other constructs of a language, look at the C library libtask as an example.
In many environments, multi-threaded code is written in a language that was originally designed without thread support (e.g. C), to which a library of threading primitives was subsequently added. There appears to be a general understanding that this is not the right approach. We provide specific arguments that a pure library approach, in which the compiler is designed independently of threading issues, cannot guarantee correctness of the resulting code.We first review why the approach almost works, and then examine some of the surprising behavior it may entail. We further illustrate that there are very simple cases in which a pure library-based approach seems incapable of expressing an efficient parallel algorithm.Our discussion takes place in the context of C with Pthreads, since it is commonly used, reasonably well specified, and does not attempt to ensure type-safety, which would entail even stronger constraints. The issues we raise are not specific to that context.
As far as I can tell, goroutines are similar to the block mechanisms and runtime system in Grand Central Dispatch, which is the same concept of concurrency in Cilk (http://supertech.csail.mit.edu/cilk/ and the paper "The Implementation of the Cilk-5 Multithreaded Language" in particular: http://supertech.csail.mit.edu/papers/cilk5.pdf).
I'm not a big fan of Java, but one of its good points is that threads are part of the language and their behaviour is predicatable across implementations.
That isn't really the case. Java's threading can either be green threads or OS threads and there's no way as a programmer to know what the JVM implements on any given platform.
See the paper by Hans Boehm from PLDI 2005, "Threads Cannot Be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
The abstract explains the argument:
In many environments, multi-threaded code is written in a language that was originally designed without thread support (e.g. C), to which a library of threading primitives was subsequently added. There appears to be a general understanding that this is not the right approach. We provide specific arguments that a pure library approach, in which the compiler is designed independently of threading issues, cannot guarantee correctness of the resulting code.We first review why the approach almost works, and then examine some of the surprising behavior it may entail. We further illustrate that there are very simple cases in which a pure library-based approach seems incapable of expressing an efficient parallel algorithm.Our discussion takes place in the context of C with Pthreads, since it is commonly used, reasonably well specified, and does not attempt to ensure type-safety, which would entail even stronger constraints. The issues we raise are not specific to that context.
As far as I can tell, goroutines are similar to the block mechanisms and runtime system in Grand Central Dispatch, which is the same concept of concurrency in Cilk (http://supertech.csail.mit.edu/cilk/ and the paper "The Implementation of the Cilk-5 Multithreaded Language" in particular: http://supertech.csail.mit.edu/papers/cilk5.pdf).