6 ms·

It shows that Ruby still has life left in it yet. The language itself is wonderful, there's a great ecosystem of tooling but the performance was always lagging.

by asim 4y ago

It shows that Ruby still has life left in it yet. The language itself is wonderful, there's a great ecosystem of tooling but the performance was always lagging. Hopefully some of this makes it a choice for people once more over other more esoteric languages. My only concern here would be the time and sunk cost fallacy of someone like a Shopify working on a Ruby JIT. It reminds me of when Facebook was working on the HipHop VM for PHP code and compiling PHP to large C++ binaries. I mean I get it, you have millions of lines of code, you don't want to rewrite it, but I often wonder, is there a better solution to this? Is there just a natural path towards, write new things in a new language and leave the old behind? Genuine question, because I'm not talking about rewriting the stack, I'm just talking about not investing significant amounts of time in low level infrastructure that's totally unrelated to business priorities. Yes fast code means better user experiences but often there's alternative ways around this than doing some literal JIT compiler work.

xoac 4y ago
Someone has to do this work, and I this is a good example of a company giving back to what was originally a non-industry project (Ruby).
- asim 4y ago
  Yes, I'm just asking whether that needs to be Shopify? And whether their time is best spent elsewhere.
  - olau 4y ago
    The loss of human time in big corporations is immense. Coordination overhead and losses due to information logistics problems. I'd imagine a project like this with no dependencies on the rest of the stack can be run efficiently. From a bang per buck point of view it might beat other means (rewrite, using multiple languages, redoing ops to run on cheaper backbone) by a huge factor. I get your sunk cost objection, but it's a bit depressing to hear people worry about someone doing genuinely useful work. Nobody wants to take responsibility or get their hands dirty. There's still plenty of low-hanging fruit in both language implementations and databases. The world today is just mountains upon mountains of bullshit.
  - xal 4y ago
    Creating and sharing powerful tools for people to build the things that they want to exist is kinda in Shopify's DNA. It's also important to me to give back to open source. It's done so much for us.
  - xoac 4y ago
    Well they have one of the bigger ruby/rails deployments so a 10% perf increase benefits them quite a bit.
psychoslave 4y ago
I see the point to make a parallel with HipHop, but here YJIT is directly integrated in CRuby, the main implementation of the language, and it’s just a matter of command line flag whether you enable or disable it — at least from what I remember that I red. From what I remember, HipHop was distributed in a different toolchain than the vanilla PHP interpreter. Ruby also have other interpreters available by the way: https://github.com/codicoscepticos/ruby-implementations https://github.com/codicoscepticos/ruby-implementations
- maxime_cb 4y ago
  Yes. Not only is YJIT directly integrated into CRuby, it's also 100% compatible with your existing Ruby code, which is why we chose to go that route. We didn't want to independently reimplement Ruby because we knew that this would lead to a situation where we wouldn't be 100% compatible, which would stop people from using YJIT. If you think about PyPy for example, they have great performance numbers, but relatively few people are using it.
  - v3ss0n 4y ago
    Yeah , it was because Guido himself was not promoting that project . PyPy team really tried hard to be compatible , now almost all c-extensions including DS libraries worked. I am using PyPy in production for 8 years and - it reduce memory load by a lot , ( 80 MB vs over 300 MB for tornado web service running) - it is so much faster than python that is comparable to node in high load peformance. - it would be compatibile with every lib if Main Stream Python community had even tried it and work on it.
