Live data from Hacker News

Ruby 3.2’s YJIT is Production-Ready

shopify.engineering

161–170 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#161
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

i'm pretty sure eregon is biased...

Re: Ruby 3.2’s YJIT is Production-Ready

#162
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

Even if GvR promotes it fully, it won't be adopted unless c extensions work out of the box.

Python without its crazy amount of extensions in c-api won't survive.

Re: Ruby 3.2’s YJIT is Production-Ready

#163
post #160

Earlier quoted context omitted.

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?

and when was oracle the fastest database? You are not allowed to even publish that metric....

Re: Ruby 3.2’s YJIT is Production-Ready

#164
post #142

Earlier quoted context omitted.

I don't know if I'm just a bad programmer and everyone knows something I don't, but it seems to be the benefits of a strongly typed language are wildly overblown. It's a different way of thinking about building software and it saves you from a few mistakes you could otherwise make, but you'd think I was writing code with a hammer and chisel the way people on HN talk about languages like Ruby. It feels a lot like the…

Strongly and statically typed languages are not very common. Most languages that pretend to be strongly + statically typed aren't, by a fairly large margin (I'm looking at you, C++, Objective C or Dart). However, once you have strongly + statically typed languages, you can very often create safe-by-design (tm) APIs, APIs that are simply impossible to misuse (for some definition of misusing). A trivial example (which…

> Most languages that pretend to be strongly + statically typed aren't, by a fairly large margin (I'm looking at you, C++, Objective C or Dart).

What about Dart doesn't feel sufficiently typed for you?

Re: Ruby 3.2’s YJIT is Production-Ready

#165

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…

> Since optional typing, dynamically typed languages got the guarantees of type checking

Optional typing, at least in TypeScript, will not give you the guarantees of type checking. It finds many of your type errors, but not all of them because the type system is deliberately unsound.

Re: Ruby 3.2’s YJIT is Production-Ready

#166

Earlier quoted context omitted.

I don't know if I'm just a bad programmer and everyone knows something I don't, but it seems to be the benefits of a strongly typed language are wildly overblown. It's a different way of thinking about building software and it saves you from a few mistakes you could otherwise make, but you'd think I was writing code with a hammer and chisel the way people on HN talk about languages like Ruby. It feels a lot like the…

For me, it comes down to the fact that static typing completely eliminates large classes of bugs. It therefore dramatically lowers the testing load. The compile step essentially performs its own tests. Think about all the test cases I save myself from having to write... Beyond that, it also forces me to think structurally from the start. But I tend to be working on rather complex applications, I almost certainly woul…

[deleted]

Re: Ruby 3.2’s YJIT is Production-Ready

#167
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

Even if GvR promotes it fully, it won't be adopted unless c extensions work out of the box. Python without its crazy amount of extensions in c-api won't survive.

This is something that's up to the community really. The PyPy developers early on made a new FFI that is also available for CPython, sadly not entirely as easy as the classic API but completely functional and if there was a push to rewrite extensions to use that FFI (or provide dual-paths) then the gap could be bridged.

Re: Ruby 3.2’s YJIT is Production-Ready

#168
post #45

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’ve been doing Rails development for 10 years now and I just don’t think it’s possible to safely update anything in Ruby. Our app has 20,000 rspec unit tests and 5,000 cypress browser automation tests and basically every ruby patch version creates breakages that somehow slip through all of that despite nothing being mentioned in the changelogs.

Re: Ruby 3.2’s YJIT is Production-Ready

#169

Earlier quoted context omitted.

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)

I’m not aware of anyone using it, we evaluated it at work and decided it wasn’t worth using despite us making heavy use of TypeScript and Rust.

Re: Ruby 3.2’s YJIT is Production-Ready

#170
post #138

Earlier quoted context omitted.

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…

I've seen more than one ruby dev proclaim they specifically don't want types; if you want a language that has it, there are plenty to choose from.

My take here is that typed-ruby is something SOME people want (I'm one), but a lot don't.

I'm not sure what level of force that provides to anyone who has either tried or is considering adding it to the language.

Post reply on HN