[stevedonovan]

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.

[afavour]

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.

[nbittich]

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.

[marcosdumay]

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.

[virtualritz]

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.