11 ms·

Async Rust never left the MVP state

446 points by pjmlp 6mo ago

hmry 6mo ago
Great article! Love these types of deep dives into optimizations. Hope the project goal works out! I've felt before that compilers often don't put much effort into optimizing the "trivial" cases. Overly dramatic title for the content, though. I would have clicked "Async Rust Optimizations the Compiler Still Misses" too you know
- Animats 6mo ago
  Agree on title. Too dramatic. The author seems to be obsessing about the overhead for trivial functions. He's bothered by overhead for states for "panicked" and "returned". That's not a big problem. Most useful async blocks are big enough that the overhead for the error cases disappears. He may have a point about lack of inlining. But what tends to limit capacity for large numbers of activities is the state space required per activity.
  - molf 6mo ago
    > Most useful async blocks are big enough that the overhead for the error cases disappears. Is it really though? In my experience many Rust applications/libraries can be quite heavy on the indirection. One of the points from the article is that contrary to sync Rust, in async Rust each indirection has a runtime cost. Example from the article: async fn bar(blah: SomeType) -> OtherType { foo(blah).await } I would naively expect the above to be a 'free' indirection, paying only a compile-time cost for the compiler to inline the code. But after reading the article I understand this is not true, and it has a runtime cost as well.
  - swiftcoder 6mo ago
    > Most useful async blocks are big enough that the overhead for the error cases disappears. Most useful async blocks are deeply nested, so the overhead compounds rapidly. Check the size of futures in a decently large Tokio codebase sometime
  - dathinab 6mo ago
    > Agree on title. Too dramatic. not just too dramatic given that all the things they list are non essential optimizations, and some fall under "micro optimizations I wouldn't be sure rust even wants", and given how far the current async is away from it's old MVP state, it's more like outright dishonest then overly dramatic like the kind of click bait which is saying the author does cares neither about respecting the reader nor cares about honest communication, which for someone wanting to do open source contributions is kinda ... not so clever through in general I agree rust should have more HIR/MIR optimizations, at least in release mode. E.g. its very common that a async function is not pub and in all places directly awaited (or other wise can be proven to only be called once), in that case neither `Returned` nor `Panicked` is needed, as it can't be called again after either. Similar `Unresumed` is not needed either as you can directly call the code up to the first await (and with such a transform their points about "inlining" and "asyncfns without await still having a state machine" would also "just go away"TM, at least in some places.). Similar the whole `.map_or(a,b)` family of functions is IMHO a anti-pattern, introducing more function with unclear operator ordering and removal of the signaling `unwrap_` and no benefits outside of minimal shortening a `.map(b).unwrap_or(a)` and some micro opt. is ... not productive on a already complicated language. Instead guaranteed optimizations for the kind of patterns a `.map(b).unwrap_or(a)` inline to would be much better.
  - algesten 6mo ago
    He's optimizing for embedded no-std situation. These things do matter in constrained environments.
    - Animats 6mo ago
      He briefly mentions microcontrollers, but doesn't go into details. That might make sense, for microcontrollers which implement some kind of protocol talking to something.
  - repelsteeltje 6mo ago
    > [...] That's not a big problem [...] Depends somewhat on your expectations, I suppose. Compared to Python, Java, sure, but Rust off course strives to offer "zero-cost" high level concepts. I think the critique is in the same realm of C++'s std::function. Convenience, sure, but far from zero-cost.
    - pjmlp 6mo ago
      To the point it got replaced by std::function_ref() in C++26.
      - repelsteeltje 6mo ago
        Exactly. And I guess that is also the gist of the article: async Rust needs additional TLC.
  - selfhoster1312 6mo ago
    In my experience, it's not uncommon to have an async trait method for which many implementations are actually synchronous. For example, different tables in your DB need to perform some calculations, but only some tables reference other tables. In that case, the method needs to be async and take a handle to the DB as parameter, but many table entries can perform the calculation on their own without using the handle (or any async operation). This may look like a case of over-optimization, but given how many times i've seen this pattern, i assume it builds up to a lot of unnecessary fluff in huge codebases. To be clear, in that case, the concern is not really about runtime speed (which is super fast), but rather about code bloat for compilation time and binary size.
