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

91–100 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#91

Post by abvdasker »

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.

Re: Ruby 3.2’s YJIT is Production-Ready

#92

Post by vidarh »

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 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 write statically typed code, then sure, you're in for a world of hurt. I could imagine using a statically typed language again if it made me as productive as Ruby, but most statically types languages have near useless type systems that I wouldn't wish on my worst enemy.

Re: Ruby 3.2’s YJIT is Production-Ready

#94

Post by JohnBooty »

erikrothoff wrote: post #46
JohnBooty wrote: post #15

Earlier quoted context omitted.

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.

Sounds like you're running it!

    Since I didn't notice any improvements I started wondering.
It only speeds up Ruby itself. In a "real world" web app performance, performance is mostly dominated by Ruby/PHP/Java/whatever sitting around and waiting for database queries to execute.

So for a lot of web workloads the perf increase won't be huge. If your average endpoint is e.g. 5ms of Ruby and 500ms of DB queries, your max speedup will be negligible if you switch to YJIT... or even if you rewrite the whole app in hand-optimized assembler.

(Also gets to the root of why perf-based criticism of Ruby is usually dumb, IMHO. It's usually not the problem)

Re: Ruby 3.2’s YJIT is Production-Ready

#95

Post by vidarh »

davidw wrote: post #73
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 ...

What are you using that's strongly typed and as quick to get stuff done with as Ruby?

Ruby.

(Ruby is strongly typed in the "doesn't automatically coerce types" and "maintains a fixed type for an object" sense; using the term "strong typing" is inherently ambiguous because it has so many partially conflicting meanings)

Re: Ruby 3.2’s YJIT is Production-Ready

#97

Post by pak9rabid »

vidarh wrote: post #92
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 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…

Have you looked into Crystal? It's supposed to be a statically-typed language, with the syntax of Ruby.

https://en.wikipedia.org/wiki/Crystal_(programming_language)

Re: Ruby 3.2’s YJIT is Production-Ready

#98

Post by JohnBooty »

dosethree wrote: post #85
JohnBooty wrote: post #41

Earlier quoted context omitted.

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)

This is super common, (and the mark of a bad programmer if you program the same in every language). What's funny is the opposite - people who get so into ruby that everything they write is cute and overthought - is actually worse. Ruby is so powerful but simplicity is the best if other people are going to read and maintain your code. Go is great for this.

    Ruby is so powerful but simplicity is the best if 
    other people are going to read and maintain your code.
Amen. Keep it simple for a large shared Ruby application, such as a Rails app.

More advanced Ruby (writing your own operators/iterators/whatever, metaprogramming, extending the language itself, whatever) is best reserved for Ruby frameworks, not applications.

Re: Ruby 3.2’s YJIT is Production-Ready

#99

Post by JohnBooty »

config_yml wrote: post #40
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!

As someone experienced in Ruby (and Rails), I've also always had the opposite experience. Very little options!

There haven't been a ton of choices when I've looked for Ruby/Rails jobs, but I never had much trouble landing one. They usually seem pretty relieved to have found somebody.

When I've been on the hiring side of the equation, it's been very tough to find candidates.

Re: Ruby 3.2’s YJIT is Production-Ready

#100

Post by xutopia »

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.
Post reply on HN