5 ms·

> In this environment, a language like Go has the opportunity to shine. Go has another advantage over Scala (and any other JVM langauge), which also happens to

• pjmlp 12y ago
  I guess you haven't read the JLS. There isn't any requirement for red threads in certified JVMs and a few of them do offer green threads, which is actually how the first versions used to do threading.
  • smegel 12y ago
    Well I meant that in regard to which JVMs people actually use...not what are theoretically possible.
    • jbooth 12y ago
      Even then, Java's had ExecutorService, Callable<T> and BlockingQueue<T> for a long time. Effectively the same thing as Go's green threads from a programmer's perspective, with the only real difference being that Go swaps out an executing goroutine on I/O or other syscalls (or calling any C code).
      • Matthias247 12y ago
        Newer Go ersions will also preempt green threads on normal functions calls and not only on syscalls. Both is not possible with the JVMs primitives where you need "cooperative code". However there exists Quasar for the JVM which seems to be able to emulate something similar to green threads with the help of bytecode weaving (and inserting preemption points).
        • jbooth 12y ago
          Ok, fair enough, but if IO isn't happening, who cares if it's a runtime or the OS swapping out the 'thread'?
    • pjmlp 12y ago
      I was also talking about JVMs people actually use. There is much more out there than OpenJDK and Oracle commercial JVM. If you want a real product example, http://www.is2t.com/products/specifications/ http://www.is2t.com/products/specifications/
• dragonwriter 12y ago
  > Go has another advantage over Scala (and any other JVM langauge), which also happens to be it's killer feature - green threads, the ability to write non-blocking concurrent code in a synchronous style without callbacks. "Green threads", per se, aren't an advantage. M:N threads are potentially an advantage, since they allow both hardware parallelism and concurrency with a greater degree than the degree of hardware parallelism without the overhead of native threads for each concurrent task. OTOH, nothing stops either JVM implementations (when compared to the underlying platform) or JVM languages (when compared to the JVM itself) from using an M:N threading model. > Yes, I am sure Scala has some "leaky abstraction" over what are essentially just callbacks, as does Java, but it's not quite the same. Green threads (whether 1:N or M:N) are a (potentially leaky) abstraction over what are essentially callbacks, too (while a well-designed green thread implementation can avoid this for code written entirely in the language, for calls linked code written in other languages that isn't specifically aware of and designed to cooperate with the green thread implementation, there is the risk of actions which block the underlying native thread, which will then block all green threads that are running on the same native thread.)
• deleted 12y ago
  [deleted]
• TheHydroImpulse 12y ago
  No, it's certainly not an advantage in every case, because that's all you can use. It's not always the best tool for the job. Under the JVM, you have a massive amount of library support for multithreading and concurrency. You have things available like Futures, STM (Software transaction model), Actor Model (Akka), parallel collections, etc... Not to mention taking advantage of immutability, which can simplify concurrency a lot in some cases. It's not a one-size-fits-all type of game here. So having one choice will essentially lock you into what you can do with it. I also wouldn't say a Future, which is a Monad, a leaky abstraction. You don't really need to understand monads to use them, in fact, a lot of people use what are monads all the time, without knowing it.
  • codygman 12y ago
    > STM (Software transaction model) I thought this was software transactional memory? Java has an implementation?
    • TheHydroImpulse 12y ago
      Oops, not sure why I put that, it's indeed software transactional memory. Akka is a pretty known library that supports it.