- diondokter 6mo ago
  So on the title, I picked this because it's simply the truth. Since async landed in 2019 or so, not much has changed. Yes, we can have async in traits and closures now. But those are updates to the typesystem, not to the async machinery itself. Wakers are a little bit easier to work with, but that's an update to std/core. As I understand it, the people who landed async Rust were quite burnt out and got less active and no one has picked up the torch. (Though there's 1 PR open from some google folk that will optimize how captured variables are laid out in memory, which is really nice to have) Since I and the people I work with are heavy async users, I think it's maybe up to me to do it or at least start it. Free as in puppy I guess. So yeah, the title is a little baitey, but I do stand behind it.
  - mplanchard 6mo ago
    Some of the burnout no doubt being due to the catastrophizing of every decision by the community and the extreme rhetoric used across the board. Great to see people wanting to get involved with the project, though. That’s the beauty of open source: if it aggravates you, you can fix it.
    - selfhoster1312 6mo ago
      As an example of this, i remember a huge debate at the time about `await foo()` vs `foo().await` syntax. The community was really divided on that one, and there was a lot of drama because that's the kind of design decision you can't really walk back from. Retrospectively, i think everyone is satisfied with the adopted syntax.
      - jurgenburgen 6mo ago
        > Retrospectively, i think everyone is satisfied with the adopted syntax. Maybe it’s a case of agree and commit, since it can’t really be walked back.
        diondokter 6mo ago
        Various prominent people have said years after that .await was the correct choice after all
groundzeros2015 6mo ago
Async seems like an underbaked idea across the board. Regular code was already async. When you need to wait for an async operation, the thread sleeps until ready and the kernel abstracts it away. But We didn’t like structuring code into logical threads, so we added callback systems for events. Then realized callbacks are very hard to reason about and that sequential control is better. So threads was the right programming model. Now language runtimes prefer “green threads” for portability and performance but most languages don’t provide that properly. Instead we have awkward coloring of async/non-async and all these problems around scheduling, priority, and no-preemption. It’s a worse scheduling and process model than 1970.
- swiftcoder 6mo ago
  > So threads was the right programming model. For problems that aren't overly concerned with performance/memory, yes. You should probably reach for threads as a default, unless you know a priori that your problem is not in this common bucket. Unfortunately there is quite a lot of bookkeeping overhead in the kernel for threads, and context switches are fairly expensive, so in a number of high performance scenarios we may not be able to afford kernel threading
  - groundzeros2015 6mo ago
    In that sentence I’m referring to the abstract idea of a thread of execution as a model of programming, not OS threads. A green thread implementation could do it too. But what you said about kernel implementation is true. But are we really saying that the primary motivation for async/await is performance? How many programmers would give that answer? How many programs are actually hitting that bottleneck? Doesn’t that buck the trend of every other language development in the past 20 years, emphasizing correctness and expressively over raw performance?
    - swiftcoder 6mo ago
      > But are we really saying that the primary motivation for async/await is performance? The original motivation for not using OS threads was indeed performance. Async/await is mostly syntax sugar to fix some of the ergonomic problems of writing continuation-based code (Rust more or less skipped the intermediate "callback hell" with futures that Javascript/Python et al suffered through).
slopinthebag 6mo ago
It's so funny that people will do anything to hate on Rust, including nitpicking a few bytes of overhead for a future while they reach for an entire thread or runtime to handle async in their favourite language.
- MrBuddyCasino 6mo ago
  Nobody seriously tries to run Golang or Java on an MCU. But they do run Rust code.
  - ok123456 6mo ago
    J2ME existed before most of the current crop of Rust programmers were born.
    - MrBuddyCasino 6mo ago
      Which doesn't work on low-end MCUs even in the CLDC profile (< 16 bit, < 32k ram, < 160k rom) and is dead since 2007, proving my point that nobody wants to run it.
- rnijveld 6mo ago
  You realize this article talks about Rust on embedded hardware specifically, where you don’t have threads or big runtimes? There is no hate going on here either, just attempts to make things better. Might I suggest you click through to the homepage and I think you’ll figure out the rest.
- lionkor 6mo ago
  It's more that I and people I know love Rust, and enjoy it, and want it to be better. I want it to be relentlessly optimized.
- berkes 6mo ago
  I know the people and the company behind this article. They do anything but "hate on Rust". You could've deduced that from the fact that someone who puts this amount of energy in a detailed article about intricacies of an area of "foo", quite certainly does not "hate on foo".
hacker_homie 6mo ago
This is the type of ugly but necessary discussions that have been happening in c++ for a while. I never really liked the viral nature of async in rust when it was introduced. I wish rust the best of luck and with more people like this rust could have a brighter future.
conaclos 6mo ago
I recently started working with Rust async. The main issue I am currently facing is code duplication: I have to duplicate every function that I want to support both asynchronous and blocking APIs. This could be great to have a `maybe-async`. I took a look at the available crates to work around this (maybe-async, bisync), but they all have issues or hard limitations.
- albertzeyer 6mo ago
  The classic function coloring problem. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
- small_scombrus 6mo ago
  It'll depend immensely on what you're actually doing, but if it's simple enough you may be able to make a macro that subs out the types & awaits
  - conaclos 6mo ago
    One of the issue I face is a blocking function that takes a generic constrained by a `trait` and its async version takes a generic constrained by an `async trait`.
- K0nserv 6mo ago
  There is work happening on keyword generics[0], which would let a function be generic over keywords like `async` and `const`. For now the best option to write code that wants to live in both worlds is sans-io. Thomas Eizinger at Fireguard has written a good article about this[1] pattern. Not only does it nicely solve the sync/async issue, but it also makes testing easier and opens the door to techniques like DST[2] I have my own writing on the topic[3], which highlights that the problem is wider than just async vs sync due to different executors. 0: https://github.com/rust-lang/effects-initiative https://github.com/rust-lang/effects-initiative 1: https://www.firezone.dev/blog/sans-io https://www.firezone.dev/blog/sans-io 2: https://notes.eatonphil.com/2024-08-20-deterministic-simulation-testing.html https://notes.eatonphil.com/2024-08-20-deterministic-simulat... 3: https://hugotunius.se/2024/03/08/on-async-rust.html https://hugotunius.se/2024/03/08/on-async-rust.html
forrestthewoods 6mo ago
Love Rust. They simply missed the mark with async. Swing and a miss. The risk they took was very calculated. Unfortunately they’re bad at math and chose the wrong trade-offs. Ah well. Shit happens.
- lionkor 6mo ago
  I think Rust has a pretty solid async implementation, compared to other systems languages. I struggle to point out another systems language with a working and actually used async implementation.
- swiftcoder 6mo ago
  > Unfortunately they’re bad at math and chose the wrong trade-offs They chose the exact same tradeoffs as C++'s async/await (and the same overall model as Python/NodeJS), so I'm not sure what that says about programming as a whole.
  - nromiun 6mo ago
    Async in Rust and C++ is nothing like it is in Python or NodeJS. Choose your own runtime is a very different model than having a default one. Not to mention Tokio (most popular runtime for Rust) is multi-threaded by default. So you have to deal with multithreading bugs as well as normal async ones. That is not the case with most async languages. For example both Python and NodeJS use a single thread to execute async code.
    - swiftcoder 6mo ago
      > Async in Rust and C++ is nothing like it is in Python or NodeJS. Choose your own runtime is a very different model than having a default one. Python still has pluggable eventloops - this is sort of mandatory to interact with weird things like GUI toolkits, and Python's standard event loop was standardised pretty late in the game. Early on there was even an ecosystem split between Twisted and competing event loops implementations. > For example both Python and NodeJS use a single thread to execute async code I'd argue this is more a historical artefact of how the languages functioned before futures were introduced, rather than an inherent limitation.
ozgrakkurt 6mo ago
Does this kind of thing make noticeable difference when applied to more complicated async functions? Examples in the blog seem too simple make any conclusions
- diondokter 6mo ago
  Hi, author here. I mention in the blog that I've tried to quickly hack two of the simplest optimizations in the compiler and it resulted in 2%-5% binary size savings in real embedded (async) codebases. And a quick and probably deeply flawed synthetic benchmark on the desktop showed a 3% perf increase. So yes, it does really matter. Keep in mind that optimizations stack. We're preventing LLVM from doing it's thing. So if we make the futures themselves smaller, LLVM will be able to optimize more. So small changes really compound.
  - ozgrakkurt 6mo ago
    Saw that but couldn't find what code it gives that improvement on. Is it some embedded application written with Embassy?
    - diondokter 6mo ago
      Yes, but I can't share the codebases since they're our client's and proprietary. But there aren't a lot of big embedded codebases that are also open source
      - ozgrakkurt 6mo ago
        Got it, thanks
DeathArrow 6mo ago
I like it more how Zig is approaching async with the new IO. It avoids function coloring.
- simonask 6mo ago
  Does it, though? Whether your function has the `async` keyword attached or has a function argument of type `IO` doesn't really change anything substantial. The whole "function color" argument seems pretty overblown to me. You can't call `foo(int, string)` if you don't have both an int and a string, so is it now a different "color" than the function `bar(int)`? If you want to call `foo` from `bar`, you have to somehow procure a string, and the same is true for `IO` in Zig, and the same is true for async in Rust, where what you have to procure is an async executor. The `async` keyword can be seen as syntactic sugar for introducing a hidden function parameter (very literally, it's called `&mut std::task::Context`), as well as rewriting the function as a state machine.
  - fwip 6mo ago
    Yeah, I tend to agree. What does improve quality-of-life substantially is having a proper effect system, especially when it comes to composing higher-order functions. Having to write copies of List.map and List.async_map in the stdlib is a smell, but the real cost is potentially having to duplicate every function in your code that calls either. E.g, if you have the 'async' effect, List.map can work with async functions or synchronous ones, without modification. It's the caller's responsibility to provide that async handler/environment at whatever level of abstraction makes sense, instead of explicitly wiring IO or async all the way through for a function that may or may not need it. The compiler (or runtime, if necessary) will keep you from calling a function that requires the async effect if you don't have a handler for it.
    - simonask 6mo ago
      I agree that `async` and other “effects” (we could also mention const, unsafe, etc.) are not very composable in present-day Rust. I will note, though, that this particular example (iterating over a list asynchronously) is actually where you might really want to do something else, because async allows you to do something fundamentally different: run all in parallel. Async really shines when you have code that does two or more things and you don’t care about the order in which they finish, and that isn’t really feasible without it.
