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

241–250 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#241

Post by w-ll »

daviding wrote: post #225

I've set this up in a staging environment of one of our apps to take a look. The staging environment we use for one-offs is on Heroku (can stand one up/down quickly), and the first issue is that a lot of the 'easy to deploy is a feature' PAAS platforms is that they bill by web/worker size restricted by memory rather than just pure virtual CPU power. Render etc all does this as well, and the memory headrooms are low.…

OT(ish) but a t3.medium on ec2 with 2v cores and ~4gb of mem is $33 a month ondemand. $20/mo on ri, and $10/mo spot.

I'm mostly done with Heroku. With one kinda big app left, all other envs, and projects are now just on aws without the tax of heroku.

And I was a big heroku fan, but their recent decisions made me shop around. I do miss the price $$ of metal in a dc, but not the price :clock: of metal.

Re: Ruby 3.2’s YJIT is Production-Ready

#242

Post by weatherlite »

aidog wrote: post #238
weatherlite wrote: post #39

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

Funny that you say that. If AI writes code, it should be Ruby, because it's shorter and easier to read. I'm making a site and love ChatGPTs Ruby code. PS: Any Microsoft people here? Ruby could be 10x faster on Windows, if we figure out how to load files faster! https://bugs.ruby-lang.org/issues/19325#note-11

Ah I meant if the AI is so capable in writing code there won't be any need for a human to read the code anymore. The "code" will be a bunch of english requirements, like an essay describing the program. Its unclear what language ChatGPT would use in that case (and who cares if the human is no longer important?).

Re: Ruby 3.2’s YJIT is Production-Ready

#243

Post by sdf4j »

bobbylarrybobby wrote: post #207
fxn wrote: post #185

Earlier quoted context omitted.

This is not true. In Ruby, tests are the same you'd write in any other language. You test that things do what they are supposed to do, not the types of parameters or return values.

Ok but if you can't constraint the types passed to a function then the universe of objects you have to test is massive. For instance you may have a performance benchmark that checks that a certain operation runs in a certain big O -- say, you want to make sure a contains(collection, elem) functions runs in constant time. If you can't constrain the type of collection (to be some kind of Map, say) then you are left tes…

That example is not very grounded on reality, isn't it?

Re: Ruby 3.2’s YJIT is Production-Ready

#244

Post by sitkack »

nickjj wrote: post #218
simantel wrote: post #27

Earlier quoted context omitted.

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

It was supported immediately for Alpine based images because rustc 1.60+ was available in that distro. Initially when 3.2 was released Debian based images didn't support it because Bullseye ships with a version of rustc that's too old to compile YJIT. But https://github.com/docker-library/ruby/commit/6db728e addressed this a few days ago by installing a pre-compiled version of rustc straight from Rust and YJIT is ava…

    $ docker container run --rm ruby:3.2.0-slim-bullseye ruby --enable-yjit -v
    ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [aarch64-linux]
Runs on Arm as well!

Re: Ruby 3.2’s YJIT is Production-Ready

#245

Post by jojo14 »

weatherlite wrote: post #242
aidog wrote: post #238

Earlier quoted context omitted.

Funny that you say that. If AI writes code, it should be Ruby, because it's shorter and easier to read. I'm making a site and love ChatGPTs Ruby code. PS: Any Microsoft people here? Ruby could be 10x faster on Windows, if we figure out how to load files faster! https://bugs.ruby-lang.org/issues/19325#note-11

Ah I meant if the AI is so capable in writing code there won't be any need for a human to read the code anymore. The "code" will be a bunch of english requirements, like an essay describing the program. Its unclear what language ChatGPT would use in that case (and who cares if the human is no longer important?).

If an AI were meant to write code it would be Python. That is english with very few syntactic sugar mainly parens and colons.

Unless the result wouldn't be meant to be read nor understood by anyone.

IMHO Python is the closest to pseudo-code specifications.

Re: Ruby 3.2’s YJIT is Production-Ready

#246

Post by lmm »

yawaramin wrote: post #240
lmm wrote: post #232

Earlier quoted context omitted.

> Oracle goal here is to make a good enterprise ready DB solution Maybe. Or maybe it's to soak naive clients for all they're worth. The remedy for bad benchmarks is good benchmarks, not no benchmarks. > Just look at the « independent and fair review » that Top Gear made about Tesla. What about it? It was accurate and informative (unless you think Tesla lied about their range stats). The good points about electric car…

> The remedy for bad benchmarks is good benchmarks, not no benchmarks. The comment you replied to just said Oracle allows running benchmarks internally, though.

Sure. How likely is it that someone running bechmarks internally - who is unlikely to be a benchmarking expert - is going to do a better job than a dedicated benchmarking project like TechEmpower that has a whole lot of people looking and contributing?

Re: Ruby 3.2’s YJIT is Production-Ready

#247

Post by semiquaver »

xfalcox wrote: post #175
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.

> Also Oracle

Very little of Graal/Truffle is locked behind an oracle license. The community edition is FOSS and within 5-10% of the performance of the paid version (so still an order of magnitude above MRI with or without YJIT). The situation is very similar to HotSpot/OpenJDK.

https://www.graalvm.org/community/opensource/

Re: Ruby 3.2’s YJIT is Production-Ready

#248

Post by sitkack »

jrochkind1 wrote: post #115
hardwaregeek wrote: post #31

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.

No, I'm afraid I'd say Sorbet/RBS haven't really been catching on widely.

https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet looks really cool.

You know the yjit folks are going to take this and make yjit even faster right?

Re: Ruby 3.2’s YJIT is Production-Ready

#249

Post by semiquaver »

hardwaregeek wrote: post #31

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.

Matz poisoned the well once sorbet was gaining traction by releasing a nearly useless competitor (RBS) and refusing to allow any interop.

Re: Ruby 3.2’s YJIT is Production-Ready

#250

Post by semiquaver »

bobbylarrybobby wrote: post #207
fxn wrote: post #185

Earlier quoted context omitted.

This is not true. In Ruby, tests are the same you'd write in any other language. You test that things do what they are supposed to do, not the types of parameters or return values.

Ok but if you can't constraint the types passed to a function then the universe of objects you have to test is massive. For instance you may have a performance benchmark that checks that a certain operation runs in a certain big O -- say, you want to make sure a contains(collection, elem) functions runs in constant time. If you can't constrain the type of collection (to be some kind of Map, say) then you are left tes…

Try sorbet in a real project before you make this claim. It’s not perfect but it’s pretty good.
Post reply on HN