3 ms·

The big difference compared to HHVM is that this is part of Ruby. It's not a separate project. Shopify is sponsoring much of the effort, but it's owned by the c

The big difference compared to HHVM is that this is part of Ruby. It's not a separate project. Shopify is sponsoring much of the effort, but it's owned by the community. At Stripe, there are millions of lines of Ruby. Lots of it would be better off in a different language—if it had been written in another language initially. Ruby is easy to hire for, there are tens of thousands of pages of documentation for the code written in it, and there's a ton of operational knowledge about how to use it well. Switching is possible, but the cost to replace it is half a decade or more. During that time, you're not building new features, you're worrying about compatibility and making sure there's no downtime. Instead of making incremental improvements, your infra folks are worrying about migration paths. At the end of the day, the major arguments against Ruby is lack of native type checking (solved with tooling) and performance. For Shopify, you can either undertake a major engineering effort to rewrite your stack (years of effort, incidents, no real feature development, morale killing) or kick a few million dollars at making the thing your engineers like faster. The cost of replacing Ruby is tens of millions of dollars: not just engineers putting pen to paper, but lost business from putting the company on hold, breakages, and throwing out immense amounts of operational knowledge and experience. Said another way, telling a thousand+ people to drop what they're doing, learn a new language, and redo all their work is an expensive way to end up with a worse version of what you already have. It's not a sunk cost fallacy if you literally can't afford to change.

JohnBooty 4y ago
Love this post, although: Ruby is easy to hire for I've always had the opposite experience!
- bastawhiz 4y ago
  In my time at Stripe, few of the candidates were fluent in Ruby, but it almost always took less than a couple weeks to get spun up with it. If you're looking for Ruby talent, it's more challenging.
  - JohnBooty 4y ago
    I've worked at places that hire folks with Ruby experience only (more difficult) and places that just hired the best available engineer and let them learn Ruby (easier but EXTREMELY mixed results - specifically lots of Java ppl insisting on writing Ruby that looks like Java and insisting upon using e.g. Spring conventions in Rails)
    - dosethree 4y ago
      This is super common, (and the mark of a bad programmer if you program the same in every language). What's funny is the opposite - people who get so into ruby that everything they write is cute and overthought - is actually worse. Ruby is so powerful but simplicity is the best if other people are going to read and maintain your code. Go is great for this.
      - JohnBooty 4y ago
        Ruby is so powerful but simplicity is the best if other people are going to read and maintain your code. Amen. Keep it simple for a large shared Ruby application, such as a Rails app. More advanced Ruby (writing your own operators/iterators/whatever, metaprogramming, extending the language itself, whatever) is best reserved for Ruby frameworks, not applications.
- config_yml 4y ago
  As someone experienced in Ruby (and Rails), I've also always had the opposite experience. Very little options!
  - JohnBooty 4y ago
    There haven't been a ton of choices when I've looked for Ruby/Rails jobs, but I never had much trouble landing one. They usually seem pretty relieved to have found somebody. When I've been on the hiring side of the equation, it's been very tough to find candidates.
onlyrealcuzzo 4y ago
> Switching is possible, but the cost to replace it is half a decade or more. I would imagine if you're going to switch millions of lines from one language to another - you wouldn't do it by hand - you'd write something transpile it? Has any company actually done something like this before - especially somewhat recently? I can't imagine anyone doing it by hand...
- cguess 4y ago
  That doesn't really work in practice at scale. There's "Ruby" ways of doing things that don't just transpile over. It's also the entire Rails framework that would have to be ported then, which is beyond a monumental undertaking. That's not to even mention the massive amounts of new bugs that would be put into the code that have been ironed out over years of debugging and testing in the Ruby base. There's a reason so many legacy operators still run COBOL despite even C being a better candidate, it was just created twenty years too late and the costs of moving it over is well outside of the savings of not doing that. "If it ain't broke, don't fix it" is very much the key here.