InfinityByTen 6mo ago
I like this article already because it took me to the goals of Rust for 2026. We use the language in our team, but we haven't needed to go very deep to do the stuff we need. Yet, I really enjoy witnessing the development of a language from ground up with so much community feedback. I somehow miss noticing that in C++ and I have no idea how it is working in other domains. My only gripe is that a lot of it is feeling a bit kick-starter-y, with each of the goals needing specific funding. Is that the best model we've found so far?
- repelsteeltje 6mo ago
  > I somehow miss noticing that in C++ and I have no idea how it is working in other domains. There seems to be some consensus even within the C++ ISO committee that the evolution process of that language is somewhat broken, mostly due to its size and the way it is organized. > My only gripe is that a lot of it is feeling a bit kick-starter-y, with each of the goals needing specific funding. Is that the best model we've found so far? Sadly, this seems to be the way things go once a technology catches on, commercially. Can't blame large donors for sponsoring only the parts they are interested in. Fortunately, considerable funding of TweedeGolf comes from (Dutch) government, I think.
- diondokter 6mo ago
  In open source I guess there's two types of work: 1. features 2. maintenance You can 'sell' new features. They cost money to create, but they solve real problems. Those problems also cost money and if that's more than the cost of creating the feature, companies are willing to put in money (generally). Maintenance is harder. But there are now some maintainer funds! Like the one from RustNL: https://rustnl.org/maintainers/ https://rustnl.org/maintainers/ These are broader ongoing work and backed by many orgs chipping in a little bit. Idk if it's the best model, but at least it seems to kinda work
- NobodyNada 6mo ago
  > My only gripe is that a lot of it is feeling a bit kick-starter-y IMO the term "project goals" is quite misleading for what this actually is. A project goal is a system for one person (or a small group of people) to express that they'd like to work on something and ask for Rust project volunteers to commit ongoing time and effort to supporting them through code review, answering questions, etc. It doesn't mean that the Rust project itself has set the goal, or even necessarily endorsed it. So it's not quite right to treat it as a formal roadmap for Rust, just a "there are some contributors interested in working on these areas".
feverzsj 6mo ago
There are much more problems, like async drop.
ignoreusernames 6mo ago
Agree with the other commenters that the title is a bit too dramatic. The content was well written and got the point across. I still don’t have enough experience to have a strong opinion on Rust async, but some things did standout. On the good side, it’s nice being able to have explicit runtimes. Instead of polluting the whole project to be async, you can do the opposite. Be sync first and use the runtime on IO “edges”. This was a great fit to a project that I’m working on and it seems like a pretty similar strategy to what zig is doing with IO code. This largely solved the function colloring problem in this particular case. Strict separation of IO and CPU bound code was a requirement regardless of the async stuff, so using the explicit IO runtime was natural. On the bad side, it seems crazy to me how much the whole ecosystem depends on tokio. It’s almost like Java’s GC was optional, but in practice everyone just used the same third party GC runtime and pulling any library forced you to just use that runtime. This sort of central dependency is simply not healthy.
- selfhoster1312 6mo ago
  What's the alternative? I'm happy to use tokio, but i'm happy other folks can enjoy other executors (smol, async-std, glommio, etc). I think the situation is OK because tokio is well-maintained, even though it's not part of the standard library, and i'm afraid making it part of the standard library would make it harder to use other executors, and harder to port the standard library to other platforms. But maybe my fears are unfounded.
  - ignoreusernames 6mo ago
    As of now I don’t think there’s an alternative. I’m not a Rust expert but the core issue to me is that “async” goes beyond just having a Futures scheduler. Async stuff usually needs network, disk, os interaction, future utilities(spawn) and these are all things the runtime (tokio) provides. It’s pretty hard to be compatible with each other unless the language itself provides those.
    - turdinthemouth 6mo ago
      That's not the core issue at all it's lifetimes and allocations.
whazor 6mo ago
Async Rust on small embedded chips like ESP32 feels revolutionary. This project looks promising.
Havoc 6mo ago
This has been on my mind lately too with the talk of the new CPUs. Zen 7 sounds like it'll be a beast & coding against 1 out of dozens of cores would be a pity
micoul81 6mo ago
great article
_alphageek 6mo ago
The duplicate-state collapse (hoisting the match out of the await branches like in his process_command example) is the single easiest pattern anyone can apply to existing async code today. No compiler work needed, just a refactor.
- zozbot234 6mo ago
  At the very least, you'd want to have a custom lint that can surface the places where it's applicable. That's pretty close to compiler work.
jagged-chisel 6mo ago
Response to title: so you’re saying it’s viable
Panzerschrek 6mo ago
> Futures aren't (trivially) inlined In my programming language I wrote custom pass for inlining async function calls within other async functions. It generally works and allows to remove some boilerplate, but it increases result binary size a lot. Technically Rust can do the same.
emilfihlman 6mo ago
Rust is a passing faux, safe C will just overtake it.
dragochat 6mo ago
what's the modern "absolute beginner's guide to async in Rust" - ideally something dense that can bring someone motivated from beginner to expert in ~1 week of intense hacking on it?
- lame_lexem 6mo ago
  there is a chapter on async in comprehensive rust and rustbook which ought to bring you up to speed there is the async book but it is largely unfinished you can watch John Gjengset's crust of rust async, decrusting tokio, and why what, and how of pinning in rust then there are tokio-lessons and tokio tutorial which teach how to use tokio runtime and there are also good blogposts by phil-oop and rose wright on how async works https://doc.rust-lang.org/book/ch17-00-async-await.html https://doc.rust-lang.org/book/ch17-00-async-await.html https://google.github.io/comprehensive-rust/concurrency/welcome-async.html https://google.github.io/comprehensive-rust/concurrency/welc... https://rust-lang.github.io/async-book/intro.html https://rust-lang.github.io/async-book/intro.html https://youtu.be/ThjvMReOXYM https://youtu.be/ThjvMReOXYM https://youtu.be/o2ob8zkeq2s https://youtu.be/o2ob8zkeq2s https://youtu.be/DkMwYxfSYNQ https://youtu.be/DkMwYxfSYNQ https://github.com/freddiehaddad/tokio-lessons https://github.com/freddiehaddad/tokio-lessons https://tokio.rs/tokio/tutorial https://tokio.rs/tokio/tutorial https://os.phil-opp.com/async-await/ https://os.phil-opp.com/async-await/ https://dev.to/rosewrightdev/from-futures-to-runtimes-how-async-rust-actually-works-4gec https://dev.to/rosewrightdev/from-futures-to-runtimes-how-as...
