Ruby 3.2’s YJIT is Production-Ready
shopify.engineering
Ruby 3.2’s YJIT is Production-Ready
1–10 of 304 posts
Re: Ruby 3.2’s YJIT is Production-Ready
#2It 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.
Re: Ruby 3.2’s YJIT is Production-Ready
#3It 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 H…
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).
Re: Ruby 3.2’s YJIT is Production-Ready
#4It 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 H…
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).
Yes, I'm just asking whether that needs to be Shopify? And whether their time is best spent elsewhere.
Re: Ruby 3.2’s YJIT is Production-Ready
#5You love to see the continued investment in this language. I've been using Ruby for about a decade and I'm still enjoying writing code in it. I hope the language continues to improve and the community stays vibrant.
I can remember about 8 years ago someone telling me how they were worried Ruby (and Rails) was dying. At this point the community could dry up and I think I'd still stick with it.
Re: Ruby 3.2’s YJIT is Production-Ready
#6Does this work put Ruby into a faster category than Python until if/when Python gets a JIT in its official implementation?
Re: Ruby 3.2’s YJIT is Production-Ready
#7It 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 H…
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
Re: Ruby 3.2’s YJIT is Production-Ready
#8It 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 H…
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.
Re: Ruby 3.2’s YJIT is Production-Ready
#9It 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 H…
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.
Re: Ruby 3.2’s YJIT is Production-Ready
#10I'm pretty sure (there isn't a lot of info on how to enable it in production workloads) we're running YJIT in production and didn't notice any improvement in load times, CPU usage or anything really. If any slightly higher metrics across the board.
We're using Rails as API and web frontend with a pretty high number of requests per second, so I was hoping we'd see something. Does anyone have any experience rolling it out?