5 ms·

Java will join the (imo) better concurrency path of higher level languages with green like threads, Golang (goroutine), Erlang, Java (Loom, virtual threads) & R

Java will join the (imo) better concurrency path of higher level languages with green like threads, Golang (goroutine), Erlang, Java (Loom, virtual threads) & Ruby (soon under Ractors?). I really think C# & Python will be jealous of the languages mentioned and puts them in an odd spot from language design perspective.

aardvark179 4y ago
For Ruby I’d say the closest equivalent would be Fibers with the scheduler support introduced at 3.0. They take a different approach with pros and cons compared to virtual threads, but they are similar.
SemanticStrengh 4y ago
Kotlin state of the art coroutines should be mentioned too
- deepsun 4y ago
  Isn't Kotlin coroutines have the same coloring problem (functions must be marked with "suspend").l? Although the coloring problem is only a problem if red functions are harder to use. Not sure marking all functions with "suspend" would make it any worse, besides infecting the codebase.
  - SemanticStrengh 4y ago
    The main coloring problem beyond async is the wrapping of return types in futures, which Kotlin groundbreakingly make transparent.
  - ackfoobar 4y ago
    Here the Kotlin lead argued that it is not a "problem". https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/how-do-you-color-your-functions-...
    - vips7L 4y ago
      I don't really see how that's not a problem. While not having to specifically await you still need to mark functions as suspend and only call suspending functions from other suspending functions. I am also not sure how this explicit marking would work with interfaces. Can you create an interface that can be implemented by both suspending and synchronous functions?
      - SemanticStrengh 4y ago
        > Can you create an interface that can be implemented by both suspending and synchronous functions? I don't remember. I do know you can at least specify suspend in an interface method to enforce its implementers to be suspending too. Note that this is e.g impossible in typescript..
      - ackfoobar 4y ago
        > you still need to mark functions as suspend and only call suspending functions from other suspending functions. You restated the idea of function colouring without further elaborating why it is a problem. If your thread can afford to block and want to call a suspend function, use `runBlocking`. If your thread cannot block, having `suspend` in the type just saves you from a bug.
        SemanticStrengh 4y ago
        runBlocking can't run regular functions right? Othwerwise what's preventing you from making the main() runblocking and have all functions under a context that allow both types? If runblocking can't allow non-suspending function then you got a problem because that mean a method implementing an interface can either be suspending or not and therefore for one of two implementation, fail.
        ackfoobar 4y ago
        You can absolutely do this. `fun main() = runBlocking<Unit> {` https://kotlinlang.org/docs/composing-suspending-functions.html#async-style-functions https://kotlinlang.org/docs/composing-suspending-functions.h...
nu11ptr 4y ago
As much as I love Rust for serious code and Python for scripting, I do much prefer the green thread model to async/await in general.
- kmac_ 4y ago
  Green threads and async/await are orthogonal concepts. Both can be used at the same time and separately. Jep 425 brigns VM threads, but the API remains same as the old one. Without deep language extensions any concurrency improvements, in terms of usage, aren't possible. C#, Rust, JS made the successful leap, and imo Go route is very interesting.
- abledon 4y ago
  for anyone interested in Rust's choice to not use the green thread model: https://www.reddit.com/r/rust/comments/7x0icm/regarding_green_threads/ https://www.reddit.com/r/rust/comments/7x0icm/regarding_gree... https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... > Initially, Rust supported only the green threading model. Later, native threading was added and ultimately became the default.
  - nu11ptr 4y ago
    I get why Rust opted for native threads vs. green threads as a default, esp. when they want to promote zero cost abstractions. What the above links don't cover, and what I'm interested in, is why async/await instead of M:N/green threads for the secondary "light weight" threading model. Was async/await easier to make "zero cost"? Or what was the reason?
    - amaranth 4y ago
      In theory async/await can be compiled to something as efficient as if you wrote all the non-blocking logic by hand so yeah, it's a "zero cost" abstraction. For green threads the stdlib would have to be designed around them (again) or they'd feel like something bolted on the side with two sets of APIs for everything. This is also the case for async/await but that means green threads don't have an advantage there. If you have to worry about Task vs Thread, make sure you all the right APIs from each, figure out what to do for TLS in Tasks, etc then you may as well just use the one that is more efficient.
