[indiv0]

1. Don't use the `async` ecosystem.

2. Prefer dynamic dispatch to monomorphization (i.e., use fewer generics).

3. Don't use proc macros (i.e., don't depend on the `syn` crate, even transitively).

Easy to say; hard to put into practice. But that's all there is to it.

[fasterthanlime]

> Don't use the `async` ecosystem.

I want to make it /very/ clear that async isn't to blame at all for the pathological build times described here. It's a bug about traits and lifetimes, both very core concepts of Rust that you deal with even if you stay away from async code.

async rust will certainly be more ergonomic once some more improvements land (hopefully later this year), but I don't feel like it deserves all the sighs it's been publicly getting these past few months. (And I /love/ to complain. I've written pieces named "Surviving Rust async interface", "Getting in and out of trouble with Rust futures", "Pin and suffering", etc.)

> Prefer dynamic dispatch to monomorphization (i.e., use fewer generics).

Unless you hit a pathological case as shown in the article, it tends to not be _that_ bad, especially if you enable `-Z share-generics=y` (unstable still, yet enabled by default for debug builds if I remember correctly).

Overall still solid advice - although "use fewer generics" sometimes turns out to be "just turn a big generic type into `Box<dyn Trait>`" (it's not _just_ boxing, that would be `Box<T>`). That's what axum[1] does with all services, and it's never had the compile times issues warp[2] had, for example.

> Don't use proc macros (i.e., don't depend on the `syn` crate, even transitively).

Good news there, I hear there's some progress on the proc-macro bridge (which improves macro expansion performance) AND "wasm proc-macros". I hope this piece of advice will be completely irrelevant in a year (but for now, it's spot-on. using pin-project-lite instead of pin-project is worth it, for example).

[1] https://lib.rs/crates/axum

[2] https://lib.rs/crates/warp

[afdbcreid]

