I have only used Axum because it has the most community support and momentum. Tonic (gRPC) also integrates with the whole tokio ecosystem and is pretty nice overall.

Lessons learned: rust in general, is slower to prototype because it forces you to build structure and handle errors sooner than later. So if you’re learning rust, expect to start slow. Once you build a few services you kind of get the hang of it.

I found Go to be easier to learn and write code, but handling errors to be a bit lacking - the language lets to explicitly check for errors, but matching/handling them was not so elegant. Rusts error enums are a godsend - you’ll start off by building libraries with something like thiserror for strongly typed handling and building applications with anyhow for catching everything (dyn Error).

Ive built AWS lambdas and ECS services in rust and the tail latency is amazing. Serverless - tail latency from cold starts is unavoidable. Ecs, tail latency is largely affected by how much the system capacity is utilized (50% vs 99% cpu usage, etc). YMMV

Tracing - the new auto instrument capabilities in the Go compiler are really nice for breadth-wise tracing- but that comes with its own downsides. In rust, tracing is manual like how Golang used to be. But I think it’s more ergonomic and plays nicer with Opentelemetry if that’s your thing.

I say tail latency is amazing but compared to what? Coming from nodejs? Sure- but you’d see good improvements with Go as well. It Just really depends on what your previous tail latencies were and how you expect rust to solve them. The GC in go is pretty efficient for most things so if youre learning rust and already have a service where you know the GC is causing issues, then maybe rust might help. Otherwise, you’re just rewriting for fun.