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.

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.

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.

Rocket is moving towards async as well