You show your ignorance again. Do you think that go does not use operatingsystem threads in the background? Do you think the same abstraction could and has not been built for java? How do you think does the Erlang impmentation on Java work? How do you think that scala can start so many actors? How do you think the forkjoin framework works?
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?
Channels and Goroutines are easily available in java.util.concurrent.
If you really want compilation to pure native code, there native code compilers for Java as well.