giraffe_lady 4y ago
I think thinking of the "sunk cost" as being only or even primarily code is incomplete. It's internal expertise in that language, understanding of its strengths and weaknesses and how they fit into your business needs, custom tooling around dev, debugging & deployment, practice evaluating candidates for expertise in it, particular strengths of that language not guaranteed to be in a replacement, just all of the "unknown unknowns" that you now know through bitter experience. Surely there will still be a point where it's worth throwing all that out and starting fresh, but some of those are very hard to quantify or even see, when you have them, so the conservative choice is to stay put in the system that works.
ryanianian 4y ago
You can often solve ~70% of this with language interop. Bindings and FFIs are in my opinion very under-appreciated. This is the approach taken by PHP+HipHop, Apple with Swift/ObjC, and many Python bindings over C++ internals (TF etc). There is no magic bullet. You can't do an overnight transition. If you decide to make a language shift (or equivalently large architecture shift), you need an interop. Old and new have to coexist. The remaining 30% (where interop fails) is where engineering happens and is often where you had hidden technical debt anyway.
jrochkind1 4y ago
The JVM is as performant as it is because so much resources were invested in optimization (including various forms of JIT etc). It's an amazingly performant VM because of so much invested in tuning it. Or same about various Javascript VMs. This kind of performance comes from lots of resources invested in tuning. Lots of resources are invested, generally, when there are lots of entities relying on a thing; that's a very good reason people invest in improving a thing, right? So I'm not really sure what you mean -- you say "sunk cost", I say "Well, those who are using a thing are those who invest in improving it, how is it ever any different? And that there are people with current investments in ruby who will continue to invest to improve it is what will make ruby continue to thrive -- and how is it ever any different with any technology?" What would make it "sunk cost", i suppose, is if you think ruby is a poor technology and everyone using it should switch to something else. I guess it is popular to hate on ruby right now, but that seems to be an orthogonal debate. Ironically, one of the most popular reasons to hate on ruby is "performance" (rightly or wrongly), so it seems especialy weird to me to show up with an argument like "Sure, they're drastically improving ruby performance, but is ruby the right choice of thing to improve it's performance? After all, ruby has such bad performance!" To be fair, you didn't specifically say "because ruby has such bad performance", you didn't say anything about why ruby might be the wrong thing to invest in at all -- which makes it all the more just weird FUD, intentionally or not. You are suggesting that just in general we should prefer switching to new languages over investing in the existing ones? Since you didn't supply any specific arguments, it makes it seem as if you suggest this as a general principle, regardless of details? I think many of our experiences is that this leads to always using immature technology; to reach the stability and performance of (say) the JVM or V8 requires... investing in the thing, not constantly chasing a new immature thing hoping it will be different this time.
bastawhiz 4y ago
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)
ljm 4y ago
I think it's almost a cliché that Ruby is dying, is dead, or is outdated and uncool. It comes up in almost every post about Ruby. It's going as strong as ever and, if anything, it's stabilised into a robust, expressive and powerful language and in many cases that's a pretty acceptable trade-off. The fact it has long since matured into 'boring' technology (as in 'choose boring technology') is nothing but a good thing. It's great that so much work is going into performance, though. I've been excited to try this new JIT out in prod, and I'm excited to see how Ractor, for example, evolves.
- jack_riminton 4y ago
  Indeed. Oh well, while people keep spouting these cliches Ruby will continue running the worlds code bases (Github), a lot of the world's payments (Stripe) and a lot of the worlds e-commerce (Shopify)
pdntspa 4y ago
I am sooooooooooo sick of all this language churn. Ruby is a fantastic language, full stop.
- stevebmark 4y ago
  irb > def method irb > 'yes' irb > def method irb > 'it is not' irb > end irb > end irb > method => :method irb > method => "it is not"
  - pdntspa 4y ago
    yeah don't nest your methods. When have I ever needed that anyway?
    - stevebmark 4y ago
      That’s true, method_missing is both much more common and much worse
msie 4y ago
I think you don’t like Ruby and would want investment in the your favourite language. Because why would you care what a corporation does with their money?
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]

by asim 4y ago

xoac 4y ago

Someone has to do this work, and I this is a good example of a company giving back to what was originally a non-industry project (Ruby).

asim 4y ago
Yes, I'm just asking whether that needs to be Shopify? And whether their time is best spent elsewhere.
- olau 4y ago
  The loss of human time in big corporations is immense. Coordination overhead and losses due to information logistics problems. I'd imagine a project like this with no dependencies on the rest of the stack can be run efficiently. From a bang per buck point of view it might beat other means (rewrite, using multiple languages, redoing ops to run on cheaper backbone) by a huge factor. I get your sunk cost objection, but it's a bit depressing to hear people worry about someone doing genuinely useful work. Nobody wants to take responsibility or get their hands dirty. There's still plenty of low-hanging fruit in both language implementations and databases. The world today is just mountains upon mountains of bullshit.
- xal 4y ago
  Creating and sharing powerful tools for people to build the things that they want to exist is kinda in Shopify's DNA. It's also important to me to give back to open source. It's done so much for us.
- xoac 4y ago
  Well they have one of the bigger ruby/rails deployments so a 10% perf increase benefits them quite a bit.

psychoslave 4y ago

I see the point to make a parallel with HipHop, but here YJIT is directly integrated in CRuby, the main implementation of the language, and it’s just a matter of command line flag whether you enable or disable it — at least from what I remember that I red. From what I remember, HipHop was distributed in a different toolchain than the vanilla PHP interpreter. Ruby also have other interpreters available by the way: https://github.com/codicoscepticos/ruby-implementations https://github.com/codicoscepticos/ruby-implementations

