Why asynchronous Rust doesn't work
theta.eu.org
Why asynchronous Rust doesn't work
1–10 of 499 posts
Re: Why asynchronous Rust doesn't work
#2I'm coming around to the position that pure "async" is OK, and pure threading is OK, and green threads (as in Go goroutines) are OK, but having more than one of those in a language is not OK. They do not get along well.
Re: Why asynchronous Rust doesn't work
#3I'm coming around to the position that pure "async" is OK, and pure threading is OK, and green threads (as in Go goroutines) are OK, but having more than one of those in a language is not OK. They do not get along well.
Isn’t the Go solution green threads on top of hardware threads?
Lots of green threads get load balanced on top of a thread pool. Isn’t that the whole unique aspect of Go? So in essence they do both.
Re: Why asynchronous Rust doesn't work
#4That's an evocative title.
Re: Why asynchronous Rust doesn't work
#5I'm coming around to the position that pure "async" is OK, and pure threading is OK, and green threads (as in Go goroutines) are OK, but having more than one of those in a language is not OK. They do not get along well.
Isn’t the Go solution green threads on top of hardware threads? Lots of green threads get load balanced on top of a thread pool. Isn’t that the whole unique aspect of Go? So in essence they do both.
I think the idea is that they do not present as competing paradigms.
Go green threads or go routine are the only visible constructs to users. Whereas the hardware threads are not usable to users.
Edit: From the perspective of mutli-paradigm, C++ is truely a unique language. It not only has multiple paradigms, and largely contains them in a relatively harmony state.
Re: Why asynchronous Rust doesn't work
#6As 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.
Re: Why asynchronous Rust doesn't work
#7I'm surprised Rust went with a Scala-inspired async/await considering it wasn't well-liked outside of PLT enthusiasts. JavaScript adopted it as I don't think you could bolt any other type of sugar on top of the event loop in browsers... but Rust shouldn't suffer from such baggage.
Re: Why asynchronous Rust doesn't work
#8> 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 that passing around async closures with captured variables and also verifying nothing gets dropped prematurely and without resorting to runtime GC is bleeding-edge technology, so it should not be surprising that it has some caveats and isn’t always easy to do. The same could be said of trying to do reflection in Go, or garbage collection in C. These aren’t really the main use case for the tool.
Re: Why asynchronous Rust doesn't work
#9I don't know rust good enough but the article sounds like 'I can't write it like I want, therefore it's bad'.
Couldn't he just pass a named function instead of an anonymous one?
Re: Why asynchronous Rust doesn't work
#10I'm surprised Rust went with a Scala-inspired async/await considering it wasn't well-liked outside of PLT enthusiasts. JavaScript adopted it as I don't think you could bolt any other type of sugar on top of the event loop in browsers... but Rust shouldn't suffer from such baggage.
What's an alternative to async/await that's explicit about runtime costs?