You quote things you don't understand. n goroutines (where n is big) get multiplexed to m threads (small m, typically numbers of cores). Goroutines are cheap: each goroutine starts at a size of 4k, and creating them is a really cheap operation. Please show me a Java thread implementation with the same properties. Good luck with that.
>n goroutines (where n is big) get multiplexed to m threads (small m, typically numbers of cores).
You had the same thing in early Java with green-treads -- it is abandoned for modern JVMs, but you can mimic it. You can have millions of Scala actors.
>Goroutines are cheap: each goroutine starts at a size of 4k, and creating them is a really cheap operation.
Yes, but handling and migrating them is a "not really cheap operation". They are mostly useful as abstractions, as for performance you don't get anything over Java (if not worse: checkout Go vs Java concurrency benchmarks).
>Please show me a Java thread implementation with the same properties. Good luck with that.
Not sure I need all that "luck" you wish me. How about Java on Solaris, which multiplexes java threads to native threads?
From the documentation:
"Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run".
Same thing as in Java, just integrated into the language instead of a library. But then again, Scala offers that too.