I suppose async web servers is the poster child of async, and drove a lot of the development. However, then _everything_ went async, adding the cognitive overhead of dealing with Rust async throughout the ecosystem, whether needed or not.

In short, it still feels like a leaky abstraction: marvelous to look at working code, but errors (both compile and run-time) expose the underlying machinery underneath the syntactical sugar.

This is probably heresy, but as a former Rust dev I'm enjoying web-services in Go more these days.

I love Rust but I kind of agree. It’s really, really rare for a web service to need the low-level stuff Rust provides. A garbage collected is going to be just fine.

I hated async for months. Refused to touch it. Recently I tried it again. It (seems) way better now. Just avoid weird libraries like diesel & rocket, and everything works just as expected. I even wrote some generic code with async and surprisingly it works without me having to get a phd in type theory to please the compiler.

And if you want to make it async anyway, take a look at the abstractions a garbage collected language like Haskell can get you. (But well, the ones Go provide are probably more than enough already.)

Rust was not made for web development, and the fact that people keep creating frameworks and keep deciding they are good only shows how bad the usual practices are around the web.

Tbf Go was purpose-built for web services, while Rust was more a "oh I bet we could do that too, and they'd be crazy fast and stable!" The language hasn't bent itself to fit that shape like Go has, so it's not surprising the latter is a smoother experience overall

There are other applications, e.g. trading, where async is a godsent (monitoring hundreds of financial instrument for changes) but any sort of GC is prohibitive.

And where you also need the fine grained control that Rust provides.

E.g. halting all async tasks immediately while keeping a single core free to execute a trade as fast a possible.

Rocket.rs I believe

Rocket is moving towards async as well

Rocket is not moving anywhere right now. 0.5 supposed to be async, but it's delayed more than a year because maintainer doesn't have time.

You don't have to use async in Rocket v0.5.

I love Rouille: https://docs.rs/rouille/latest/rouille/

Is a thread per request scalable? Aren’t most of those threads just waiting for I/O? I guess thousands of concurrent requests via thousands of threads isn’t a big deal.

You mean at the application layer?

There never was any problem scaling things at the application layer. You can use almost any architecture there without issues. All the bottlenecks are elsewhere.

It's reasonably scalable. Operating system can deal with thousands of sleeping threads just fine. And I don't need more than that (on a single machine anyway).

Yes, you can run absolutely massive systems with very high throughput and high concurrency using only OS threads and "normal" synchronous programming, if done correctly. However it's generally a pain in the ass because most languages often have their own threading models that may have their own limitations or interaction-with-the-OS quirks, while in C or C++ you're typically on your own for like, all your dependencies including trivialities like thread pools and stuff. And all newer languages tend to instead design their I/O ecosystems around asynchronous stuff. So you have to choose your poison. But handling massive systems always requires a bit of special care anyway.

You will often encounter many other bottlenecks that hold your system back. There are other concerns like latency and utilization to care about. But assuming a purely "compute/IO" driven data plane, yes, you can scale synchronous APIs with threading quite far.

async is pretty efficient, no reason to ditch that.

It's just a pool of threads being used on demand.

The source of "complexity" according to the author is in using traits to make sure the middlewares are defined correctly.