10 ms·

Seems java's virtual thread is the only sane async model out there.

by feverzsj 3y ago

yogorenapan 3y ago
I believe Golang uses a similar model but much more simple to use. Uncolored async is the way to go
- ribelo 3y ago
  Go's approach to async programming is indeed simpler, but its FFI and handling of stateful coroutines can introduce complexity and overhead when bridging with external code. Using CGO is slow because it requires synchronization of the coroutine state between libc and Go. Everyone avoids CGO whenever possible, so it is not a solution. Rust chose a different path that is not more complex, but the complexity lies elsewhere.
  - yencabulator 3y ago
    Just an extra bit of clarity: the relative slowness of CGo calls is a conscious trade-off that enables Go threads to be much lighter weight. It's not an inherent aspect of the design, but a trade-off you pay for wanting more lightweight green threads. Choosing to not follow the age old C ABI internally means you have to bridge that gap if and when you come to it.
- Yoric 3y ago
  I'm of two minds on this point. Uncolored async is simpler language design and works well for _most_ cases but provides way fewer guarantees than colored async, with the potential to break badly in some cases. For instance, there are many system-level data structures that are not allowed to migrate from one thread to another (e.g. Linux mutexes or Rust's Rc) or sometimes from one core to another. If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all. Which means that you can't be a system programming language (for some definition of system programming). By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may https://github.com/Xudong-Huang/may .
  - SkiFire13 3y ago
    > e.g. Linux mutexes You don't want to use blocking mutexes anyway with async. > or Rust's Rc This is only half true. The danger is that two `Rc` that point to the same data are in different threads. But it should be safe to move all of them at once from one thread to another, which is exactly the case if all the `Rc`s involved live inside a `Future`. The problem is that this is a non-local property that's hard to encode in the type system. > By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may https://github.com/Xudong-Huang/may . FYI that's known to be unsound due to thread locals. And more generally it doesn't seem to give much attention to safety (see for example how it allowed unsound scoped tasks, or the fact it allows doing unsafe operations in some of its macros due to wrong scoping of `unsafe` blocks).
  - yencabulator 3y ago
    > If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all. A simple call to https://pkg.go.dev/runtime#LockOSThread https://pkg.go.dev/runtime#LockOSThread solves that. Pay the cost of backwards compat when you need it, don't pay it when you don't need it.
i_am_a_peasant 3y ago
That I can easily believe. Someone should make a benchmark of how many requests you can serve from a java backend compared to a rust backend that's heavy on IO and network.
- 15457345234 3y ago
  It wouldn't stop the hype, it never does. I never understood the fascination for working with cutting edge languages; to me it just increases the likelihood that you're going to find language errors or library errors and get tied up for ages helping to refine the environment. Plus the relatively small size of the developer community and supporting literature available. Maybe it's a dog people thing, the sort of people that get into it are the sort of people that want to go home and have a dog with infinite energy bouncing up and down all the time. Just exhausting to even think about.
  - biorach 3y ago
    > cutting edge languages; Whatever about anything else, Rust has definitely moved past "cutting edge"
  - i_am_a_peasant 3y ago
    I have been actually professionally working with Rust for the last 2 years, and most recently on certified safety systems. But I'm always thinking that the JVM is a pretty solid platform that has not yet reached its full potential. It gets a bad rap because of the hellhole that enterprise software is. But come on, look at android, look at games like Minecraft. Solid projects, written in large part in Java.
    - jcelerier 3y ago
      Describing Minecraft as "solid" makes me very scared reading "certified safety systems". Minecraft is the most standard possible example of Java's badness and bloat. It's explicitly what software should strive not to be.

Seems java's virtual thread is the only sane async model out there.

yogorenapan 3y ago

I believe Golang uses a similar model but much more simple to use. Uncolored async is the way to go

ribelo 3y ago
Go's approach to async programming is indeed simpler, but its FFI and handling of stateful coroutines can introduce complexity and overhead when bridging with external code. Using CGO is slow because it requires synchronization of the coroutine state between libc and Go. Everyone avoids CGO whenever possible, so it is not a solution. Rust chose a different path that is not more complex, but the complexity lies elsewhere.
- yencabulator 3y ago
  Just an extra bit of clarity: the relative slowness of CGo calls is a conscious trade-off that enables Go threads to be much lighter weight. It's not an inherent aspect of the design, but a trade-off you pay for wanting more lightweight green threads. Choosing to not follow the age old C ABI internally means you have to bridge that gap if and when you come to it.
Yoric 3y ago
I'm of two minds on this point. Uncolored async is simpler language design and works well for _most_ cases but provides way fewer guarantees than colored async, with the potential to break badly in some cases. For instance, there are many system-level data structures that are not allowed to migrate from one thread to another (e.g. Linux mutexes or Rust's Rc) or sometimes from one core to another. If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all. Which means that you can't be a system programming language (for some definition of system programming). By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may https://github.com/Xudong-Huang/may .
- SkiFire13 3y ago
  > e.g. Linux mutexes You don't want to use blocking mutexes anyway with async. > or Rust's Rc This is only half true. The danger is that two `Rc` that point to the same data are in different threads. But it should be safe to move all of them at once from one thread to another, which is exactly the case if all the `Rc`s involved live inside a `Future`. The problem is that this is a non-local property that's hard to encode in the type system. > By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may https://github.com/Xudong-Huang/may . FYI that's known to be unsound due to thread locals. And more generally it doesn't seem to give much attention to safety (see for example how it allowed unsound scoped tasks, or the fact it allows doing unsafe operations in some of its macros due to wrong scoping of `unsafe` blocks).
- yencabulator 3y ago
  > If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all. A simple call to https://pkg.go.dev/runtime#LockOSThread https://pkg.go.dev/runtime#LockOSThread solves that. Pay the cost of backwards compat when you need it, don't pay it when you don't need it.

i_am_a_peasant 3y ago

That I can easily believe. Someone should make a benchmark of how many requests you can serve from a java backend compared to a rust backend that's heavy on IO and network.

15457345234 3y ago
It wouldn't stop the hype, it never does. I never understood the fascination for working with cutting edge languages; to me it just increases the likelihood that you're going to find language errors or library errors and get tied up for ages helping to refine the environment. Plus the relatively small size of the developer community and supporting literature available. Maybe it's a dog people thing, the sort of people that get into it are the sort of people that want to go home and have a dog with infinite energy bouncing up and down all the time. Just exhausting to even think about.
- biorach 3y ago
  > cutting edge languages; Whatever about anything else, Rust has definitely moved past "cutting edge"
- i_am_a_peasant 3y ago
  I have been actually professionally working with Rust for the last 2 years, and most recently on certified safety systems. But I'm always thinking that the JVM is a pretty solid platform that has not yet reached its full potential. It gets a bad rap because of the hellhole that enterprise software is. But come on, look at android, look at games like Minecraft. Solid projects, written in large part in Java.
  - jcelerier 3y ago
    Describing Minecraft as "solid" makes me very scared reading "certified safety systems". Minecraft is the most standard possible example of Java's badness and bloat. It's explicitly what software should strive not to be.