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

171–180 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#171

Post by Gigachad »

reducesuffering wrote: post #145
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…

People often say this but it's nowhere close to universal. Ruby is 24/42 of most loved langs. https://survey.stackoverflow.co/2022/#technology-most-loved-...

This survey shows that slightly over 50% of ruby users dread using it.

Re: Ruby 3.2’s YJIT is Production-Ready

#172

Post by hawski »

v3ss0n wrote: post #158

Python have a 99% compatible jit implementation called PyPy and nobody much know about it. It was production ready since 5 years ago but ignored by mainstream. It is 400% faster than vanilla python on average and Guido and MS is working on for a few percent gain instead of promoting it or eventually making it default. PyPy.org

I wonder how much of it is related to how Python is being used for short running scripts more than Ruby, at least in my experience. In such cases startup time is more important than being faster in a long run.

Re: Ruby 3.2’s YJIT is Production-Ready

#173

Post by claudiug »

jrochkind1 wrote: post #118
lakomen wrote: post #78

> Multiple large clusters of servers distributed across the world, capable of serving over 75 million requests per minute That doesn't say anything at all sadly. Ruby people seem to be sensitive when someone asks them about performance, my last question about that was downvoted heavily here. I don't know any Ruby, I know how much Go can handle with the stdlib, a single non-parameterized route, returning "hello world"…

> since we're talking semi real world scenarios A single non-parameterized route returning "hello world" is a real-world scenario? You have an interesting business domain!

he has a saas that return hello world.

Re: Ruby 3.2’s YJIT is Production-Ready

#174

Post by treis »

letmeinhere wrote: post #156
treis wrote: post #138

Earlier quoted context omitted.

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…

Sure, this is an advantage that Typescript has, but it doesn't explain Ruby's lagging progress compared to Python and PHP. Some of that can probably pinned on the greater dynamism of Ruby, making all manner of static analysis quite challenging. But from what I've seen, it seems like the main reason is indifference or even mild hostility from the language maintainers. It looks a lot like they saw Sorbet taking off and…

I agree that Sorbet is a better solution but it's also a breaking change. It's a relatively small breaking change and, IMHO, would have been more than worth it but alas it was not my decision to make.

Re: Ruby 3.2’s YJIT is Production-Ready

#175

Post by xfalcox »

acchow wrote: post #132

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

You can enable YJIT and get a ~30% speedup by passing an extra environment variable to your Docker container. Moving away from CRuby to an alternative Ruby is a lot harder than that.

Also Oracle.

Re: Ruby 3.2’s YJIT is Production-Ready

#176

Post by Slippery_John »

zitterbewegung wrote: post #101
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 ...

Python now has an optional type system and if you add one of them such as mypy or pyre to your CI process and you can configure GitHub to refuse the pull request until types are added you can make it somewhat strongly typed. If you have a preexisting codebase I believe the way you can convert it is to add the types that you know on commits and eventually you will have enough types that adding the missing ones should…

Python's type hints are definitely an improvement and they're getting better all the time, but they're still frustrating to use at anything approaching the edge. I long for something as elegant and functional as TypeScript.

One hurdle I've stumbled over recently is the question "what is a type?", the answer can be surprising. Unions, for example, are types but not `Type`s. A function that takes an argument of type `Type` will not accept a Union. So if you want to write a function that effectively "casts" a parameter to a specified type, you can't. The best you can do is have an overload that accepts `Type` and does an actual cast, and then another that just turns it into `Any`. This is, in fact, how the standard library types its `cast` function [1]. The argument I've seen for the current behavior is that `Type` describes anything that can be passed to isinstance, but that's not a satisfying answer. Even then, `Union` can be passed to isinstance and still does not work with `Type`. Talk currently is to introduce a new kind of type called `TypeForm` or something to address this, which is certainly an improvement over nothing, but still feels like technical debt.

[1]: https://github.com/python/typeshed/blob/main/stdlib/typing.p...

Re: Ruby 3.2’s YJIT is Production-Ready

#177

Post by nateberkopec »

the-alchemist wrote: post #143
acchow wrote: post #132

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

I don't quite understand the YJIT excitement. A few benchmarks show that TruffleRuby generally beats YJIT, sometimes by a 10x margin. [0]: https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj... says

TruffleRuby can’t run production Rails traffic today, and YJIT can.

Re: Ruby 3.2’s YJIT is Production-Ready

#178

Post by Spivak »

merb wrote: post #163
v3ss0n wrote: post #160

Earlier quoted context omitted.

What? When was oracle free or opensource?

and when was oracle the fastest database? You are not allowed to even publish that metric....

I do have some sympathy for companies who don’t want to have to deal with a constant barrage of benchmarks that are egregiously wrong.

HN has been host to quite a few of these spats over the years and I wouldn’t want to deal with it, there are pretty much only downsides to letting people poorly benchmark your product and have every incentive to get it wrong.

Re: Ruby 3.2’s YJIT is Production-Ready

#179

Post by merb »

Spivak wrote: post #178
merb wrote: post #163

Earlier quoted context omitted.

and when was oracle the fastest database? You are not allowed to even publish that metric....

I do have some sympathy for companies who don’t want to have to deal with a constant barrage of benchmarks that are egregiously wrong. HN has been host to quite a few of these spats over the years and I wouldn’t want to deal with it, there are pretty much only downsides to letting people poorly benchmark your product and have every incentive to get it wrong.

well to be fair, most benchmarks are of course not comparable with the real world. People should always use what works best for them.

Re: Ruby 3.2’s YJIT is Production-Ready

#180

Post by xiphias2 »

Gigachad wrote: post #168
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 ...

I’ve been doing Rails development for 10 years now and I just don’t think it’s possible to safely update anything in Ruby. Our app has 20,000 rspec unit tests and 5,000 cypress browser automation tests and basically every ruby patch version creates breakages that somehow slip through all of that despite nothing being mentioned in the changelogs.

What about recording and replaying traffic to the servers? It's not a magical solution, but it should catch regressions.
Post reply on HN