21–30 of 499 posts
It's worth remembering that this is still a very acceptable thing to do in some cases. And spawning OS threads is sometimes easier to write and easier to read, and easier to reason about than async code.
Just because async is in the language, don't feel like you need to use it everywhere.
> The thing I really want to try and get across here is that *Rust is not a language where first-class functions are ergonomic.* So... don’t use first-class functions so much? It’s a systems language, not a functional language for describing algorithms in CS whitepapers. Or use `move` (the article does mention this). There are easy paths in most programming languages, and harder paths. Rust is no exception. The fact…
Then maybe it was a mistake to adopt an async paradigm from functional languages that relies heavily on the idea that first-class functions are cheap and easy?
(FWIW I think Rust was right to pick Scala-style async; it's really the only nice way of working with async that I've seen, in any language. I think the mistake was not realising the importance of first-class functions and prioritising them higher)
Having played with this a bit recently, I think folks are going to end up:
- assuming Tokio (now that it’s 1.xx)
- mark nearly everything as async
- push callers to use rt.block_on to wait for an async function from non-async code
I definitely miss the easy concurrency of golang the author refers to (more so in the colored functions post), particularly since AFAICT, tokio is basically going to become the default assumption. So Rust is technically pluggable here, but won’t be in practice. Does that mean that embedded folks end up having their own !tokio that they prefer? Maybe! But they’ll get locked out of the “assume tokio” ecosystem.
Async isn't really the problem - the same issue pops up with error handling, with resource management, with anything where you want to pass functions around. The real problem is that Rust's ownership semantics and limited abstractions mean it doesn't really have first-class functions: there are three different function types and the language lacks the power to abstract over them, so you can't generally take an expres…
You should read the article! The author goes into this in fascinating detail.
Either way there are bigger function "color" problems in Rust.
If you want a target for criticism in async Rust, it should be the lack of easy conversion from generators to async functions (and back) and the cognitive difficulty of implementing a custom executor.
I also think the tangent on closures is nonsense, closures are syntactically and semantically complex because closures are hard to keep safe without a garbage collector. Reference radioactivity is a feature, not a bug.
> The thing I really want to try and get across here is that *Rust is not a language where first-class functions are ergonomic.* So... don’t use first-class functions so much? It’s a systems language, not a functional language for describing algorithms in CS whitepapers. Or use `move` (the article does mention this). There are easy paths in most programming languages, and harder paths. Rust is no exception. The fact…
> So... don’t use first-class functions so much? It’s a systems language, not a functional language for describing algorithms in CS whitepapers. Then maybe it was a mistake to adopt an async paradigm from functional languages that relies heavily on the idea that first-class functions are cheap and easy? (FWIW I think Rust was right to pick Scala-style async; it's really the only nice way of working with async that I'…
As I read through the database example, I saw that the compiler just caught a multi-threading bug for the author, and instead of being thankful, he’s complaining that Rust is bad. I think he should use a higher level framework, or wait a few years for them to mature, and use a garbage collected language until then.
The compiler complained: “error[E0308]: mismatched types”
That's an evocative title.
one nice thing about rust's async/await is, you don't have to use it, and if you don't, you don't pay for it in any way. sure, I run into crates that expect me to bring in a giant runtime to make a http request or two (e.g. rusoto), but for the most part I have not had any issues productively using sans-async rust during the last few years.
so, if you don't like async/await, just don't use it! it doesn't change anything about the rest of rust.