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

101–110 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#101

Post by zitterbewegung »

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

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 be easy. For the missing ones Any is a good choice.

https://pyre-check.org and https://github.com/python/mypy are popular.

Re: Ruby 3.2’s YJIT is Production-Ready

#102

Post by wilg »

abvdasker wrote: post #91
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 was probably my "first love" as a programming language for the reasons you described, but nowadays I prefer statically typed compiled languages. Ruby is still my preferred scripting language, though I've seen the way large projects can start to suffer from high maintenance overhead when it comes to dynamic languages like Ruby.

Same. I wish I was always writing Swift.

Re: Ruby 3.2’s YJIT is Production-Ready

#103

Post by erikrothoff »

MSkog wrote: post #21
JohnBooty wrote: post #18

Earlier quoted context omitted.

The gist of it is that you need to build Ruby with `RUBY_CONFIGURE_OPTS=--enable-yjit` true and verify it is enabled with `ruby --enable-yjit --version` and then finally run your code with `ruby --enable-yjit foo.rb`. For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag.

You can also set RUBY_YJIT_ENABLE=1 to enable it.

That’s what I ended up using:

passenger_env_var RUBY_YJIT_ENABLE 1;

Re: Ruby 3.2’s YJIT is Production-Ready

#104

Post by jeltz »

frou_dh wrote: post #6

Does this work put Ruby into a faster category than Python until if/when Python gets a JIT in its official implementation?

Ruby was already slightly faster than Python in many micro benchmarks before 3.2 and YJIT, so maybe? It depends on your workload.

Re: Ruby 3.2’s YJIT is Production-Ready

#105

Post by jerf »

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.

Static typing was a nightmare (by modern standards) in the 1990s. Dynamic scripting languages were such a breath of fresh air that we were willing to pay the steep performance penalties without hardly a thought. Sort of like the saying "deleted code is debugged code", code that you actually write always performs better than the code you didn't write because it was too soul-sucking.

But static typing languages, library stacks, and environments have come a long way in the last 30 years. Now I prefer even to "prototype" in static languages because the crossover to when they start providing me net benefit is around a week or so into my development process.

I will not claim one is completely better than the other, but the balance is a lot more even than I would say it was ~20 years ago.

Re: Ruby 3.2’s YJIT is Production-Ready

#106

Post by jwcooper »

jrochkind1 wrote: post #22
JohnBooty wrote: post #18

Earlier quoted context omitted.

The gist of it is that you need to build Ruby with `RUBY_CONFIGURE_OPTS=--enable-yjit` true and verify it is enabled with `ruby --enable-yjit --version` and then finally run your code with `ruby --enable-yjit foo.rb`. For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag.

Thanks! Is there a "canonical" place to find this documented, like with the ruby distro? > For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag. Alternately, you can edit your shell init scripts to put the correct thing in `RUBY_OPTS` ENV variable, yes? I would consider this preferable to editing executable rails scripts with implementation-specific stuff (and then hopi…

We're using puma and set the RUBYOPT=--yjit in a systemd environment variable for our puma service.

The performance impact of enabling yjit was quite obvious in our charts. Another giveaway that it's properly enabled is the servers will use consume more memory.

Re: Ruby 3.2’s YJIT is Production-Ready

#107

Post by jeltz »

itake wrote: post #49
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 ...

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

Nonsense. I used to be a professional Ruby developer and that is nowhere close to the truth. While I prefer static typing it is not hard at all to code in Ruby once you have learned the basics and I almost never used IRB other than when I was a beginner.

Re: Ruby 3.2’s YJIT is Production-Ready

#108

Post by jeltz »

itake wrote: post #51
setheron wrote: post #42

Earlier quoted context omitted.

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

That is a Rails issue, not a Ruby issue. Outside some Rails libraries this is not a thing. Virtually all non-Rails libraries try hard to avoid modifying global state.

Re: Ruby 3.2’s YJIT is Production-Ready

#109

Post by bcrosby95 »

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…

Languages don't scale (out), architecture does.

Well, maybe Elixir and Erlang scales out, since architecture is baked in.

Depending on how performant a language is, it can put off (sometimes forever) your need to scale out, which can simplify things. But both Github and Shopify are beyond the level of traffic that would allow you to get away with only scaling up rather than out.

Re: Ruby 3.2’s YJIT is Production-Ready

#110

Post by jrochkind1 »

MSkog wrote: post #25
jrochkind1 wrote: post #22

Earlier quoted context omitted.

Thanks! Is there a "canonical" place to find this documented, like with the ruby distro? > For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag. Alternately, you can edit your shell init scripts to put the correct thing in `RUBY_OPTS` ENV variable, yes? I would consider this preferable to editing executable rails scripts with implementation-specific stuff (and then hopi…

Perhaps this is what you are looking for: https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md

thank you!
Post reply on HN