Right but I'm doing that because those are frameworks in other languages which offer a comparable developer experience.

fasthttp isn't even a web framework. It's not surprising that using a raw HTTP library is dramatically faster than using a full framework and ORM but it's also not a sustainable way to build complex web applications with 1000+ developers.

You don't need to have 1000 developers working on the small performance sensitive part of your application though. Split it out into its own application, and then have a small dedicated team.

I can't speak to fasthttp as I haven't used Go much, but actix-web in Rust is a full framework (not as full as something like Rails, but certainly more than mature enough to be used for production projects).

I built and maintained a critical production web app using Iron for 3 years. Keeping anything like the performance advantage you see in simple benchmarks in a real app is a big challenge.

Well sure, that's why it only makes sense unless you actually need the performance. But if you do need the performance then implementing it in a language that is designed to enable those optimisations can make a lot more sense than trying to hack around the runtime in a slower language.