criddell 4y ago
If it’s a better model, why wouldn’t C# and Python adopt it?
- jayd16 4y ago
  Yeah I really don't see an issue with C# building a virtual thread system if the paradigm really shifts that way. Its aggressively pragmatic in that way. In theory, such a system could be implemented on C# with the same sort of gotchas as Java virtual threads. I don't think there's a fundamental design conflict.
  - mike_hearn 4y ago
    There's no design conflict I'm aware of but you don't "just" implement virtual threads. The PR to do it in HotSpot is notoriously huge: https://github.com/openjdk/jdk/pull/8166 https://github.com/openjdk/jdk/pull/8166 1,140 files, (+98,553 −9,862 LOC) and those lines of code are mostly horribly fiddly low level assembly/compiler hacking. This is partly why it took years of development. Most people don't realize this, especially because in the later stages of course many others contributed, but Loom is in some sense one man's journey. Before he worked at Oracle Ron Pressler spent years writing a library called Quasar which implemented fibers on top of the JVM using bytecode rewriting and some low level hackery with internal APIs. At some point he became available for hiring and Oracle brought him on board, as by that point he was not only an expert in fiber implementations but also the JVM. That was the genesis of Loom. Something I've learned from following the intricacies of VM development is that what we get is very much a result of hidden human stories as well as technical decisions. Features happen or don't happen on the basis of who was available to be hired at the time, as much as cold calculations of performance impacts. In turn that depends heavily on the vagaries of personal lives. The skills needed to do this work aren't that easy to find on the open market and training takes a long time. For other VM implementors to do this, and realistically only .NET has the sort of languages where it makes sense (JS doesn't), well, it'd take a long time even if they start today and there's no guarantee of success.
fabioz 4y ago
Well, https://github.com/python-greenlet/greenlet https://github.com/python-greenlet/greenlet has been available for quite some time in Python (gevent probably being its most used flavor). i.e.: just because it's not in the standard library doesn't mean it's not available (so, you can actually choose whether you'd like to use async/await or greenlets).
- azinman2 4y ago
  Because it’s not in the standard library means there are various issues with compatibility. Everything needs to be designed/used for greenlets in mind. It’s not quite the same as the VM itself saying we’ve sorted it all out.
  - fabioz 4y ago
    Well, whenever you add threads to the mix (native or virtual threads) if you don't design for it, I don't think things pan out properly (but I guess that I agree that if someone designed with native threads going for virtual threads where the same APIs can now make IO async switch threads it's probably easier to go that route). I must say that the main usage I personally had of greenlets didn't have it in mind initially (it was used in an existing application where making the coloring wasn't really feasible as it was a huge app already and adopting green threads was much less work).

aardvark179 4y ago

For Ruby I’d say the closest equivalent would be Fibers with the scheduler support introduced at 3.0. They take a different approach with pros and cons compared to virtual threads, but they are similar.

SemanticStrengh 4y ago

Kotlin state of the art coroutines should be mentioned too

deepsun 4y ago
Isn't Kotlin coroutines have the same coloring problem (functions must be marked with "suspend").l? Although the coloring problem is only a problem if red functions are harder to use. Not sure marking all functions with "suspend" would make it any worse, besides infecting the codebase.
- SemanticStrengh 4y ago
  The main coloring problem beyond async is the wrapping of return types in futures, which Kotlin groundbreakingly make transparent.
- ackfoobar 4y ago
  Here the Kotlin lead argued that it is not a "problem". https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/how-do-you-color-your-functions-...
  - vips7L 4y ago
    I don't really see how that's not a problem. While not having to specifically await you still need to mark functions as suspend and only call suspending functions from other suspending functions. I am also not sure how this explicit marking would work with interfaces. Can you create an interface that can be implemented by both suspending and synchronous functions?
    - SemanticStrengh 4y ago
      > Can you create an interface that can be implemented by both suspending and synchronous functions? I don't remember. I do know you can at least specify suspend in an interface method to enforce its implementers to be suspending too. Note that this is e.g impossible in typescript..
    - ackfoobar 4y ago
      > you still need to mark functions as suspend and only call suspending functions from other suspending functions. You restated the idea of function colouring without further elaborating why it is a problem. If your thread can afford to block and want to call a suspend function, use `runBlocking`. If your thread cannot block, having `suspend` in the type just saves you from a bug.
      - SemanticStrengh 4y ago
        runBlocking can't run regular functions right? Othwerwise what's preventing you from making the main() runblocking and have all functions under a context that allow both types? If runblocking can't allow non-suspending function then you got a problem because that mean a method implementing an interface can either be suspending or not and therefore for one of two implementation, fail.
        ackfoobar 4y ago
        You can absolutely do this. `fun main() = runBlocking<Unit> {` https://kotlinlang.org/docs/composing-suspending-functions.html#async-style-functions https://kotlinlang.org/docs/composing-suspending-functions.h...

nu11ptr 4y ago

As much as I love Rust for serious code and Python for scripting, I do much prefer the green thread model to async/await in general.

kmac_ 4y ago
Green threads and async/await are orthogonal concepts. Both can be used at the same time and separately. Jep 425 brigns VM threads, but the API remains same as the old one. Without deep language extensions any concurrency improvements, in terms of usage, aren't possible. C#, Rust, JS made the successful leap, and imo Go route is very interesting.
abledon 4y ago
for anyone interested in Rust's choice to not use the green thread model: https://www.reddit.com/r/rust/comments/7x0icm/regarding_green_threads/ https://www.reddit.com/r/rust/comments/7x0icm/regarding_gree... https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... > Initially, Rust supported only the green threading model. Later, native threading was added and ultimately became the default.
- nu11ptr 4y ago
  I get why Rust opted for native threads vs. green threads as a default, esp. when they want to promote zero cost abstractions. What the above links don't cover, and what I'm interested in, is why async/await instead of M:N/green threads for the secondary "light weight" threading model. Was async/await easier to make "zero cost"? Or what was the reason?
  - amaranth 4y ago
    In theory async/await can be compiled to something as efficient as if you wrote all the non-blocking logic by hand so yeah, it's a "zero cost" abstraction. For green threads the stdlib would have to be designed around them (again) or they'd feel like something bolted on the side with two sets of APIs for everything. This is also the case for async/await but that means green threads don't have an advantage there. If you have to worry about Task vs Thread, make sure you all the right APIs from each, figure out what to do for TLS in Tasks, etc then you may as well just use the one that is more efficient.

criddell 4y ago

If it’s a better model, why wouldn’t C# and Python adopt it?

jayd16 4y ago
Yeah I really don't see an issue with C# building a virtual thread system if the paradigm really shifts that way. Its aggressively pragmatic in that way. In theory, such a system could be implemented on C# with the same sort of gotchas as Java virtual threads. I don't think there's a fundamental design conflict.
- mike_hearn 4y ago
  There's no design conflict I'm aware of but you don't "just" implement virtual threads. The PR to do it in HotSpot is notoriously huge: https://github.com/openjdk/jdk/pull/8166 https://github.com/openjdk/jdk/pull/8166 1,140 files, (+98,553 −9,862 LOC) and those lines of code are mostly horribly fiddly low level assembly/compiler hacking. This is partly why it took years of development. Most people don't realize this, especially because in the later stages of course many others contributed, but Loom is in some sense one man's journey. Before he worked at Oracle Ron Pressler spent years writing a library called Quasar which implemented fibers on top of the JVM using bytecode rewriting and some low level hackery with internal APIs. At some point he became available for hiring and Oracle brought him on board, as by that point he was not only an expert in fiber implementations but also the JVM. That was the genesis of Loom. Something I've learned from following the intricacies of VM development is that what we get is very much a result of hidden human stories as well as technical decisions. Features happen or don't happen on the basis of who was available to be hired at the time, as much as cold calculations of performance impacts. In turn that depends heavily on the vagaries of personal lives. The skills needed to do this work aren't that easy to find on the open market and training takes a long time. For other VM implementors to do this, and realistically only .NET has the sort of languages where it makes sense (JS doesn't), well, it'd take a long time even if they start today and there's no guarantee of success.

fabioz 4y ago

Well, https://github.com/python-greenlet/greenlet https://github.com/python-greenlet/greenlet has been available for quite some time in Python (gevent probably being its most used flavor). i.e.: just because it's not in the standard library doesn't mean it's not available (so, you can actually choose whether you'd like to use async/await or greenlets).

azinman2 4y ago
Because it’s not in the standard library means there are various issues with compatibility. Everything needs to be designed/used for greenlets in mind. It’s not quite the same as the VM itself saying we’ve sorted it all out.
- fabioz 4y ago
  Well, whenever you add threads to the mix (native or virtual threads) if you don't design for it, I don't think things pan out properly (but I guess that I agree that if someone designed with native threads going for virtual threads where the same APIs can now make IO async switch threads it's probably easier to go that route). I must say that the main usage I personally had of greenlets didn't have it in mind initially (it was used in an existing application where making the coloring wasn't really feasible as it was a huge app already and adopting green threads was much less work).