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

51–60 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#51

Post by itake »

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

I've been coding for 10+ years and I would argue that ruby is not kind to the writer.

Ruby requires you to be aware of much more "state" than any other language that I have coded in, because all assumptions about methods cannot be confirmed until the code is run. For example, a gem might modify the default_scope of a portion of active record models. You have to memorize all these tweaks and even then you don't know if the code you've written will do what you want until it is actually been run.

Re: Ruby 3.2’s YJIT is Production-Ready

#52

Post by phaedryx »

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

The solution is to be religious about testing and writing tests. If you've done it well, refactors are pretty safe and your objects are pretty well understood.

Re: Ruby 3.2’s YJIT is Production-Ready

#54

Post by pdntspa »

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 am sooooooooooo sick of all this language churn. Ruby is a fantastic language, full stop.

Re: Ruby 3.2’s YJIT is Production-Ready

#55

Post by pantulis »

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

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.

Re: Ruby 3.2’s YJIT is Production-Ready

#56

Post by pantulis »

phaedryx wrote: post #52
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 ...

The solution is to be religious about testing and writing tests. If you've done it well, refactors are pretty safe and your objects are pretty well understood.

Also, you need to be religious about testing and writing tests _anyway_.

Re: Ruby 3.2’s YJIT is Production-Ready

#57

Post by rrgok »

the_sleaze9 wrote: post #17
panzi wrote: post #14

What does 10% speedup mean? Doing 10% more work in the same time or needing 10% less time for the same amount of work?

I have to admit my brain seems to be short circuiting on this one. Aren't these 2 ways of saying the same thing?

The percentage is applied to two different things. One for work and the other for the time.

It took sometime to me too.

Re: Ruby 3.2’s YJIT is Production-Ready

#58

Post by byroot »

pantulis wrote: post #53

I'm wondering about what impact would this have in Basecamp's hosting bills...

If you look at the breakdown per service, EC2 (assuming mostly Ruby) seem to be at best 20% of the bill: https://twitter.com/dhh/status/1613508201953038337

So if you are to make Ruby ~10% faster, you might reduce Basecamp hosting bill by 2% at best.

Re: Ruby 3.2’s YJIT is Production-Ready

#59

Post by vlunkr »

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

I still think it's a great choice for smaller projects. I can't imagine it at the scale of shopify.

Re: Ruby 3.2’s YJIT is Production-Ready

#60

Post by DoctorOW »

byroot wrote: post #58
pantulis wrote: post #53

I'm wondering about what impact would this have in Basecamp's hosting bills...

If you look at the breakdown per service, EC2 (assuming mostly Ruby) seem to be at best 20% of the bill: https://twitter.com/dhh/status/1613508201953038337 So if you are to make Ruby ~10% faster, you might reduce Basecamp hosting bill by 2% at best.

> Remember, this excludes the current Basecamp and Basecamp 2, which use our own hardware for this

https://dev.37signals.com/our-cloud-spend-in-2022/

Post reply on HN