Why asynchronous Rust doesn't work

[utterances-bot]

Why asynchronous Rust doesn't work

In 2017, I said that “asynchronous Rust programming is a disaster and a mess”. In 2021a lot more of the Rust ecosystem has become asynchronous – such that it...

https://theta.eu.org/2021/03/08/async-rust-2.html

[HadrienG2]

As you point out, a lot of the ergonomics issues of closures in Rust appear when they are long-lived (stored in structs, sent to other threads, etc), because now you have to think hard about all the lifetime calculus that the compiler would elide or otherwise handle for you in simple callback cases.

For multi-threaded work, this means that closures can be made a lot more ergonomic when abiding with a structured concurrency paradigm where no concurrent task is allowed to evade the current scope. See scoped threads in rayon and crossbeam if you are not familiar with the concept. The much-loved rayon parallel iterators are actually just a special case of it.

I wonder what currently prevents the async ecosystem from producing a good 99% solution that is as ergonomic as scoped threads are for threads. I suspect the need for long-lived framework-ish infrastructures (event loops, IO backends, etc) might be it, but am not sure.

[bocc]

I am also troubled by the fact that two closures with identical signatures are not considered identical by the type checker, so you can't eg. return closures from different match arms. (Although I'm sure there is a reason for this which I am unaware of.)

[koraa]

I pretty much agree with all your points: Async programming as it is today in rust is a mess and the lack of good support for closures is a sore point. Lot's of the paradigms in rust are borrowed from functional languages and being able to use a more functional style is one of the biggest advantages of rust for me…it is a sorry state of affairs that we are not able to use a functional style when coding in rust.

I would like to add the following: I've always looked at Rust as sort of the Breaking 2.0 Version of C++ twenty years later and as such benefits immensely from the mistakes that where made in C++. Templates/Generics, RAII, Move semantics, zero-cost-abstractions, smart pointers where all first tried in C++ and sometimes to questionable results. Rusts answers to the problems (use haskell style type classes, use RAII with a normal function as constructor, move by default, just use zero cost abstractions) are all the direct result of lessons learned in C++.

I think these mistakes had to be made at some point to make the innovations possible; doing async properly, as a zero cost abstraction, in the absence of garbage collection, in the absence of lazyness is something no other language truly attempted. Like javascript, we're going for syntax sugar without the typing depth a proper monadic system like in haskell provides. With the added difficulty of doing memory management explicitly…

This is a mistake, but since neither you nor I can provide the experience of what actually works in this regard, it's a mistake that needs to be made for a Rust 3.0 to do it properly.

[liquidev]

@bocc The reason for that is that if a closure captures different variables than another closure, its size changes. Eg. if a closure captures two variables x: i32 and y: i16, its size is going to be different than a closure that captures f: std::fs::File. You'd have to use a dyn T in this case.

[HadrienG2]

I am also troubled by the fact that two closures with identical signatures are not considered identical by the type checker, so you can't eg. return closures from different match arms. (Although I'm sure there is a reason for this which I am unaware of.)

Something like this has actually been proposed in the early days of futures and impl Trait, where people wanted to be able to return two different kinds of concrete types from a function returning impl Trait. But the Rust designers were uneasy about it at the time because it could not be made zero-cost, which means that making it too transparent would create a performance footgun.

To see why, remember that the difference between a function and a closure is that a closure can store state (references to variables in the surrounding scope, or moved/copied versions thereof). At the implementation level, it is like a struct holding that captured state. Every such struct is potentially unique because every closure captures potentially different state, so to store a closure, you need a variable whose type is specific to that closure.

If we wanted to store N different kinds of closures in a single variable, then we would need a type which can store N different kinds of concrete structs, i.e. an enum or a (boxed) trait object. Both of these abstractions have nontrivial overhead. Enums require discriminant checking and have a space overhead that's the maximum of the N stored types, whereas trait objects require memory allocation (in current Rust, there is work to relax this in selected cases in the future) and vtable indirection.

I personally think that given sufficiently loud syntax, this would still be accepted and become a nice language feature. But as usual, someone needs to put in the work of designing that loud syntax and resolving all the unforeseen edge cases that don't come up when one is just toying with a concept.

[HadrienG2]

@koraa While I very much agree with your general sentiment, I would just like to bounce back on a specific point...

Like javascript, we're going for syntax sugar without the typing depth a proper monadic system like in haskell provides.

Several prominent Rust designers have stated in the past that a monadic system designed like that of Haskell wouldn't work in Rust in their opinion. The pain points usually mentioned are...

• Without further constraints, higher-kinded types like Monad make type inference undecidable. The constraints used by Haskell, based on currying, would feel out of place in Rust, where currying is not commonly used.
• There are difficult interactions with the ownership, borrowing and lifetime system, common pain points being handling multiple kinds of references and (in the specific case of async and generators) correctly handling borrows across suspend and resume points without introducing avenues for memory unsafety.
• A monadic design makes it difficult to handle complex control flow, such as early returns or general loops. This is not usually a problem for functional programming languages, where such control flow is rare as it is almost always done for the purpose of mutating data or selectively avoiding side effects. But since Rust is a lot friendlier towards mutation, it feels more limiting there.
• There are a lot of API problems that Haskell solves with their local equivalent of a tree of boxed trait objects, rather than trying to produce maximally efficient state machine types, and this would feel like an uncomfortable amount of overhead in a performance-focused language like Rust.