- dana321 6mo ago
  It doesn't take a week to learn the async basics. add async keyword to functions add .await when calling them use tokio in your main function (easy to look up) use the async recursion crate if you need to use recursion but don't want to box everything There are some bonuses like calling functions in parallel, but there you go.
  - usrnm 6mo ago
    And then you want to do something trivial like an async callback
alexchamberlain 6mo ago
It seems like inlining futures that aren't holding variables over the await point might solve a large part of these issues?
robmccoll 6mo ago
Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me. Nearly every time I call a function I don't want to have to care if it is synchronous or not. I want the syntax and grammar (and illusion?) of one continuous thread of execution. The few times where I explicitly want to not wait are the places that should be special. This is why new languages should build in green threading from the start.
- j16sdiz 6mo ago
  What you want is quite the opposite of what rust is -- rust force rules. Look at how the borrow works. Most of the time, the compiler can _suggest_ the fix.. and instead of fixing that silently, they want you to fix it. This is the design choice they made.
- aw1621107 6mo ago
  > Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me. Technically speaking Rust didn't have to use a keyword (and in fact didn't for quite some time between 1.0 and when async was added), but the ergonomics of the library-based keyword-less solutions was considered to be less than optimal compared to building in support to the language. > This is why new languages should build in green threading from the start. This, just like most other decisions one can make when designing a language, is a tradeoff. Green threads have their niceties for sure, but they also have drawbacks which made them a nonstarter for what the point in the design space the Rust devs were aiming for. In particular, the Rust devs wanted something that did not require overhead for FFI and also did not require foreign code to know that something async-related is involved. Green threads don't work here because they either have overhead when copying stuff between the green thread stack and the foreign stack or need foreign code to understand how to handle the green thread stack.
- tremon 6mo ago
  > I want the syntax and grammar (and illusion?) of one continuous thread of execution Then you shouldn't be using a low-level systems language? You can simply choose a higher-level abstraction language that better matches your programming preferences.
