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

151–160 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#151

Post by Yoric »

vidarh wrote: post #80
ajmurmann wrote: post #65

Earlier quoted context omitted.

As someone who spent a good chunk of their career teaching TDD, I agree and disagree. Yes, tests are crucial. However, which tests to write varies among other things by language. When I write Ruby, I benefit from testing even the simplest things. When I write Rust or even Type Script or Swift I'll focus much more on tests for complex logic and on integration and acceptance tests. Static typing eliminates an entire, l…

When I write Ruby, I test expected behaviours, and if there are type errors in there those tends to fall out from tests I needed anyway. If you need to test specifically for errors due types, then generally that suggests that either your application does not normally exercise those code paths at all and/or you fail to test behaviours of your application.

Does this include writing libraries for use by third-parties?

Re: Ruby 3.2’s YJIT is Production-Ready

#152

Post by pantulis »

JW_00000 wrote: post #77
pantulis wrote: post #55

Earlier quoted context omitted.

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.

No, but gradual/optional typing did come after Ruby. Back in 2005, you could choose between static typing with type checking but lots of verbosity (e.g. Java "Point point = new Point();" or C++ "for (std::map ::iterator it = myMap.begin(); it != myMap.end(); it++)") or dynamic typing without type checking but also without the verbosity. Since optional typing, dynamically typed languages got the guarantees of type che…

Isn't RBS for Ruby a way of having optional typing? (Not challenging here, honest question :P)

Re: Ruby 3.2’s YJIT is Production-Ready

#153

Post by earthnail »

pantulis wrote: post #63
byroot wrote: post #58

Earlier quoted context omitted.

If you look at the breakdown per service, EC2 (assuming mostly Ruby) seem to be at best 20% of the bill: https://twitter.com/dhh/status/1613508201953038337 So if you are to make Ruby ~10% faster, you might reduce Basecamp hosting bill by 2% at best.

Thanks for spotting that, I had missed it! This goes to show (again) that the "Ruby/Rails does not scale" myth is fictional.

There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve.

And so Ruby may scale in cpu performance, but not with your number of teams.

That’s why Spotify switched to Java (I think they were a heavy Python user before that, not Ruby, but not sure anymore - but the organisational problem is the same for those two).

Note that I still choose Rails for all my projects, but my company is small.

Re: Ruby 3.2’s YJIT is Production-Ready

#154

Post by pantulis »

jeltz wrote: post #107
itake wrote: post #49

Earlier quoted context omitted.

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.

It's good practice to use irb to quickly check stuff or inspect the programmatic surface of a new library. But that's a Ruby feature that you don't have in other languages! In no way its mandatory to code inside irb. Most of my time was spent in Textmate or Emacs.

Re: Ruby 3.2’s YJIT is Production-Ready

#155

Post by kenhwang »

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

And by many accounts Oracle makes the fastest database yet everyone still uses Postgres.

Also our experience with truffleruby is death by a thousand subtle differences. It might be 97% compatible but chasing down that 3% undocumented behavior difference on every minor version update for every gem got exhausting fast. Everyone uses and tests against cruby.

Re: Ruby 3.2’s YJIT is Production-Ready

#156

Post by letmeinhere »

treis wrote: post #138
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.

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 slapped together a competing spec (without any associated tooling) that would ensure all type information stays outside of the `.rb` file.

It seems like the only impact it has had is to dissuade people who would like some static types from adopting it, in favor of this vaporware. Contrast this with Python's embrace gradual extension of mypy type hints.

I'd love to be proven wrong, that there are thriving projects building atop RBS. I'd still _prefer_ a system that allowed me to type a function signature so that anyone inspecting it could immediately know its shape, but at least the shadow types would be _something_.

Re: Ruby 3.2’s YJIT is Production-Ready

#157

Post by FpUser »

Yoric wrote: post #147
FpUser wrote: post #117

Earlier quoted context omitted.

>"for (std::map ::iterator it = myMap.begin(); it != myMap.end(); it++)")" All you really needed is: for (auto it : myMap) and you still get compile type safety

Well, in 2005, you didn't.

Well we are not discussing 2005 version of Ruby. Why limit C++ to that particular time?

Re: Ruby 3.2’s YJIT is Production-Ready

#158

Post by v3ss0n »

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

Re: Ruby 3.2’s YJIT is Production-Ready

#159

Post by [deleted] »

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

[deleted]

Re: Ruby 3.2’s YJIT is Production-Ready

#160

Post by v3ss0n »

kenhwang wrote: post #155
the-alchemist wrote: post #143

Earlier quoted context omitted.

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

And by many accounts Oracle makes the fastest database yet everyone still uses Postgres. Also our experience with truffleruby is death by a thousand subtle differences. It might be 97% compatible but chasing down that 3% undocumented behavior difference on every minor version update for every gem got exhausting fast. Everyone uses and tests against cruby.

What? When was oracle free or opensource?
Post reply on HN