[sampullman]

I'm not so sure. I use Rust for simple web services now, when I would have used Python or JS/TS before, and the development speed isn't much different. The main draw is the language/type system/borrow checker, and reduced memory/compute usage is a nice bonus.

[aaronblohowiak]

Which framework? Do you write sync or async? I’ve AoC’d rust and really liked it but async seems a bit much.

[dsff3f3f3f]

Not the other poster but I moved from Go to Rust and the main packages I use for web services are axum, askama, serde and sqlx. Tokio and the futures crate are fleshed out enough now that I rarely run into async issues.

[sampullman]

That's pretty much where I'm at, plus a few basic packages for auth, caching, job/queue stuff. I can't remember the last time I had to care about async, but it does occasionally come up when dealing with things like background tasks.

I'm not totally happy with sqlx and the logging situation, but most issues that come up are the "solve once and never worry about it again" type.

[wtetzner]

I have to agree, despite using it a lot, async is the worst part of Rust.

If I had to do some of my projects over again, I'd probably just stick with synchronous Rust and thread pools.

The concept of async isn't that bad, but it's implementation in Rust feels rushed and incomplete.

For a language that puts so much emphasis on compile time checks to avoid runtime footguns, it's way too easy to clog the async runtime with blocking calls and not realize it.

[tayo42]

If he was OK with python performance limitations the rust without async is more then enough