phplovesong 6mo ago
Async rust is a big wart in the language. There was this one guy posting about "i want off Gos wild ride" a few years back, but IIRC he never considered just how bad async rust is. I will take Go concurrency over rust async any day of the week.
amluto 6mo ago
async fn bar(input: u32) -> i32 { let blah = input > 10; // Preamble let result = foo(blah).await; result * 2 // Postamble } > If only we were allowed to execute the code up to the first await point, then we could get rid of the Unresumed state. But "futures don't do anything unless polled" is guaranteed, so we can't change that. Is that actually valid reasoning? If we know that foo(blah) doesn’t do “anything” until polled, then why can’t bar call foo without polling it before foo itself is polled? After all, there’s no “anything” that will happen.
- mahkoh 6mo ago
  Because foo might call process::abort().
  - amluto 6mo ago
    I disagree. If the codegen / optimizer is trying to preserve the rule that futures don’t have side effects until polled, then it seems fine to assume that the future being wrapped also follows that rule. So if I call a foo() that violates the rule, it seems odd to complain that the generated bar() also violates it.
    - deleted 6mo ago
      [deleted]
satvikpendem 6mo ago
Rust in my opinion needs an algebraic effects system to truly fix the function coloring problem. We have OCaml 5 which has one in production as well as a few other languages like Koka experimenting with it but hopefully we can add that to Rust as well. I'm not sure how the keyword generics initiative is going though, haven't heard any news on that.
grougnax 6mo ago
Async Rust is still better than any language async feature.
- yarn_ 6mo ago
  sad but true
J_Shelby_J 6mo ago
I don’t understand why Rust even has panics if its primary goal is safety. We should be able to prove that the code has no paths that may panic ever. I’ve been looking at this all week. It’s very difficult to make a program that is guaranteed not to panic. My understanding is that the panic handler is about 300kb, and the only way to exclude it is if your code has no paths that can panic when it compiles. And after it compiles you can check the binary to see if the panic handler was included. It’s hacky. Yes you can lint out unwraps and other panic operations, but if there was a subset of no-panic rust a large part of the issue detailed in this post goes away. But it’s frustrating working with a language that has so many operations that can, in theory, panic even if in practice they should only do so if a bit flips. Like a proving an array is non-empty or working with async. You either end up with a lot of error handling for situations which will never happen or really strange patterns like non-empty list pattern (structure with first field and then your list). Which of course ends up adding its own bloat.
- dodobirdlord 6mo ago
  Panicking is fairly important for ergonomics and safety. If panicking wasn’t available and execution had to proceed in all situations, recovering from a situation like memory corruption where invariants have been violated would require a lot of error handling anywhere an invariant is checked. This is exactly the sort of large amounts of error handling for situations that will almost certainly never arise than you are concerned about.
- zozbot234 6mo ago
  > I don’t understand why Rust even has panics if its primary goal is safety. We should be able to prove that the code has no paths that may panic ever. I’ve been looking at this all week. It’s very difficult to make a program that is guaranteed not to panic. The Rust-in-Linux folks are working on this with things like failable memory operations. It's required for their own use. Increased use of proof (such as proving that an array is non-empty) is also being slowly worked on.
- positron26 6mo ago
  The OS running the program isn't even perfect. I tire so much of complainers who want someone else to make all their tools infallible yet want to do nothing. Let's just full-stop there. They not only want to avoid working on the tools. They prefer if the tool does everything for them, and they prefer having things done for them without bound. Complainers want easy APIs. When the API isn't easy enough, they want easy Kubernetes containers "programmed" by YAML. When that isn't easy enough, it's all point-and-click hosted services on GCP and Amazon. You people don't want to program. You want apps. Infallable apps. You want to be consumers, fed from the sky like little birds who endeavor only never to fledge, never to fly. And you want to pay nothing for it. The secret you people need to figure out is that the lifestyle you think is sustainable is actually a commensal relationship with people building things for you. There is no vast alliance to wrest power from corporations, to dissolve capitalism, no grass roots movement to "shake things up." There is food falling from higher in the water column from an ecosystem filled with people who do things. Those above do not have time to look down, but if they did, all they would feel is overwhelming contempt, so they only look across at the horizon. But why do people seek to confirm comments like this? Because Rust scary. Churn on, little ant mill. Let be free any who understand the pointlessness of this performance.
oxag3n 6mo ago
If you read documentation around Rust Async and Tokio, you'll find proper explanation why CPU intensive parts should not be part of async stack, how to use primitives efficiently (like std::sync::Mutex in async blocks), how to glue sync and async code. A lot of code doesn't follow there guidelines because they don't care about efficiency and don't need it. But there are numerous projects who care about performance and efficiency, and realize the pitfalls once code runs in production (ScyllaDB is one example). LLMs don't help as well, generating everything async up to the main, using wrong primitives and not properly designing the system.
appz3 6mo ago
[dead]
lacymorrow 6mo ago
[dead]
UltraSane 6mo ago
Rust's ownership model is perfect for threading yet it went all in on async
danborn26 6mo ago
Async Rust still feels incredibly complex for typical use cases. The ecosystem fragmentation around executors makes it harder than it needs to be.

446 points by pjmlp 6mo ago

hmry 6mo ago

Great article! Love these types of deep dives into optimizations. Hope the project goal works out! I've felt before that compilers often don't put much effort into optimizing the "trivial" cases. Overly dramatic title for the content, though. I would have clicked "Async Rust Optimizations the Compiler Still Misses" too you know

Animats 6mo ago
Agree on title. Too dramatic. The author seems to be obsessing about the overhead for trivial functions. He's bothered by overhead for states for "panicked" and "returned". That's not a big problem. Most useful async blocks are big enough that the overhead for the error cases disappears. He may have a point about lack of inlining. But what tends to limit capacity for large numbers of activities is the state space required per activity.
- molf 6mo ago
  > Most useful async blocks are big enough that the overhead for the error cases disappears. Is it really though? In my experience many Rust applications/libraries can be quite heavy on the indirection. One of the points from the article is that contrary to sync Rust, in async Rust each indirection has a runtime cost. Example from the article: async fn bar(blah: SomeType) -> OtherType { foo(blah).await } I would naively expect the above to be a 'free' indirection, paying only a compile-time cost for the compiler to inline the code. But after reading the article I understand this is not true, and it has a runtime cost as well.
- swiftcoder 6mo ago
  > Most useful async blocks are big enough that the overhead for the error cases disappears. Most useful async blocks are deeply nested, so the overhead compounds rapidly. Check the size of futures in a decently large Tokio codebase sometime
- dathinab 6mo ago
  > Agree on title. Too dramatic. not just too dramatic given that all the things they list are non essential optimizations, and some fall under "micro optimizations I wouldn't be sure rust even wants", and given how far the current async is away from it's old MVP state, it's more like outright dishonest then overly dramatic like the kind of click bait which is saying the author does cares neither about respecting the reader nor cares about honest communication, which for someone wanting to do open source contributions is kinda ... not so clever through in general I agree rust should have more HIR/MIR optimizations, at least in release mode. E.g. its very common that a async function is not pub and in all places directly awaited (or other wise can be proven to only be called once), in that case neither `Returned` nor `Panicked` is needed, as it can't be called again after either. Similar `Unresumed` is not needed either as you can directly call the code up to the first await (and with such a transform their points about "inlining" and "asyncfns without await still having a state machine" would also "just go away"TM, at least in some places.). Similar the whole `.map_or(a,b)` family of functions is IMHO a anti-pattern, introducing more function with unclear operator ordering and removal of the signaling `unwrap_` and no benefits outside of minimal shortening a `.map(b).unwrap_or(a)` and some micro opt. is ... not productive on a already complicated language. Instead guaranteed optimizations for the kind of patterns a `.map(b).unwrap_or(a)` inline to would be much better.
- algesten 6mo ago
  He's optimizing for embedded no-std situation. These things do matter in constrained environments.
  - Animats 6mo ago
    He briefly mentions microcontrollers, but doesn't go into details. That might make sense, for microcontrollers which implement some kind of protocol talking to something.
- repelsteeltje 6mo ago
  > [...] That's not a big problem [...] Depends somewhat on your expectations, I suppose. Compared to Python, Java, sure, but Rust off course strives to offer "zero-cost" high level concepts. I think the critique is in the same realm of C++'s std::function. Convenience, sure, but far from zero-cost.
  - pjmlp 6mo ago
    To the point it got replaced by std::function_ref() in C++26.
    - repelsteeltje 6mo ago
      Exactly. And I guess that is also the gist of the article: async Rust needs additional TLC.
- selfhoster1312 6mo ago
  In my experience, it's not uncommon to have an async trait method for which many implementations are actually synchronous. For example, different tables in your DB need to perform some calculations, but only some tables reference other tables. In that case, the method needs to be async and take a handle to the DB as parameter, but many table entries can perform the calculation on their own without using the handle (or any async operation). This may look like a case of over-optimization, but given how many times i've seen this pattern, i assume it builds up to a lot of unnecessary fluff in huge codebases. To be clear, in that case, the concern is not really about runtime speed (which is super fast), but rather about code bloat for compilation time and binary size.
diondokter 6mo ago
So on the title, I picked this because it's simply the truth. Since async landed in 2019 or so, not much has changed. Yes, we can have async in traits and closures now. But those are updates to the typesystem, not to the async machinery itself. Wakers are a little bit easier to work with, but that's an update to std/core. As I understand it, the people who landed async Rust were quite burnt out and got less active and no one has picked up the torch. (Though there's 1 PR open from some google folk that will optimize how captured variables are laid out in memory, which is really nice to have) Since I and the people I work with are heavy async users, I think it's maybe up to me to do it or at least start it. Free as in puppy I guess. So yeah, the title is a little baitey, but I do stand behind it.
- mplanchard 6mo ago
  Some of the burnout no doubt being due to the catastrophizing of every decision by the community and the extreme rhetoric used across the board. Great to see people wanting to get involved with the project, though. That’s the beauty of open source: if it aggravates you, you can fix it.
  - selfhoster1312 6mo ago
    As an example of this, i remember a huge debate at the time about `await foo()` vs `foo().await` syntax. The community was really divided on that one, and there was a lot of drama because that's the kind of design decision you can't really walk back from. Retrospectively, i think everyone is satisfied with the adopted syntax.
    - jurgenburgen 6mo ago
      > Retrospectively, i think everyone is satisfied with the adopted syntax. Maybe it’s a case of agree and commit, since it can’t really be walked back.
      - diondokter 6mo ago
        Various prominent people have said years after that .await was the correct choice after all

groundzeros2015 6mo ago

Async seems like an underbaked idea across the board. Regular code was already async. When you need to wait for an async operation, the thread sleeps until ready and the kernel abstracts it away. But We didn’t like structuring code into logical threads, so we added callback systems for events. Then realized callbacks are very hard to reason about and that sequential control is better. So threads was the right programming model. Now language runtimes prefer “green threads” for portability and performance but most languages don’t provide that properly. Instead we have awkward coloring of async/non-async and all these problems around scheduling, priority, and no-preemption. It’s a worse scheduling and process model than 1970.

swiftcoder 6mo ago
> So threads was the right programming model. For problems that aren't overly concerned with performance/memory, yes. You should probably reach for threads as a default, unless you know a priori that your problem is not in this common bucket. Unfortunately there is quite a lot of bookkeeping overhead in the kernel for threads, and context switches are fairly expensive, so in a number of high performance scenarios we may not be able to afford kernel threading
- groundzeros2015 6mo ago
  In that sentence I’m referring to the abstract idea of a thread of execution as a model of programming, not OS threads. A green thread implementation could do it too. But what you said about kernel implementation is true. But are we really saying that the primary motivation for async/await is performance? How many programmers would give that answer? How many programs are actually hitting that bottleneck? Doesn’t that buck the trend of every other language development in the past 20 years, emphasizing correctness and expressively over raw performance?
  - swiftcoder 6mo ago
    > But are we really saying that the primary motivation for async/await is performance? The original motivation for not using OS threads was indeed performance. Async/await is mostly syntax sugar to fix some of the ergonomic problems of writing continuation-based code (Rust more or less skipped the intermediate "callback hell" with futures that Javascript/Python et al suffered through).

slopinthebag 6mo ago

It's so funny that people will do anything to hate on Rust, including nitpicking a few bytes of overhead for a future while they reach for an entire thread or runtime to handle async in their favourite language.

MrBuddyCasino 6mo ago
Nobody seriously tries to run Golang or Java on an MCU. But they do run Rust code.
- ok123456 6mo ago
  J2ME existed before most of the current crop of Rust programmers were born.
  - MrBuddyCasino 6mo ago
    Which doesn't work on low-end MCUs even in the CLDC profile (< 16 bit, < 32k ram, < 160k rom) and is dead since 2007, proving my point that nobody wants to run it.
rnijveld 6mo ago
You realize this article talks about Rust on embedded hardware specifically, where you don’t have threads or big runtimes? There is no hate going on here either, just attempts to make things better. Might I suggest you click through to the homepage and I think you’ll figure out the rest.
lionkor 6mo ago
It's more that I and people I know love Rust, and enjoy it, and want it to be better. I want it to be relentlessly optimized.
berkes 6mo ago
I know the people and the company behind this article. They do anything but "hate on Rust". You could've deduced that from the fact that someone who puts this amount of energy in a detailed article about intricacies of an area of "foo", quite certainly does not "hate on foo".

hacker_homie 6mo ago

This is the type of ugly but necessary discussions that have been happening in c++ for a while. I never really liked the viral nature of async in rust when it was introduced. I wish rust the best of luck and with more people like this rust could have a brighter future.

conaclos 6mo ago

I recently started working with Rust async. The main issue I am currently facing is code duplication: I have to duplicate every function that I want to support both asynchronous and blocking APIs. This could be great to have a `maybe-async`. I took a look at the available crates to work around this (maybe-async, bisync), but they all have issues or hard limitations.

albertzeyer 6mo ago
The classic function coloring problem. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
small_scombrus 6mo ago
It'll depend immensely on what you're actually doing, but if it's simple enough you may be able to make a macro that subs out the types & awaits
- conaclos 6mo ago
  One of the issue I face is a blocking function that takes a generic constrained by a `trait` and its async version takes a generic constrained by an `async trait`.
K0nserv 6mo ago
There is work happening on keyword generics[0], which would let a function be generic over keywords like `async` and `const`. For now the best option to write code that wants to live in both worlds is sans-io. Thomas Eizinger at Fireguard has written a good article about this[1] pattern. Not only does it nicely solve the sync/async issue, but it also makes testing easier and opens the door to techniques like DST[2] I have my own writing on the topic[3], which highlights that the problem is wider than just async vs sync due to different executors. 0: https://github.com/rust-lang/effects-initiative https://github.com/rust-lang/effects-initiative 1: https://www.firezone.dev/blog/sans-io https://www.firezone.dev/blog/sans-io 2: https://notes.eatonphil.com/2024-08-20-deterministic-simulation-testing.html https://notes.eatonphil.com/2024-08-20-deterministic-simulat... 3: https://hugotunius.se/2024/03/08/on-async-rust.html https://hugotunius.se/2024/03/08/on-async-rust.html

forrestthewoods 6mo ago

Love Rust. They simply missed the mark with async. Swing and a miss. The risk they took was very calculated. Unfortunately they’re bad at math and chose the wrong trade-offs. Ah well. Shit happens.

lionkor 6mo ago
I think Rust has a pretty solid async implementation, compared to other systems languages. I struggle to point out another systems language with a working and actually used async implementation.
swiftcoder 6mo ago
> Unfortunately they’re bad at math and chose the wrong trade-offs They chose the exact same tradeoffs as C++'s async/await (and the same overall model as Python/NodeJS), so I'm not sure what that says about programming as a whole.
- nromiun 6mo ago
  Async in Rust and C++ is nothing like it is in Python or NodeJS. Choose your own runtime is a very different model than having a default one. Not to mention Tokio (most popular runtime for Rust) is multi-threaded by default. So you have to deal with multithreading bugs as well as normal async ones. That is not the case with most async languages. For example both Python and NodeJS use a single thread to execute async code.
  - swiftcoder 6mo ago
    > Async in Rust and C++ is nothing like it is in Python or NodeJS. Choose your own runtime is a very different model than having a default one. Python still has pluggable eventloops - this is sort of mandatory to interact with weird things like GUI toolkits, and Python's standard event loop was standardised pretty late in the game. Early on there was even an ecosystem split between Twisted and competing event loops implementations. > For example both Python and NodeJS use a single thread to execute async code I'd argue this is more a historical artefact of how the languages functioned before futures were introduced, rather than an inherent limitation.

ozgrakkurt 6mo ago

Does this kind of thing make noticeable difference when applied to more complicated async functions? Examples in the blog seem too simple make any conclusions

diondokter 6mo ago
Hi, author here. I mention in the blog that I've tried to quickly hack two of the simplest optimizations in the compiler and it resulted in 2%-5% binary size savings in real embedded (async) codebases. And a quick and probably deeply flawed synthetic benchmark on the desktop showed a 3% perf increase. So yes, it does really matter. Keep in mind that optimizations stack. We're preventing LLVM from doing it's thing. So if we make the futures themselves smaller, LLVM will be able to optimize more. So small changes really compound.
- ozgrakkurt 6mo ago
  Saw that but couldn't find what code it gives that improvement on. Is it some embedded application written with Embassy?
  - diondokter 6mo ago
    Yes, but I can't share the codebases since they're our client's and proprietary. But there aren't a lot of big embedded codebases that are also open source
    - ozgrakkurt 6mo ago
      Got it, thanks

DeathArrow 6mo ago

I like it more how Zig is approaching async with the new IO. It avoids function coloring.

simonask 6mo ago
Does it, though? Whether your function has the `async` keyword attached or has a function argument of type `IO` doesn't really change anything substantial. The whole "function color" argument seems pretty overblown to me. You can't call `foo(int, string)` if you don't have both an int and a string, so is it now a different "color" than the function `bar(int)`? If you want to call `foo` from `bar`, you have to somehow procure a string, and the same is true for `IO` in Zig, and the same is true for async in Rust, where what you have to procure is an async executor. The `async` keyword can be seen as syntactic sugar for introducing a hidden function parameter (very literally, it's called `&mut std::task::Context`), as well as rewriting the function as a state machine.
- fwip 6mo ago
  Yeah, I tend to agree. What does improve quality-of-life substantially is having a proper effect system, especially when it comes to composing higher-order functions. Having to write copies of List.map and List.async_map in the stdlib is a smell, but the real cost is potentially having to duplicate every function in your code that calls either. E.g, if you have the 'async' effect, List.map can work with async functions or synchronous ones, without modification. It's the caller's responsibility to provide that async handler/environment at whatever level of abstraction makes sense, instead of explicitly wiring IO or async all the way through for a function that may or may not need it. The compiler (or runtime, if necessary) will keep you from calling a function that requires the async effect if you don't have a handler for it.
  - simonask 6mo ago
    I agree that `async` and other “effects” (we could also mention const, unsafe, etc.) are not very composable in present-day Rust. I will note, though, that this particular example (iterating over a list asynchronously) is actually where you might really want to do something else, because async allows you to do something fundamentally different: run all in parallel. Async really shines when you have code that does two or more things and you don’t care about the order in which they finish, and that isn’t really feasible without it.

InfinityByTen 6mo ago

I like this article already because it took me to the goals of Rust for 2026. We use the language in our team, but we haven't needed to go very deep to do the stuff we need. Yet, I really enjoy witnessing the development of a language from ground up with so much community feedback. I somehow miss noticing that in C++ and I have no idea how it is working in other domains. My only gripe is that a lot of it is feeling a bit kick-starter-y, with each of the goals needing specific funding. Is that the best model we've found so far?

repelsteeltje 6mo ago
> I somehow miss noticing that in C++ and I have no idea how it is working in other domains. There seems to be some consensus even within the C++ ISO committee that the evolution process of that language is somewhat broken, mostly due to its size and the way it is organized. > My only gripe is that a lot of it is feeling a bit kick-starter-y, with each of the goals needing specific funding. Is that the best model we've found so far? Sadly, this seems to be the way things go once a technology catches on, commercially. Can't blame large donors for sponsoring only the parts they are interested in. Fortunately, considerable funding of TweedeGolf comes from (Dutch) government, I think.
diondokter 6mo ago
In open source I guess there's two types of work: 1. features 2. maintenance You can 'sell' new features. They cost money to create, but they solve real problems. Those problems also cost money and if that's more than the cost of creating the feature, companies are willing to put in money (generally). Maintenance is harder. But there are now some maintainer funds! Like the one from RustNL: https://rustnl.org/maintainers/ https://rustnl.org/maintainers/ These are broader ongoing work and backed by many orgs chipping in a little bit. Idk if it's the best model, but at least it seems to kinda work
NobodyNada 6mo ago
> My only gripe is that a lot of it is feeling a bit kick-starter-y IMO the term "project goals" is quite misleading for what this actually is. A project goal is a system for one person (or a small group of people) to express that they'd like to work on something and ask for Rust project volunteers to commit ongoing time and effort to supporting them through code review, answering questions, etc. It doesn't mean that the Rust project itself has set the goal, or even necessarily endorsed it. So it's not quite right to treat it as a formal roadmap for Rust, just a "there are some contributors interested in working on these areas".

feverzsj 6mo ago

There are much more problems, like async drop.

ignoreusernames 6mo ago

Agree with the other commenters that the title is a bit too dramatic. The content was well written and got the point across. I still don’t have enough experience to have a strong opinion on Rust async, but some things did standout. On the good side, it’s nice being able to have explicit runtimes. Instead of polluting the whole project to be async, you can do the opposite. Be sync first and use the runtime on IO “edges”. This was a great fit to a project that I’m working on and it seems like a pretty similar strategy to what zig is doing with IO code. This largely solved the function colloring problem in this particular case. Strict separation of IO and CPU bound code was a requirement regardless of the async stuff, so using the explicit IO runtime was natural. On the bad side, it seems crazy to me how much the whole ecosystem depends on tokio. It’s almost like Java’s GC was optional, but in practice everyone just used the same third party GC runtime and pulling any library forced you to just use that runtime. This sort of central dependency is simply not healthy.

selfhoster1312 6mo ago
What's the alternative? I'm happy to use tokio, but i'm happy other folks can enjoy other executors (smol, async-std, glommio, etc). I think the situation is OK because tokio is well-maintained, even though it's not part of the standard library, and i'm afraid making it part of the standard library would make it harder to use other executors, and harder to port the standard library to other platforms. But maybe my fears are unfounded.
- ignoreusernames 6mo ago
  As of now I don’t think there’s an alternative. I’m not a Rust expert but the core issue to me is that “async” goes beyond just having a Futures scheduler. Async stuff usually needs network, disk, os interaction, future utilities(spawn) and these are all things the runtime (tokio) provides. It’s pretty hard to be compatible with each other unless the language itself provides those.
  - turdinthemouth 6mo ago
    That's not the core issue at all it's lifetimes and allocations.

whazor 6mo ago

Async Rust on small embedded chips like ESP32 feels revolutionary. This project looks promising.

Havoc 6mo ago

This has been on my mind lately too with the talk of the new CPUs. Zen 7 sounds like it'll be a beast & coding against 1 out of dozens of cores would be a pity

micoul81 6mo ago

great article

_alphageek 6mo ago

The duplicate-state collapse (hoisting the match out of the await branches like in his process_command example) is the single easiest pattern anyone can apply to existing async code today. No compiler work needed, just a refactor.

zozbot234 6mo ago
At the very least, you'd want to have a custom lint that can surface the places where it's applicable. That's pretty close to compiler work.

jagged-chisel 6mo ago

Response to title: so you’re saying it’s viable

Panzerschrek 6mo ago

> Futures aren't (trivially) inlined In my programming language I wrote custom pass for inlining async function calls within other async functions. It generally works and allows to remove some boilerplate, but it increases result binary size a lot. Technically Rust can do the same.

emilfihlman 6mo ago

Rust is a passing faux, safe C will just overtake it.

dragochat 6mo ago

what's the modern "absolute beginner's guide to async in Rust" - ideally something dense that can bring someone motivated from beginner to expert in ~1 week of intense hacking on it?

lame_lexem 6mo ago
there is a chapter on async in comprehensive rust and rustbook which ought to bring you up to speed there is the async book but it is largely unfinished you can watch John Gjengset's crust of rust async, decrusting tokio, and why what, and how of pinning in rust then there are tokio-lessons and tokio tutorial which teach how to use tokio runtime and there are also good blogposts by phil-oop and rose wright on how async works https://doc.rust-lang.org/book/ch17-00-async-await.html https://doc.rust-lang.org/book/ch17-00-async-await.html https://google.github.io/comprehensive-rust/concurrency/welcome-async.html https://google.github.io/comprehensive-rust/concurrency/welc... https://rust-lang.github.io/async-book/intro.html https://rust-lang.github.io/async-book/intro.html https://youtu.be/ThjvMReOXYM https://youtu.be/ThjvMReOXYM https://youtu.be/o2ob8zkeq2s https://youtu.be/o2ob8zkeq2s https://youtu.be/DkMwYxfSYNQ https://youtu.be/DkMwYxfSYNQ https://github.com/freddiehaddad/tokio-lessons https://github.com/freddiehaddad/tokio-lessons https://tokio.rs/tokio/tutorial https://tokio.rs/tokio/tutorial https://os.phil-opp.com/async-await/ https://os.phil-opp.com/async-await/ https://dev.to/rosewrightdev/from-futures-to-runtimes-how-async-rust-actually-works-4gec https://dev.to/rosewrightdev/from-futures-to-runtimes-how-as...
dana321 6mo ago
It doesn't take a week to learn the async basics. add async keyword to functions add .await when calling them use tokio in your main function (easy to look up) use the async recursion crate if you need to use recursion but don't want to box everything There are some bonuses like calling functions in parallel, but there you go.
- usrnm 6mo ago
  And then you want to do something trivial like an async callback

alexchamberlain 6mo ago

It seems like inlining futures that aren't holding variables over the await point might solve a large part of these issues?

robmccoll 6mo ago

Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me. Nearly every time I call a function I don't want to have to care if it is synchronous or not. I want the syntax and grammar (and illusion?) of one continuous thread of execution. The few times where I explicitly want to not wait are the places that should be special. This is why new languages should build in green threading from the start.

j16sdiz 6mo ago
What you want is quite the opposite of what rust is -- rust force rules. Look at how the borrow works. Most of the time, the compiler can _suggest_ the fix.. and instead of fixing that silently, they want you to fix it. This is the design choice they made.
aw1621107 6mo ago
> Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me. Technically speaking Rust didn't have to use a keyword (and in fact didn't for quite some time between 1.0 and when async was added), but the ergonomics of the library-based keyword-less solutions was considered to be less than optimal compared to building in support to the language. > This is why new languages should build in green threading from the start. This, just like most other decisions one can make when designing a language, is a tradeoff. Green threads have their niceties for sure, but they also have drawbacks which made them a nonstarter for what the point in the design space the Rust devs were aiming for. In particular, the Rust devs wanted something that did not require overhead for FFI and also did not require foreign code to know that something async-related is involved. Green threads don't work here because they either have overhead when copying stuff between the green thread stack and the foreign stack or need foreign code to understand how to handle the green thread stack.
tremon 6mo ago
> I want the syntax and grammar (and illusion?) of one continuous thread of execution Then you shouldn't be using a low-level systems language? You can simply choose a higher-level abstraction language that better matches your programming preferences.

