3 ms·
The syntax isn't the problem. The syntax is fine: I've never had a serious problem with Rust's async syntax, and the language has been and continues to remove
by topspin 3y ago
The syntax isn't the problem. The syntax is fine: I've never had a serious problem with Rust's async syntax, and the language has been and continues to remove the papercuts that have emerged since async appeared.
The thing about async Rust that absolutely destroys my efforts with it is the legion of problems involving dependencies and their async runtime peculiarities.
As a result I've had to set Rust aside for most things where I'd otherwise love to employ it. I can't risk losing days to some tangle of an async runtime compatibility snafu. The one area that Rust has really astonished me recently is embedded Rust and MCUs: the ecosystem there is still young, but the results that can be produced with Rust in embedded development are really astonishing.
Of course, there is typically no async runtime involved at that level, so problem solved...
- _ahxg 3y ago> I can't risk losing days to some tangle of an async runtime compatibility snafu. At this point in time, if you use Tokio, won't basically everything mainstream work? At least that has been my experience so far.
- pornel 3y agoThe pain only exists if you're trying not to use Tokio that has 90% "market share" of Rust runtimes. I get that it is sometimes needed (if you use GTK or browser JS as your async runtime, or write your own executor). But for majority users there is only one runtime and there's no compatibility problem. Tokio won, and network effects killed everything else. Think of it like Golang's choice of runtimes (there isn't one).
- p4ul 3y agoThis is my impression, too! The door is open for other async runtimes, but for the majority of us, Tokio is the solution. And that's been just fine for me!