4 ms·
How so? It’s trivial to block on a Future or to call a function within a Future. I could imagine another language where all “functions” are Futures, but I don’
by skavi 2y ago
How so? It’s trivial to block on a Future or to call a function within a Future.
I could imagine another language where all “functions” are Futures, but I don’t think that would be the right move for Rust.
At the very least, that alternative language would probably have to provide a default executor. IMO, that’s a bit much for a language that aims to have a very minimal runtime.
- conradev 2y agoDoing that in Rust can be a footgun if the synchronous code blocks for too long. You often want a separate threadpool for calling those functions. It works great in Swift, though! Swift mitigates a lot of the function coloring pain: synchronous methods can conform to asynchronous protocol requirements, thanks to the compiler generating thunks (at least, I think that’s how it works)
- adastra22 2y agoA thunk wouldn't be zero-cost.
- skavi 2y agoOf course. But the common case of calling a synchronous function from a Future is something trivial like a + b.
- metaltyphoon 2y agoIsn’t this what spawn_blocking and block_in_place do?
- saagarjha 2y agoThe opposite, actually. Swift (Concurrency) doesn't really have a good way to do the kind of thing spawn_blocking does. (Though, some would argue that the very design of spawn_blocking is not good to begin with.)
- conradev 2y agoYes! In Swift there is no need to do this sort of differentiation, though, which is more ergonomic. Different trade-offs.
- adastra22 2y agoAs I mention in replies to sibling comments, Go works that way: every function is a Future, and there is no such thing as a non-async function. It works pretty well and is super easy to use and reason about, with no hard edges. Yes, it would have to provide a default executor in the standard library. And it would have to have a noasync mode (analogous to nostd) for embedded applications that can't have asynchronous execution. These are hurdles, but not very large ones. The ship has sailed though.
- skavi 2y agoA great bit about Rust async is that it’s sufficiently flexible for use in embedded environments. I would really not prefer a Rust that includes a more intrusive runtime. Especially given the API changes things like io-uring may require to exploit. As it works now, I can nearly always predict what assembly I’ll see when I compile a Rust program. It’s predictable enough to work anywhere C does. I would hate to lose that.
- arlort 2y agoThe other comment implied it but I think it's worth pointing out that: > embedded applications that can't have asynchronous execution Is most definitely not the case. They can't have the same type of async runtime that would be optimal for a web server or the likes (and I'm not sure all desktop applications and web servers are going to always benefit from the same runtime in the same way), but that's a point in favour of Rust's model imho If you're interested this is an embedded async runtime that's expected to run in no-std and no-alloc environments https://embassy.dev/ https://embassy.dev/