phplovesong 6mo ago

Async rust is a big wart in the language. There was this one guy posting about "i want off Gos wild ride" a few years back, but IIRC he never considered just how bad async rust is. I will take Go concurrency over rust async any day of the week.

amluto 6mo ago

async fn bar(input: u32) -> i32 { let blah = input > 10; // Preamble let result = foo(blah).await; result * 2 // Postamble } > If only we were allowed to execute the code up to the first await point, then we could get rid of the Unresumed state. But "futures don't do anything unless polled" is guaranteed, so we can't change that. Is that actually valid reasoning? If we know that foo(blah) doesn’t do “anything” until polled, then why can’t bar call foo without polling it before foo itself is polled? After all, there’s no “anything” that will happen.

mahkoh 6mo ago
Because foo might call process::abort().
- amluto 6mo ago
  I disagree. If the codegen / optimizer is trying to preserve the rule that futures don’t have side effects until polled, then it seems fine to assume that the future being wrapped also follows that rule. So if I call a foo() that violates the rule, it seems odd to complain that the generated bar() also violates it.
  - deleted 6mo ago
    [deleted]

satvikpendem 6mo ago

Rust in my opinion needs an algebraic effects system to truly fix the function coloring problem. We have OCaml 5 which has one in production as well as a few other languages like Koka experimenting with it but hopefully we can add that to Rust as well. I'm not sure how the keyword generics initiative is going though, haven't heard any news on that.

grougnax 6mo ago

Async Rust is still better than any language async feature.

yarn_ 6mo ago
sad but true

J_Shelby_J 6mo ago

I don’t understand why Rust even has panics if its primary goal is safety. We should be able to prove that the code has no paths that may panic ever. I’ve been looking at this all week. It’s very difficult to make a program that is guaranteed not to panic. My understanding is that the panic handler is about 300kb, and the only way to exclude it is if your code has no paths that can panic when it compiles. And after it compiles you can check the binary to see if the panic handler was included. It’s hacky. Yes you can lint out unwraps and other panic operations, but if there was a subset of no-panic rust a large part of the issue detailed in this post goes away. But it’s frustrating working with a language that has so many operations that can, in theory, panic even if in practice they should only do so if a bit flips. Like a proving an array is non-empty or working with async. You either end up with a lot of error handling for situations which will never happen or really strange patterns like non-empty list pattern (structure with first field and then your list). Which of course ends up adding its own bloat.

dodobirdlord 6mo ago
Panicking is fairly important for ergonomics and safety. If panicking wasn’t available and execution had to proceed in all situations, recovering from a situation like memory corruption where invariants have been violated would require a lot of error handling anywhere an invariant is checked. This is exactly the sort of large amounts of error handling for situations that will almost certainly never arise than you are concerned about.
zozbot234 6mo ago
> I don’t understand why Rust even has panics if its primary goal is safety. We should be able to prove that the code has no paths that may panic ever. I’ve been looking at this all week. It’s very difficult to make a program that is guaranteed not to panic. The Rust-in-Linux folks are working on this with things like failable memory operations. It's required for their own use. Increased use of proof (such as proving that an array is non-empty) is also being slowly worked on.
positron26 6mo ago
The OS running the program isn't even perfect. I tire so much of complainers who want someone else to make all their tools infallible yet want to do nothing. Let's just full-stop there. They not only want to avoid working on the tools. They prefer if the tool does everything for them, and they prefer having things done for them without bound. Complainers want easy APIs. When the API isn't easy enough, they want easy Kubernetes containers "programmed" by YAML. When that isn't easy enough, it's all point-and-click hosted services on GCP and Amazon. You people don't want to program. You want apps. Infallable apps. You want to be consumers, fed from the sky like little birds who endeavor only never to fledge, never to fly. And you want to pay nothing for it. The secret you people need to figure out is that the lifestyle you think is sustainable is actually a commensal relationship with people building things for you. There is no vast alliance to wrest power from corporations, to dissolve capitalism, no grass roots movement to "shake things up." There is food falling from higher in the water column from an ecosystem filled with people who do things. Those above do not have time to look down, but if they did, all they would feel is overwhelming contempt, so they only look across at the horizon. But why do people seek to confirm comments like this? Because Rust scary. Churn on, little ant mill. Let be free any who understand the pointlessness of this performance.

oxag3n 6mo ago

If you read documentation around Rust Async and Tokio, you'll find proper explanation why CPU intensive parts should not be part of async stack, how to use primitives efficiently (like std::sync::Mutex in async blocks), how to glue sync and async code. A lot of code doesn't follow there guidelines because they don't care about efficiency and don't need it. But there are numerous projects who care about performance and efficiency, and realize the pitfalls once code runs in production (ScyllaDB is one example). LLMs don't help as well, generating everything async up to the main, using wrong primitives and not properly designing the system.

appz3 6mo ago

[dead]

lacymorrow 6mo ago

[dead]

UltraSane 6mo ago

Rust's ownership model is perfect for threading yet it went all in on async

danborn26 6mo ago

Async Rust still feels incredibly complex for typical use cases. The ecosystem fragmentation around executors makes it harder than it needs to be.