[sbarre]

Obvious how?

Are you going to restructure literally thousands of employees and their teams, staffed with Rubyists and organized around your current setup?

Will you re-hire and/or re-train everyone?

That doesn't seem so obvious... At the scale of a team like Shopify, refactoring to a different language is probably a non-starter.

[cookiecaper]

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.

[nicoburns]

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.

[Jach]

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

[jashmatthews]

"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.

Mandelbrot (from CLBG) Ruby 246s NodeJS 8s Java 4s

Web (fortunes from TE benchmarks) Ruby + Roda + Sequel 51k rps NodeJS + Express 46k rps Java + Dropwizard 62k rps

[nicoburns]

You're comparing Ruby to other options that are still slow:

Java (vertx-postgres) 347k rps, Go (fasthttp) 320k rps Rust (actix-postgres) 607k rps

[jashmatthews]

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.

[nicoburns]

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).

[jashmatthews]

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.

[mikepurvis]

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.

1: https://www.softwaresessions.com/episodes/rust-in-production...