Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.2’s YJIT is Production-Ready

shopify.engineering

Post reply on HN
Print view View original

41–50 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#41

Post by JohnBooty »

bastawhiz wrote: post #29
JohnBooty wrote: post #23

Earlier quoted context omitted.

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

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.

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)

Re: Ruby 3.2’s YJIT is Production-Ready

#42

Post by setheron »

revskill wrote: post #38

For anyone thinking Ruby is dying or slow, it's not the reason people like me used it and sticked with it in first place! It's about the experience when you write the code itself. It's natural, like a flow of water, and you're suddenly in Zen mode, where your thought just naturally flow without even you're aware or not. I first time learn Ruby from zero to "hero" in production confidently is in just under a week. And…

Ruby definitely optimizes for the writer but it fails for the reader (a saying I say quite frequently at work).

Re: Ruby 3.2’s YJIT is Production-Ready

#43

Post by ljm »

asim wrote: post #2

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 H…

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.

Re: Ruby 3.2’s YJIT is Production-Ready

#44

Post by richardlblair »

setheron wrote: post #42
revskill wrote: post #38

For anyone thinking Ruby is dying or slow, it's not the reason people like me used it and sticked with it in first place! It's about the experience when you write the code itself. It's natural, like a flow of water, and you're suddenly in Zen mode, where your thought just naturally flow without even you're aware or not. I first time learn Ruby from zero to "hero" in production confidently is in just under a week. And…

Ruby definitely optimizes for the writer but it fails for the reader (a saying I say quite frequently at work).

It _can_. Much like any other language, if you're not careful you can write some very convoluted Ruby code. What makes Ruby different is when you invest in readability you get far greater returns for much less effort.

Re: Ruby 3.2’s YJIT is Production-Ready

#45

Post by Thaxll »

revskill wrote: post #38

For anyone thinking Ruby is dying or slow, it's not the reason people like me used it and sticked with it in first place! It's about the experience when you write the code itself. It's natural, like a flow of water, and you're suddenly in Zen mode, where your thought just naturally flow without even you're aware or not. I first time learn Ruby from zero to "hero" in production confidently is in just under a week. And…

The main issue I have with Ruby / Python is the fact that it's duck typed, it makes the maintenance and refactor pretty hazardous.

You get objects you don't know what's in there, 6 month later someone changed it, no compile error but it will break when you run it.

And so to overcome those major issues they added really ugly stuff that is not core to the language, linters, annotations etc ...

Re: Ruby 3.2’s YJIT is Production-Ready

#46

Post by erikrothoff »

JohnBooty wrote: post #15
erikrothoff wrote: post #10

I'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…

Does anyone have any experience rolling it out? FWIW, the linked article has prod benchmarks. I'm pretty sure (there isn't a lot of info on how to enable it in production workloads) we're running YJIT in production Sure you're running it? You have to compile with YJIT support, and then pass the command line arg. (It doesn't support YJIT out of the box because, I presume, they didn't want to force a Rust dependency on…

Yes, I'm pretty sure because:

1. Compiled with jyjit confrmed (ruby --yjit) returns the correct value

2. RubyVM::YJIT.enabled? returned true

But the information available on how to confirm YJIT is running is not super clear. Since I didn't notice any improvements I started wondering.

Re: Ruby 3.2’s YJIT is Production-Ready

#47

Post by erikrothoff »

jrochkind1 wrote: post #13
erikrothoff wrote: post #10

I'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…

> I'm pretty sure (there isn't a lot of info on how to enable it in production workloads The YJIT is not on by default in ruby 3.2, you have to specifically enable it. If you aren't sure if you have enabled it... what makes you pretty sure you have enabled it? It seems possible you have not enabled it, if you aren't confident you know how to do so? I am not using it yet myself, and don't want to put any possibly inco…

Yes, I'm pretty sure because:

1. Compiled with jyjit confrmed (ruby --yjit) returns the correct value

2. RubyVM::YJIT.enabled? returned true

I didn't notice any improvements at basically so I can't really say _for sure_ if it was working as intended.

Re: Ruby 3.2’s YJIT is Production-Ready

#48

Post by mprovost »

onlyrealcuzzo wrote: post #24
bastawhiz wrote: post #12

Earlier quoted context omitted.

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…

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

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

Re: Ruby 3.2’s YJIT is Production-Ready

#49

Post by itake »

Thaxll wrote: post #45
revskill wrote: post #38

For anyone thinking Ruby is dying or slow, it's not the reason people like me used it and sticked with it in first place! It's about the experience when you write the code itself. It's natural, like a flow of water, and you're suddenly in Zen mode, where your thought just naturally flow without even you're aware or not. I first time learn Ruby from zero to "hero" in production confidently is in just under a week. And…

The main issue I have with Ruby / Python is the fact that it's duck typed, it makes the maintenance and refactor pretty hazardous. You get objects you don't know what's in there, 6 month later someone changed it, no compile error but it will break when you run it. And so to overcome those major issues they added really ugly stuff that is not core to the language, linters, annotations etc ...

Even in dev, you have to basically code in irb in order to verify everything works.

Re: Ruby 3.2’s YJIT is Production-Ready

#50

Post by [deleted] »

setheron wrote: post #42
revskill wrote: post #38

For anyone thinking Ruby is dying or slow, it's not the reason people like me used it and sticked with it in first place! It's about the experience when you write the code itself. It's natural, like a flow of water, and you're suddenly in Zen mode, where your thought just naturally flow without even you're aware or not. I first time learn Ruby from zero to "hero" in production confidently is in just under a week. And…

Ruby definitely optimizes for the writer but it fails for the reader (a saying I say quite frequently at work).

[deleted]
Post reply on HN