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.
Ruby 3.2’s YJIT is Production-Ready
31–40 of 304 posts
Re: Ruby 3.2’s YJIT is Production-Ready
#32Earlier quoted context omitted.
The big difference compared to HHVM is that this is part of Ruby. It's not a separate project. Shopify is sponsoring much of the effort, but it's owned by the community. At Stripe, there are millions of lines of Ruby. Lots of it would be better off in a different language—if it had been written in another language initially. Ruby is easy to hire for, there are tens of thousands of pages of documentation for the code…
> Switching is possible, but the cost to replace it is half a decade or more. I would imagine if you're going to switch millions of lines from one language to another - you wouldn't do it by hand - you'd write something transpile it? Has any company actually done something like this before - especially somewhat recently? I can't imagine anyone doing it by hand...
You need to produce code that not just runs, but is idiomatic in the target language. I'm not aware of ANY transpilers that do this for target and source languages that run in different runtimes (i.e., not coffeeacript to JS). You need every language feature to translate cleanly, and that means that a translation failure makes it impossible to convert a logical unit (module, package, etc) at once. Simply having a translated version of the code without making it idiomatic means it's impossible to read or modify.
Re: Ruby 3.2’s YJIT is Production-Ready
#33What 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?
At 10% it's approximately the same. But say 50% instead.
If it takes 1/2 the time to do something, you can do double the work in that time.
If on the other hand, you can do 1.5x the work in the same time, it means you've made it use 33% less time than before.
With 10% less time you're taking 1/0.9 = 1.11111x more work in the same time.
Re: Ruby 3.2’s YJIT is Production-Ready
#34What does 10% speedup mean? Doing 10% more work in the same time or needing 10% less time for the same amount of work?
10% less time for the same amount of work, since we are measuring the total response time of the workload in question and looking at median (p50), p90 and p99 numbers.
Re: Ruby 3.2’s YJIT is Production-Ready
#35What 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?
Not exactly, "doing 10% more work in the same time" means needing 9(.1)% less time to do the same work (100 / 110 versus 90 / 100).
Needing 10% less time for the same amount of work means you can do 11(.1)% more work in the same time.
Re: Ruby 3.2’s YJIT is Production-Ready
#36Man that is a terrible graph. Why use tiny fonts and smush them together, them make the image small as well. I wish I could read the charts...
You can see this chart and all the numbers and more at https://speed.yjit.org/, which this chart was taken from.
Re: Ruby 3.2’s YJIT is Production-Ready
#37Earlier quoted context omitted.
> I'm pretty sure (there isn't a lot of info on how to enable it in production workloads The YJIT is not on by default in ruby 3.2, you have to specifically enable it. If you aren't sure if you have enabled it... what makes you pretty sure you have enabled it? It seems possible you have not enabled it, if you aren't confident you know how to do so? I am not using it yet myself, and don't want to put any possibly inco…
Also worth noting that the Ruby 3.2 Docker image can't run with YJIT yet, so if your production setup is in a container, it's most likely not using YJIT. GitHub issue link here: https://github.com/docker-library/ruby/pull/398
That's not correct:
$ podman run -it -e RUBYOPT="--yjit" ruby:3.2
irb(main):001:0> puts RUBY_DESCRIPTION
ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [aarch64-linux]
=> nilRe: Ruby 3.2’s YJIT is Production-Ready
#38For 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 as far as i know, no other language could bring me such experience.
Re: Ruby 3.2’s YJIT is Production-Ready
#39Glad to see Ruby still going strong it will forever be the 1st programming language I actually loved working with, and the combination of it with Rails was amazing. Had to move to the other side (Typescript, Django) but I think unless ChatGPT will write all the code 10 years from now - Rails and Ruby will still be there, providing teams with a lot of power and a lot of fun.
Re: Ruby 3.2’s YJIT is Production-Ready
#40Earlier quoted context omitted.
The big difference compared to HHVM is that this is part of Ruby. It's not a separate project. Shopify is sponsoring much of the effort, but it's owned by the community. At Stripe, there are millions of lines of Ruby. Lots of it would be better off in a different language—if it had been written in another language initially. Ruby is easy to hire for, there are tens of thousands of pages of documentation for the code…
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!