- bastawhiz 4y ago
  You need to produce code that not just runs, but is idiomatic in the target language. I'm not aware of ANY transpilers that do this for target and source languages that run in different runtimes (i.e., not coffeeacript to JS). You need every language feature to translate cleanly, and that means that a translation failure makes it impossible to convert a logical unit (module, package, etc) at once. Simply having a translated version of the code without making it idiomatic means it's impossible to read or modify.
- mprovost 4y ago
  How is hiring a few people to write a transpiler any different than hiring a few engineers to write a JIT compiler? Isn't a JIT just transpiling code at a different level (bytecode instead of source code)?
- r-s 4y ago
  Many many years ago I was hired to convert a Fortran app to C. The first person to try it ran it through a software called "f2c". It worked fine - but the code was totally non human readable so it couldn't be extended later, so it provided almost no value in this case.

JohnBooty 4y ago

Love this post, although: Ruby is easy to hire for I've always had the opposite experience!

bastawhiz 4y ago
In my time at Stripe, few of the candidates were fluent in Ruby, but it almost always took less than a couple weeks to get spun up with it. If you're looking for Ruby talent, it's more challenging.
- JohnBooty 4y ago
  I've worked at places that hire folks with Ruby experience only (more difficult) and places that just hired the best available engineer and let them learn Ruby (easier but EXTREMELY mixed results - specifically lots of Java ppl insisting on writing Ruby that looks like Java and insisting upon using e.g. Spring conventions in Rails)
  - dosethree 4y ago
    This is super common, (and the mark of a bad programmer if you program the same in every language). What's funny is the opposite - people who get so into ruby that everything they write is cute and overthought - is actually worse. Ruby is so powerful but simplicity is the best if other people are going to read and maintain your code. Go is great for this.
    - JohnBooty 4y ago
      Ruby is so powerful but simplicity is the best if other people are going to read and maintain your code. Amen. Keep it simple for a large shared Ruby application, such as a Rails app. More advanced Ruby (writing your own operators/iterators/whatever, metaprogramming, extending the language itself, whatever) is best reserved for Ruby frameworks, not applications.
config_yml 4y ago
As someone experienced in Ruby (and Rails), I've also always had the opposite experience. Very little options!
- JohnBooty 4y ago
  There haven't been a ton of choices when I've looked for Ruby/Rails jobs, but I never had much trouble landing one. They usually seem pretty relieved to have found somebody. When I've been on the hiring side of the equation, it's been very tough to find candidates.

onlyrealcuzzo 4y ago

> Switching is possible, but the cost to replace it is half a decade or more. I would imagine if you're going to switch millions of lines from one language to another - you wouldn't do it by hand - you'd write something transpile it? Has any company actually done something like this before - especially somewhat recently? I can't imagine anyone doing it by hand...

cguess 4y ago
That doesn't really work in practice at scale. There's "Ruby" ways of doing things that don't just transpile over. It's also the entire Rails framework that would have to be ported then, which is beyond a monumental undertaking. That's not to even mention the massive amounts of new bugs that would be put into the code that have been ironed out over years of debugging and testing in the Ruby base. There's a reason so many legacy operators still run COBOL despite even C being a better candidate, it was just created twenty years too late and the costs of moving it over is well outside of the savings of not doing that. "If it ain't broke, don't fix it" is very much the key here.
bastawhiz 4y ago
You need to produce code that not just runs, but is idiomatic in the target language. I'm not aware of ANY transpilers that do this for target and source languages that run in different runtimes (i.e., not coffeeacript to JS). You need every language feature to translate cleanly, and that means that a translation failure makes it impossible to convert a logical unit (module, package, etc) at once. Simply having a translated version of the code without making it idiomatic means it's impossible to read or modify.
mprovost 4y ago
How is hiring a few people to write a transpiler any different than hiring a few engineers to write a JIT compiler? Isn't a JIT just transpiling code at a different level (bytecode instead of source code)?
r-s 4y ago
Many many years ago I was hired to convert a Fortran app to C. The first person to try it ran it through a software called "f2c". It worked fine - but the code was totally non human readable so it couldn't be extended later, so it provided almost no value in this case.