3 ms·

A likely large contributor to others' experience not matching yours is async: Newcomers often refuse to try rust's excellent native threading support and jump r

A likely large contributor to others' experience not matching yours is async: Newcomers often refuse to try rust's excellent native threading support and jump right to the badly tacked-on, lets-write-javascript-in-rust monstrosity called async. Async "won" in the rust ecosystem because of superior branding but it is by far the worst solution to parallelism in rust. It has, by necessity, 100% of the problems and limitations of threading, such as they are, plus many more of its own. It's impossible that async could ever be easier than threading and yet countless newcomers are lured in and convinced they don't understand threads therefore need async. "I don't understand how to fly a Cessna therefore I need to fly an F-15."

remram 4y ago
Async has been in development for a few years during which the experience wasn't great. The popularity of Rust made it so many people wanted to try it anyway, with a plethora of frameworks being developed and replaced and not working when the next version of futures/tokio/hyper came out. The experience now that futures are in the standard library and tokio etc are actually stable is much better. Most async libraries are thread-safe, contrary to the JavaScript or Python asyncio worlds, so you are free to call call block_on(func(...)) in whatever thread if that is your preferred coding style and the library doesn't already expose a blocking interface. The low-level "zero-cost" future composition is available to you if you need to squeeze a lot of performance but you absolutely don't have to wrestle with the "monstrosity" if you don't want to.
geodel 4y ago
Well, users are obsessed with Async because Rust authors themselves are obsessed with it. The amount of discussions around design and development of Async feature is endless. The common theme is how a normal crappy Go app will become super app with Rust's zero cost async support. I can understand they chose this path to gain market share by having tons of web services written in Rust. And async might be great fit for it. But now one can't just go around and say 'Oh, Rust async is not for plebs they can continue with something much simpler to fulfill their needs'.
cmrdporcupine 4y ago
Yep and the worst is that it seems that now 3rd party dependencies basically force it because they've also made that choice. And one thing in your stack is async, everything else ends up following.
the__alchemist 4y ago
I'd love an async filter on `crates.io` and `docs.rs`.
josephg 4y ago
Async works great in other languages. I adore being able to get high performance out of a single thread in javascript thanks to its async IO model. Rust's problem with async isn't that async itself is a bad idea. The problem is that rust got halfway through adding async support and then didn't finish the job. If you have half a house, your problem isn't that houses are a bad idea. You just need a builder. (Or, a wrecking ball. Which I'd be more than happy with at this point.)
- mwcampbell 4y ago
  > (Or, a wrecking ball. Which I'd be more than happy with at this point.) I doubt that would be necessary or appropriate. A lot of thought, discussion, and work has already gone into the design, and I'm inclined to assume that the people involved knew what they were doing. Rust's zero-overhead approach to async is much more ambitious than the async support in other languages. More work on the interactions with other language features would certainly be useful, but I think suggesting that the existing implementation be discarded is more likely to frustrate the people who have been doing all of this hard work than to accomplish anything useful.
Zababa 4y ago
> Newcomers often refuse to try rust's excellent native threading support and jump right to the badly tacked-on, lets-write-javascript-in-rust monstrosity called async. To be fair, many of those newcomers have heard that threaded code is very hard to get right (which is repeated by so many people these days), and/or come from the JS world where async is pretty much the only choice you have. This is something that may be partially fixed by more communication. For example, the Rust book currently doesn't cover async at all. Adding a chapter on async and when to use it might help. Another issue is that lots of people come to Rust from/for webdev. The most popular web frameworks (actix-web, rocket, ...) are all using async. I don't have any idea on how to fix this. If what you say is true, that "It's impossible that async could ever be easier than threading", then I think that's something that people should know and tell other people.
chlorion 4y ago
Threading is not an alternative to "async" and can't replace it. The alternative to "async" is non-blocking IO and an event loop written by hand, possibly with some threading thrown into the mix for certain tasks. This is exactly what the async runtime is doing behind the scenes, and what languages without first class async support have to do to support this form of concurrency. Doing an event loop manually is probably going to end up being more difficult and less safe than using the language level async abstractions. Sometimes just spawning threads is the best solution, but it's fairly wasteful to spawn threads for something like IO, especially if there are many operations in flight (1000+).

remram 4y ago

Async has been in development for a few years during which the experience wasn't great. The popularity of Rust made it so many people wanted to try it anyway, with a plethora of frameworks being developed and replaced and not working when the next version of futures/tokio/hyper came out. The experience now that futures are in the standard library and tokio etc are actually stable is much better. Most async libraries are thread-safe, contrary to the JavaScript or Python asyncio worlds, so you are free to call call block_on(func(...)) in whatever thread if that is your preferred coding style and the library doesn't already expose a blocking interface. The low-level "zero-cost" future composition is available to you if you need to squeeze a lot of performance but you absolutely don't have to wrestle with the "monstrosity" if you don't want to.

geodel 4y ago

Well, users are obsessed with Async because Rust authors themselves are obsessed with it. The amount of discussions around design and development of Async feature is endless. The common theme is how a normal crappy Go app will become super app with Rust's zero cost async support. I can understand they chose this path to gain market share by having tons of web services written in Rust. And async might be great fit for it. But now one can't just go around and say 'Oh, Rust async is not for plebs they can continue with something much simpler to fulfill their needs'.

cmrdporcupine 4y ago

Yep and the worst is that it seems that now 3rd party dependencies basically force it because they've also made that choice. And one thing in your stack is async, everything else ends up following.

the__alchemist 4y ago

I'd love an async filter on `crates.io` and `docs.rs`.

josephg 4y ago

Async works great in other languages. I adore being able to get high performance out of a single thread in javascript thanks to its async IO model. Rust's problem with async isn't that async itself is a bad idea. The problem is that rust got halfway through adding async support and then didn't finish the job. If you have half a house, your problem isn't that houses are a bad idea. You just need a builder. (Or, a wrecking ball. Which I'd be more than happy with at this point.)

mwcampbell 4y ago
> (Or, a wrecking ball. Which I'd be more than happy with at this point.) I doubt that would be necessary or appropriate. A lot of thought, discussion, and work has already gone into the design, and I'm inclined to assume that the people involved knew what they were doing. Rust's zero-overhead approach to async is much more ambitious than the async support in other languages. More work on the interactions with other language features would certainly be useful, but I think suggesting that the existing implementation be discarded is more likely to frustrate the people who have been doing all of this hard work than to accomplish anything useful.

Zababa 4y ago

> Newcomers often refuse to try rust's excellent native threading support and jump right to the badly tacked-on, lets-write-javascript-in-rust monstrosity called async. To be fair, many of those newcomers have heard that threaded code is very hard to get right (which is repeated by so many people these days), and/or come from the JS world where async is pretty much the only choice you have. This is something that may be partially fixed by more communication. For example, the Rust book currently doesn't cover async at all. Adding a chapter on async and when to use it might help. Another issue is that lots of people come to Rust from/for webdev. The most popular web frameworks (actix-web, rocket, ...) are all using async. I don't have any idea on how to fix this. If what you say is true, that "It's impossible that async could ever be easier than threading", then I think that's something that people should know and tell other people.

chlorion 4y ago

Threading is not an alternative to "async" and can't replace it. The alternative to "async" is non-blocking IO and an event loop written by hand, possibly with some threading thrown into the mix for certain tasks. This is exactly what the async runtime is doing behind the scenes, and what languages without first class async support have to do to support this form of concurrency. Doing an event loop manually is probably going to end up being more difficult and less safe than using the language level async abstractions. Sometimes just spawning threads is the best solution, but it's fairly wasteful to spawn threads for something like IO, especially if there are many operations in flight (1000+).