maxime_cb 4y ago
Yes. Not only is YJIT directly integrated into CRuby, it's also 100% compatible with your existing Ruby code, which is why we chose to go that route. We didn't want to independently reimplement Ruby because we knew that this would lead to a situation where we wouldn't be 100% compatible, which would stop people from using YJIT. If you think about PyPy for example, they have great performance numbers, but relatively few people are using it.
- v3ss0n 4y ago
  Yeah , it was because Guido himself was not promoting that project . PyPy team really tried hard to be compatible , now almost all c-extensions including DS libraries worked. I am using PyPy in production for 8 years and - it reduce memory load by a lot , ( 80 MB vs over 300 MB for tornado web service running) - it is so much faster than python that is comparable to node in high load peformance. - it would be compatibile with every lib if Main Stream Python community had even tried it and work on it.

giraffe_lady 4y ago

I think thinking of the "sunk cost" as being only or even primarily code is incomplete. It's internal expertise in that language, understanding of its strengths and weaknesses and how they fit into your business needs, custom tooling around dev, debugging & deployment, practice evaluating candidates for expertise in it, particular strengths of that language not guaranteed to be in a replacement, just all of the "unknown unknowns" that you now know through bitter experience. Surely there will still be a point where it's worth throwing all that out and starting fresh, but some of those are very hard to quantify or even see, when you have them, so the conservative choice is to stay put in the system that works.

ryanianian 4y ago

You can often solve ~70% of this with language interop. Bindings and FFIs are in my opinion very under-appreciated. This is the approach taken by PHP+HipHop, Apple with Swift/ObjC, and many Python bindings over C++ internals (TF etc). There is no magic bullet. You can't do an overnight transition. If you decide to make a language shift (or equivalently large architecture shift), you need an interop. Old and new have to coexist. The remaining 30% (where interop fails) is where engineering happens and is often where you had hidden technical debt anyway.

jrochkind1 4y ago

The JVM is as performant as it is because so much resources were invested in optimization (including various forms of JIT etc). It's an amazingly performant VM because of so much invested in tuning it. Or same about various Javascript VMs. This kind of performance comes from lots of resources invested in tuning. Lots of resources are invested, generally, when there are lots of entities relying on a thing; that's a very good reason people invest in improving a thing, right? So I'm not really sure what you mean -- you say "sunk cost", I say "Well, those who are using a thing are those who invest in improving it, how is it ever any different? And that there are people with current investments in ruby who will continue to invest to improve it is what will make ruby continue to thrive -- and how is it ever any different with any technology?" What would make it "sunk cost", i suppose, is if you think ruby is a poor technology and everyone using it should switch to something else. I guess it is popular to hate on ruby right now, but that seems to be an orthogonal debate. Ironically, one of the most popular reasons to hate on ruby is "performance" (rightly or wrongly), so it seems especialy weird to me to show up with an argument like "Sure, they're drastically improving ruby performance, but is ruby the right choice of thing to improve it's performance? After all, ruby has such bad performance!" To be fair, you didn't specifically say "because ruby has such bad performance", you didn't say anything about why ruby might be the wrong thing to invest in at all -- which makes it all the more just weird FUD, intentionally or not. You are suggesting that just in general we should prefer switching to new languages over investing in the existing ones? Since you didn't supply any specific arguments, it makes it seem as if you suggest this as a general principle, regardless of details? I think many of our experiences is that this leads to always using immature technology; to reach the stability and performance of (say) the JVM or V8 requires... investing in the thing, not constantly chasing a new immature thing hoping it will be different this time.

bastawhiz 4y ago

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)

ljm 4y ago

I think it's almost a cliché that Ruby is dying, is dead, or is outdated and uncool. It comes up in almost every post about Ruby. It's going as strong as ever and, if anything, it's stabilised into a robust, expressive and powerful language and in many cases that's a pretty acceptable trade-off. The fact it has long since matured into 'boring' technology (as in 'choose boring technology') is nothing but a good thing. It's great that so much work is going into performance, though. I've been excited to try this new JIT out in prod, and I'm excited to see how Ractor, for example, evolves.

jack_riminton 4y ago
Indeed. Oh well, while people keep spouting these cliches Ruby will continue running the worlds code bases (Github), a lot of the world's payments (Stripe) and a lot of the worlds e-commerce (Shopify)

pdntspa 4y ago

I am sooooooooooo sick of all this language churn. Ruby is a fantastic language, full stop.

stevebmark 4y ago
irb > def method irb > 'yes' irb > def method irb > 'it is not' irb > end irb > end irb > method => :method irb > method => "it is not"
- pdntspa 4y ago
  yeah don't nest your methods. When have I ever needed that anyway?
  - stevebmark 4y ago
    That’s true, method_missing is both much more common and much worse

msie 4y ago

I think you don’t like Ruby and would want investment in the your favourite language. Because why would you care what a corporation does with their money?

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]