3 ms·

Yeah, right. Just take a closer look what goroutines really are (hint: not threads), and how Java threads differ from them.

• nickik 14y ago
  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?
  • _ak 14y ago
    Funny how we talk about Go and Java and you suddenly come up with Scala and Erlang.
    • nickik 14y ago
      Scala runs on the JVM and I said Erlang running on Java (granted I meant JVM). I was refering to this: https://github.com/trifork/erjang https://github.com/trifork/erjang
• pretoriusB 14y ago
  Well, you and your "hint" are mistaken. 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.
  • _ak 14y ago
    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.
    • pjmlp 14y ago
      http://labs.oracle.com/projects/squawk/ http://labs.oracle.com/projects/squawk/ Used to power these nice devices, http://www.sunspotworld.com/ http://www.sunspotworld.com/ Here is another one, http://www.cacaojvm.org/ http://www.cacaojvm.org/
    • pretoriusB 14y ago
      >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?
• pjmlp 14y ago
  Goroutines are what is known as green threads in Java land. The Java specification allows for green threads, N:1 mapping of threads, or system threads, 1:1 mapping to system threads. It is up to the Java VM or compiler to offer one implementation or even both. Tasks in java.util.concurrent make use of thread pooling to also achieve N:1 mapping of tasks to threads. The Squawk and the Cacao VMs are two examples of a Java VM using green threads, http://labs.oracle.com/projects/squawk/ http://labs.oracle.com/projects/squawk/ http://www.cacaojvm.org/ http://www.cacaojvm.org/