I think the problem is that many people seem to think of rust as a back end language to begin with. And while there are crates that aim at that, the big problem

I think the problem is that many people seem to think of rust as a back end language to begin with. And while there are crates that aim at that, the big problem there is that rust itself is not meant for that and it is simply bad at it. Rust is a systems language and this is where it shines. I'm currently using it for micro controllers and sensors and it is a perfect fit in this space. It genuinely feels like someone has given me a set of precision tools after doing everything with sticks and stones in the form of C. The reason why I think it's a bad choice for back end is not because of the limited ecosystem either. Take actix for example. In order to handle resources, your codebase inevitably becomes a huge pile of Arc<Mutex<_>> and Arc<RwLock<_>>s and mpsc's and sooner rather then later this end up biting back, most commonly in the form of an endless rabbit hole of read/write locks. And when I first saw sync/await in the rfcs, that's exactly what I feared would happen. Tokio is another elephant in the room that needs to be addressed: a ton of crates depend on different and completely incompatible versions of it. Most people get this wrong when they get overexcited about rust. And then there are those who get it right. Full disclosure, I haven't tried it or gone through the source code but InfluxDB IOx seems like a perfect choice for rust and a good use case for async/awaits.