3 ms·

Now, I think async is bad syntactic sugar that hides what's really going on under the surface. And I rail against it all the time. Especially the way dropping i

Now, I think async is bad syntactic sugar that hides what's really going on under the surface. And I rail against it all the time. Especially the way dropping in async contaminates code bases by building tendrils across call-sites all through the application. ... But the tools that have been built around it are very useful and there's some good stuff there. I have some quibbles with this article: "Rust comes at this problem with an “async/await” model" No, it does not. It allows for that, and there's a big ... community ... around the async stuff, but in reality the language is entirely fine with operating using explicit concurrency constructs. And in fact for most applications I think standard synchronous functions combined with communicating channels is cleaner. I work in code bases that do both, and I find the explicit approach easier to reason about. In the end, Async is something people ideally reach for only after they hit the wall with blocking on I/O. But in reality they're often reaching for it just because -- either because it's cool... or because some framework they are relying on mandates it. But I think the pendulum will swing back the other way at some point. I don't think it's fair to tar the whole language with it.

lionkor 3y ago
> It allows for that This is like saying C++ allows for templates, and theres a big community around it. Sure, but its the entire community.
- cmrdporcupine 3y ago
  If you're a web facing developer and looking at web services, then I guess you could think this about Rust. Believe it or not, there's other types of things being built in Rust. Systems work, which I think Rust is more appropriate for.
- marcosdumay 3y ago
  Almost all Rust libraries just don't deal with concurrency at all. Maybe async is the most popular concurrency construct there (I have no idea). But the entire population here is small.
- jeroenhd 3y ago
  Practically speaking: the only libraries I regularly use that demand me to use async stuff are HTTP clients, and those have optional blocking imports. I still need to sprinkle [tokio::main] in front of the entry point, but from that point on, everything is blocking. I don't think it's "the entire community" at all. Dealing with futures across library calls is a pain and almost every library that can avoid it, will avoid it. I try to avoid async code because of its annoying pain points and I rarely see any circumstances where spawning a new thread doesn't work. Sure, there's more overhead, and you need some kind of limiting factor to prevent spawning a billion of them, but async isn't really required in most circumstances. It's like saying Go allows for generics. Very few people and libraries bother with them. Working with them is kind of a pain. They're there jf you want to use them, but you generally don't.

lionkor 3y ago

> It allows for that This is like saying C++ allows for templates, and theres a big community around it. Sure, but its the entire community.

cmrdporcupine 3y ago
If you're a web facing developer and looking at web services, then I guess you could think this about Rust. Believe it or not, there's other types of things being built in Rust. Systems work, which I think Rust is more appropriate for.
marcosdumay 3y ago
Almost all Rust libraries just don't deal with concurrency at all. Maybe async is the most popular concurrency construct there (I have no idea). But the entire population here is small.
jeroenhd 3y ago
Practically speaking: the only libraries I regularly use that demand me to use async stuff are HTTP clients, and those have optional blocking imports. I still need to sprinkle [tokio::main] in front of the entry point, but from that point on, everything is blocking. I don't think it's "the entire community" at all. Dealing with futures across library calls is a pain and almost every library that can avoid it, will avoid it. I try to avoid async code because of its annoying pain points and I rarely see any circumstances where spawning a new thread doesn't work. Sure, there's more overhead, and you need some kind of limiting factor to prevent spawning a billion of them, but async isn't really required in most circumstances. It's like saying Go allows for generics. Very few people and libraries bother with them. Working with them is kind of a pain. They're there jf you want to use them, but you generally don't.