I'd instinctively worry about overhead there
Are there benchmarks comparing sync http libraries with block_on-wrapped async http libraries?
Are there benchmarks comparing sync http libraries with block_on-wrapped async http libraries?
Yeah, one of the nice things about blocking I/O is that you can perform it with a single syscall. With block_on(async_io), you're now dealing with registration with a reactor, polling epoll, and extra syscalls for each I/O operation. Not to mention the overhead of running the state-machine as opposed to line by line.
95% of what I write isn't performance-critical or even, really, performance-relevant. I still choose Rust for the vast majority of projects for ergonomic and correctness reasons.
Swift comes closest with codable/decodable but it's often still lacking the ergonomics of serde, especially the attribute options per field
A lot of people come to rust for other reasons, like compile time safety checks etc...
But most importantly, the delta between the performance of block_on and not, versus block_on and Python are massively different. You can write inefficient rust and still have a huge win over Python.