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

131–140 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#131

Post by djur »

stevebmark wrote: post #70

Is there a name for this syndrome? The same thing happened at Github. Ruby and Rails are slow enough in production that they dedicate a specialized, long-running internal team to it. This team doesn't contribute directly to the product. They hire core Ruby and Rails maintainers, also not to contribute to the product, just to try to help improve their slow software. It's a dream job that shouldn't exist. If you tell m…

Can you give some examples of companies that "scaled" without dedicating at least some engineering work to improving their runtime?

Re: Ruby 3.2’s YJIT is Production-Ready

#133

Post by why-el »

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…

The top comment in HN is one where the poster is not 100% is using the thing we are discussing.

Re: Ruby 3.2’s YJIT is Production-Ready

#134

Post by Gene_Parmesan »

mostlysimilar wrote: post #113
vidarh wrote: post #92

Earlier quoted context omitted.

I used to have that attitude. Then I wrote my first Ruby project as an experiment. That was 17 years ago, and the majority of the code I've written since has been Ruby. What clinched it was that the first Ruby project I wrote involved trying to reimplement a piece of C code we had. It ended up 10% the size with more functionality, and it took me a tiny fraction of the time to write. If you write code the way you writ…

I don't know if I'm just a bad programmer and everyone knows something I don't, but it seems to be the benefits of a strongly typed language are wildly overblown. It's a different way of thinking about building software and it saves you from a few mistakes you could otherwise make, but you'd think I was writing code with a hammer and chisel the way people on HN talk about languages like Ruby. It feels a lot like the…

For me, it comes down to the fact that static typing completely eliminates large classes of bugs. It therefore dramatically lowers the testing load. The compile step essentially performs its own tests. Think about all the test cases I save myself from having to write...

Beyond that, it also forces me to think structurally from the start. But I tend to be working on rather complex applications, I almost certainly wouldn't use a static lang for data processing or similar tasks.

> It feels a lot like the people who used to try to convince everyone functional programming was the only way to go and object-oriented programming was for dinosaurs.

What do you mean "used to"?? Haha

Re: Ruby 3.2’s YJIT is Production-Ready

#135

Post by JohnBooty »

acchow wrote: post #132

I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?

Tragically, one of the principals behind TruffleRuby (and researcher at Shopify) was Chris Eaton and he passed away a few months ago.

I'm not sure where this leaves TruffleRuby itself, or plans to implement it at Shopify.

(Rest in peace, Chris, and may your memory be a blessing to those who knew you)

Re: Ruby 3.2’s YJIT is Production-Ready

#136

Post by ezekg »

xutopia wrote: post #100
stevebmark wrote: post #70

Is there a name for this syndrome? The same thing happened at Github. Ruby and Rails are slow enough in production that they dedicate a specialized, long-running internal team to it. This team doesn't contribute directly to the product. They hire core Ruby and Rails maintainers, also not to contribute to the product, just to try to help improve their slow software. It's a dream job that shouldn't exist. If you tell m…

Shopify like many other successful Ruby shops were successful because of the speed of development. The cost of hosting is secondary and any company the size of Shopify can afford to involve a small team to reduce hosting costs... with impact for the developers happiness to boot.

I wonder if YJIT actually did decrease infrastructure costs for Shopify, seeing as it requires ~3x more memory. For my business, it’s come out about even. But a >30% decrease in response time is worth it, for me at least.

I run many small servers (2 processes each), but IIRC, Shopify runs beefy servers. So may be different for them.

Re: Ruby 3.2’s YJIT is Production-Ready

#137

Post by JamesSwift »

pantulis wrote: post #55
Thaxll wrote: post #45

Earlier quoted context omitted.

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

It's not like strong typing came after Ruby. In fact, duck typing was a _feature_ of Ruby on its days. At the end of the day, you choose your battles, it's not a black-or-white decision.

Ruby is one of the few successors to smalltalk with "true" everything is an object and message passing. As such, duck typing is in fact a feature and if you can internalize how it differs from traditional OOP then it becomes very powerful. It is a double edged sword however, and can be wielded poorly.

Re: Ruby 3.2’s YJIT is Production-Ready

#138

Post by treis »

hardwaregeek wrote: post #31

It's been a sec since I've used Ruby. How's the typing story? Seems like Sorbet is doing quite well, but are there comprehensive typings for the ecosystem, like TypeScript? Because with ergonomic, comprehensive type checking and a JIT, Ruby might be a tempting option again.

The problem, I think, is the restrictions that not having a compilation step places on what typing you can do without a big breaking change. Typescript didn't have this problem because everyone already used bundlers/minifiers/etc. Adding another compiler like step to that process was pretty natural.

Ruby doesn't have that and adding it in poses problems for REPL development. They chose to go with a separate file for types. Which gets around the breaking change problem but the ergonomics are terrible. Think the hope is that IDE support eventually gets around that issue. But thus far not a whole lot of adoption.

Re: Ruby 3.2’s YJIT is Production-Ready

#139

Post by byroot »

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…

There might be a number of reasons why YJIT isn't effective in your application.

The best way to know it to enable YJIT runtime statistics [0] to see whether YJIT is doing a lot of side exits and if so why. But it requires a bit of YJIT knowledge to interpret them.

It's also entirely possible that your application isn't CPU bound in the first place, or that it's bottlenecked by things YJIT can't do anything about (e.g. GVL).

That's close to impossible to guess what it might be without being able to instrument the application.

[0] https://github.com/ruby/ruby/blob/df6b72b8ff7af16a56fa48f3b4...

Re: Ruby 3.2’s YJIT is Production-Ready

#140

Post by the-alchemist »

JohnBooty wrote: post #135
acchow wrote: post #132

I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?

Tragically, one of the principals behind TruffleRuby (and researcher at Shopify) was Chris Eaton and he passed away a few months ago. I'm not sure where this leaves TruffleRuby itself, or plans to implement it at Shopify. (Rest in peace, Chris, and may your memory be a blessing to those who knew you)

so sad, I had no idea. We lost a brilliant mind...
Post reply on HN