I know there about the bridge improvement (the amazing @nnethercote's work) but can you refer to sources on the wasm proc macros? The last thing I know about them is @dtolnay's watt.

In my experience, however, macros are usually not that problematic and `syn` is a one-time cost.

[vgel]

My understanding of point #2 is that LLVM may still try to devirtualize the call, which would reduce the performance impact -- is that true for Rust? I know it happens sometimes in C++.

Also for proc macros, rust-analyzer seems to struggle with them sometimes as well, so I try to avoid them (outside Serde, which is worth any price) for that reason.

[afdbcreid]

rust-analyzer for a long time expands all kinds of proc-macros. The only project it does not work (although to be honest I didn't really tried) is rustc.

[spekcular]

What forthcoming improvements to async are you referring to?

[staticassertion]

Or don't, because all of those things are great. Compile times aren't that bad unless you're doing a clean uncached build, which is very unlikely.

[aaaaaaaaaaab]

Async seems to be the first big "footgun" of Rust. It's widespread enough that you can't really avoid interacting with it, yet it's bad enough that it makes people resent the language.

[vgel]

It's really not as bad as it's made out to be. You can paint yourself into a corner with it, but a lot of that is that async is fundamentally more complicated than sync / threaded code, and there's only so much any language can do to paper that over. Rust exposes a lot of details, so it can be complicated to get to grips with how they combine with async in certain corner cases, but the happy path is quite happy even now.

A lot of the async Rust code I work with already looks like `async fn foo() -> ... { do_request().await?.blah().await }`, plus the occasional gathering of futures into a `Vec` to join on. That sort of thing, not much different from Javascript, but with a lot more control of the low-level details.

A good deal of corner cases should get better once async traits are stabilized, which will mean much less need for manually writing out Future types. But honestly, even now it's not that bad. I have a codebase that uses async to read hundreds of thousands of files[1], streaming gunzip them, pass them to another future which streaming parses records from them, and then pushes those parsed records into a `FnMut` closure for further non-async processing. It took a bit of thinking and design to get everything moving together nicely, but that corner of the codebase now is only ~200 lines of pretty straightforward code -- there's like 1 instance of `Unpin`. It's not that bad.

[1]: I know async isn't necessarily faster for reading files, but it started life doing network requests and it can still saturate a 200-core machine so I haven't felt the need to port it over to threads.

[fasterthanlime]

Quick aside: if you're willing to live the nightly life (unstable rustc), the `type_alias_impl_trait` feature gets you most of the way to "async trait methods". You still have to have a `Future` associated type, but in impl blocks, it just becomes `type Future = impl Future<Output = Blah>`, and then the compiler infers what the concrete (and probably unnameable, if you use async blocks) type is - no need to mess with `Pin<Box<T>>`.

The most egregious code comes when implementing one of the `AsyncRead`/`AsyncWrite` traits or similar, and that can come up a bunch in backend services, for example if you want to record metrics on how/when/where data flows, apply some limits etc. I'm curious how the ecosystem will adapt once async trait methods land for real.

[inferiorhuman]

FWIW I really don't like async in rust. It's improved significantly over the past couple years and it's nowhere near as bad as callback hell in Javascript but things still feel opaque. I've been toying around with a little monitoring agent (think Nagios or Sensu) to keep an eye on my defective LG fridge. So far I've managed to crash rustc twice. Trying to wrap my head around one library (that I was using incorrectly) I managed to "fork bomb" the damn thing and realize that I've little to no insight into the runtime. Try to find the current number of running tasks being managed by tokio…

The beauty of the rust async stuff is that you can move to a multi-threaded runtime as you desire with minimal effort.

[fasterthanlime]

> Try to find the current number of running tasks being managed by tokio…

As a heavy user of async Rust in production (at a couple places), resource leaks / lack of visibility into that has been a top issue.

In this area, tokio-console[1] is an exciting development. I have high hopes for it and adjacent tools in the future. (Instrumenting your app with tracing+opentelemetry stuff can help a lot, too).

Until those become featureful/mainstream enough, Go has the upper hand in terms of "figuring out what's going on in an async program at any given time".

[1]: https://lib.rs/crates/tokio-console

[inferiorhuman]

Okay that's really cool, I'm going to have to play around with it.

[oxff]

> The beauty of the rust async stuff is that you can move to a multi-threaded runtime as you desire with minimal effort.

This is also a downside, having multi-thread be the default and not single-thread. It introduces some awkward / accidental trait bounds that are annoying to deal with if you want to do thread-per-core type of stuff IIRC.

[verdagon]

I respectfully disagree; I don't think concurrency has to be that much more fundamentally complicated. It's likely that Rust's other design decisions are what made concurrency so difficult in Rust.

Pony does fearless concurrency better IMO, and Forty2 shows how we can expand on Pony to be faster and more flexible.

There are other approaches that have emerged recently too. For example, one can apply Loom's memory techniques to most memory management approaches to eliminate the coloring problem, to decouple functions from concurrency concerns.

There are also languages which separate threads' memory from each other which allows them to do non-atomic refcounting, relying on copying for any messages crossing thread boundaries (though that's often optimized away, and could be even less than Rust's clone()ing elsewhere).

One could also apply that technique to a language using generational references, if they want something without RC or tracing GC.

Sometimes I wish Rust waited just a few more years before going all-in on async/await. Alas!

[pcwalton]

> Pony does fearless concurrency better IMO

Pony is garbage collected. Most of the reasons why Rust async/await are the way it is boil down to the fact that Rust is memory safe without using GC.

> Forty2 shows how we can expand on Pony to be faster and more flexible

I can't tell from a glance, but that also looks garbage collected.

> For example, one can apply Loom's memory techniques to most memory management approaches to eliminate the coloring problem

Assuming you're referring to the JVM Project Loom, that's just M:N threading. This was tried in Rust almost a decade ago. Nobody used it because the performance was not appreciably better than 1:1 threading.

> There are also languages which separate threads' memory from each other which allows them to do non-atomic refcounting

You mean like Rust? Like, that's exactly why Rust can have both Rc and Arc and still be safe.

> relying on copying for any messages crossing thread boundaries (though that's often optimized away, and could be even less than Rust's clone()ing elsewhere).

Ancient Rust did this, but it was removed because with the current immutability and borrow checking rules there is no need for copying anymore. Why would you want copying if you don't need it?

I'm also not going to just accept that clone() could be faster. I mean, I'm sure the clone codegen could be improved by better register allocation or whatever, but I don't think that's what you mean.

> One could also apply that technique to a language using generational references, if they want something without RC or tracing GC.

Why would you want to copy if you don't have to?

> Sometimes I wish Rust waited just a few more years before going all-in on async/await. Alas!

I haven't seen anything here that is better than Rust's async/await, and a lot that's either worse or doesn't fit with the rest of Rust's design.

[vgel]

I'd push back on "concurrency so difficult in Rust" -- because async isn't the only, or even best, way to do concurrency in Rust. I prefer using threads when I can, and Rust makes working with threads quite joyful[1]. I'd cautiously agree that it's possible async wasn't the best model to go "all in" on, though Rust is quite happily multi-paradigm so if something better comes along and has a notably different set of optimal use-cases than threads or async, I wouldn't be surprised to see Rust adopt it as well.

I'm personally sort of skeptical about "color free async" because the models for sync/blocking IO and async IO are so different -- you can paper over the syntax differences, but you're going to be in a world of hurt when the semantic differences arise[2]. I'll admit I haven't tried a color-free async implementation myself though, so it's just speculation / sour grapes :-)

> There are also languages which separate threads' memory from each other which allows them to do non-atomic refcounting, relying on copying for any messages crossing thread boundaries (though that's often optimized away, and could be even less than Rust's clone()ing elsewhere).

Curious what you mean by this -- my understanding is that Rust also does this (i.e., you can `move |x|` a value into a thread and that thread owns it now, and then the thread can hand it back in a `JoinHandle`. That sort of sharing doesn't require an Arc or Mutex, since there's only one owner at a time. Is this something different?

[1]: The other day I turned something reading in files from the filesystem sequentially into a custom threadpool passing blocks of parsed JSON over a MPSC channel that exposed the whole thing as a sequential iterator and it worked first try. I almost didn't believe it until I wrote the tests.

[2]: E.g., "I wrote this and tested it with blocking IO but this syscall isn't supported by io_uring so in async mode it goes to a threadpool and passes some huge object in a message which kills perf with a huge memcpy", or some similar jank. Just spitballing on the type of thing I would fear happening, not a specific example.

[pcwalton]

The biggest problems with "colorless async" arise with FFI. You really can't abstract over the differences between a real OS mutex and a language mutex when you're interfacing with system libraries that expect locks to actually behave like locks. Otherwise it's a recipe for deadlocks.

[hgomersall]

I really dislike threads and now I've grokked async (which, granted, took effort), I much prefer that world. I just find the design of my system is much cleaner and more robust than anything I've written in threads.

[rowanG077]

Why is it a footgun? I have been using it and I didn't notice anything bad with it yet.

[tialaramex]

I think there's a terminology problem. To me a "footgun" is a feature which provides you with a very easy way to shoot yourself in the foot, hence the name. For example there's no way that the a[b] array index operation should default to not having bounds checks as it does in C and C++. That's a footgun. Rust does pretty well on this front, and I don't think async is especially worse.

But I can see Rust async being more of a gumption trap than many features. A gumption trap is a problem which uses up your motivation before you can work on the thing you actually wanted to do and so there's none left for the actual project.

[TylerE]

Isn’t that sort of the definition of a foot gun? That the downside/danger isn’t obvious.

[rowanG077]

Well only if the danger exists, obviously.

[tayo42]

How are people writing event loop based webservices with rust then if they're not using async?

[steveklabnik]

(I don't think async is bad.)

Some folks just use threads, no event loop.

Event loops are also there without async, you could just write against mio or whatever else you choose directly.