If you have thousands of rubyists then you surely have hundreds who also know other languages? Seems to make sense to use a fast langauage for the small performance sensitive part of your codebase.
Seems also that since Ruby is not going to be taught as part of people's normal formal education in programming, you can expect Rubyists to be on average more capable of... learning new things.
So yes, "re-train". Give everyone a book on the new language, maybe pay for some online courses from pluralsight or wherever, cancel meetings for a week. You can learn a lot faster than in a school environment when you've got paid 8 hour days to put into a single subject + coworkers to chat with.
Besides, it's not like they don't get to avoid learning new things anyway, even if you restrict it to the Ruby ecosystem. In the JS world (which I'm sure they all know too, as one tends to when working on web sites even if you're mostly back-end) as new revisions of the language come out people have to keep up with the syntax and changing idioms.
"For some reason, programmers love to learn new stuff, as long as it's
not syntax."
-- Steve Yegge
"Faster" languages often have big advantages in small benchmarks which get a lot smaller or even reverse once you're looking at whole application performance.
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.
