That’s also my question after reading this post. When trying to shave off milliseconds by going for a full rewrite, moving away from ruby seems like an obvious decision...at least intuitively..
Yeah. Consider that BigCos end up writing transpilers and new runtimes for their target platforms before rewriting the application, which would entail discarding the decades of built-in bugfixes and application logic as well as reconstructing the organization around a different platform -- HipHop for PHP, Grumpy, etc. A language change is no small thing in any company of appreciable size.
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.
Sentry (otherwise a Python application) built their Symbolicator service in Rust because it was a better fit for the domain. Probably also because Armin Ronacher has become a fan of the language and simply wanted to [1]. Now, Sentry is like 100 employees or something, so it's obviously a way more agile organization that Shopify at 10x the size, but having more limited resources is also a reason to avoid spreading yourself too thin.
Their monolith was written in Rails so Ruby alone was not the source of slow performance. In fact the solution was more to do with cloning the database in order to be able to isolate reads and writes so not even a programming language problem at all.
I'm assuming the details of exactly what the new implementation is have been deliberately withheld for some future post where they talk specifics (especially if it's something exciting like Rust/Elixir/Go). This keeps the focus of this post on the approach to migration, using the old implementation as a reference in order to burn down the list of divergences, etc.