Two particularly interesting recaps to read are:

• Niko Matsakis on HKTs like Monad in Rust : https://smallcultfollowing.com/babysteps/blog/2016/11/09/associated-type-constructors-part-4-unifying-atc-and-hkt/ (end of a series, with links to the previous posts)
• Withoutboats summarizing why async await cannot be easily replaced with monads and do notation : https://twitter.com/withoutboats/status/1027702531361857536 .

To be clear, I don't think this invalidates your overall point that there might be benefits to a more general-purpose abstraction here, but I think there's a reasonable amount of evidence that the designs that work for Haskell cannot be applied as-is to an imperative language like Rust or Javascript, especially when performance is a concern. The "clean" solution to async/await like problems in those languages may eventually turn out to be something completely different like some sort of generalized coroutine abstraction.

[DBJDBJ]

"... async has destroyed rust as a viable language for embedded, because trying to hide alot of the design has led to a fat runtime..."

That had precisely "destroyed" Rust as a viable language for system programing too (hint:OS).

[kazimuth]

e: on further reflection this article is pointless hacker news bait and i don't feel like participating here. Hope everybody enjoys the ongoing plagues and deadly climate events.

[jgarvin]

@aep I'm confused by the claim Rust has a fat runtime because Rust has no runtime. You can use async on embedded just fine? This enabled async for no_std.

[aep]

sorry, no energy for that, good luck with your embedded endeavors.

[nixomose]

the article mentions one of the problems caused by rust's general design, but I think one thing that everybody seems to gloss over, is the high level picture problem. programming languages exist as a tool to allow a human to convey a logic progression of steps to a microprocessor that can run them in the best (easiest, fastest, etc, what have you) way possible. If that were not true, we'd all be writing hexcodes in native machine language for our favorite processor. The language is supposed to be a tool for the human to make their job easier. And in my opinion, this, is where rust falls down. It tries to solve hard problems like dangling pointers but in trade has made simple things so hard, that it seems to me at least, counter productive. It would make more sense to write a much simpler language, and write tons of static analyzers to try and find places where you've gone wrong. By enforcing rules that you wouldn't normally need to follow just in case it might cause you to break the dangling pointer rule, is counter productive. async is just another example of that.

[MrTact]

It would make more sense to write a much simpler language, and write tons of static analyzers to try and find places where you've gone wrong.

You are literally describing how the Rust compiler works.

By enforcing rules that you wouldn't normally need to follow just in case it might cause you to break the dangling pointer rule, is counter productive.

Huh? If you have a pointer that you might not own, then you have a pointer you might not own! If the compiler allows you to manipulate it, then you are opening the door to derefing a null ptr at runtime. There's no way around this! (Or perhaps it's better to say, no one has yet come up with a better zero-cost solution than ownership.)

[nixomose]

Huh? If you have a pointer that you might not own, then you have a pointer you might not own! If the compiler allows you to manipulate it, then you are opening the door to derefing a null ptr at runtime. There's no way around this! (Or perhaps it's better to say, no one has yet come up with a better zero-cost solution than ownership.)

I didn't explain myself well. The point I was trying to get across was that the rules exist to solve a problem. but sometimes the rules force you to do things that you wouldn't need to do and still have safe code, but in order to make it possible to ensure that the compiler KNOWS its safe, it has to enforce these rules.
that's not a great explanation either, lemme try again. you can write a perfectly safe function that would not pass rust's rules because the rules exist to enforce a particular thing, and it drags other things down with it.

the problem being it creates a more restrictive environment than needs to exist to avoid problems, because it also keeps you from doing perfectly valid and safe things, just so it can be sure it's safe.
The ability to write code that does something useful that maybe the compiler can't prove is safe but actually is, is part of why humans are writing software and computers are not.

[HadrienG2]

@nixomose The static analysis false positive problem that you describe is the reason why Rust has unsafe features.

I think (but correct me if I'm wrong) that your point of disagreement with the language design here is how often unsafe blocks should be needed. Rust is designed under the assumption that after a period of cognitive training, you should reach the point where unsafe features are rarely needed in your everyday programming and you can do most of your work with the safe subset.

If you do reach this point, then the current Rust design is beneficial, because it greatly limits the codebase portion that you need to audit by hand in order to ensure safety properties, which means that when working on your code, you can usually free your mind from such concerns and focus on more important things.

If, on the other hand, you do not reach this point where unsafe is rarely needed, then the current Rust design will be frustrating, because it does not try hard to make unsafe ergonomic. To the contrary, it tries to make it a bit clumsy so that you avoid using it when not absolutely necessary, to help in the aforementioned training process.

For many people, it seems the tradeoff becomes beneficial after a couple of weeks/months of Rust use, but I can totally imagine that there are also other people for whom it won't ever work out.

[DBJDBJ]

"...Rust is designed under the assumption that after a period of cognitive training, you should reach the point ..."

1. Let us imagine there is a set of most useful programming languages.
2. Rust is not the language that most people will understand from that set.

The same applies to standard C++, Haskell, Lisp, etc ... that is a second set.

The third set is the first set minus the second set.

Feasible software development uses the languages from the third set. Whatever we (here) might think of them. Hint: C, zig, Swift, GO. And yes there are "things" like C#, Java, PHP, JavaScript, et all.

Increase the distance until you see the full picture.