Live data from Hacker News

Ruby 3.2’s YJIT is Production-Ready

shopify.engineering

251–260 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#251

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…

People often say this but it's nowhere close to universal. Ruby is 24/42 of most loved langs. https://survey.stackoverflow.co/2022/#technology-most-loved-...

I don't say ALL people, it's "people like me", why care about numbers ?

Re: Ruby 3.2’s YJIT is Production-Ready

#252
post #234

I start to have less love for technical pride languages and love business backed languages like Ruby more. It also means wide ranges of library, more jobs. Great or elegant niche languages put me in bad position so far. (Also sick of developer complex)

I'm with you on this as I get older. 'Been fascinated with Clojure for years but now sick of being out in the cold/on the fringe as it hasn't really converted into anything which brings home the bacon so I've turned to Java and Javascript lately. Will even do PHP if necessary if it means more paid work as a solo dev.

Hence why I embrace the FP stuff that lands on Java, C# and co.

It might not be as nice as having the original package, but it is good enough approximation while using boring technology (TM).

I leave the cool languages for hobby coding.

Re: Ruby 3.2’s YJIT is Production-Ready

#253

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.

Not everyone, other than for a specific customer project, I have mostly worked in SQL Server or Oracle, and slowly approaching 50 now.

There are still quite a few enterprise workloads that only the likes of stuff like DB2 are a match for them.

Re: Ruby 3.2’s YJIT is Production-Ready

#254

Earlier quoted context omitted.

Tragically, one of the principals behind TruffleRuby (and researcher at Shopify) was Chris Eaton and he passed away a few months ago. I'm not sure where this leaves TruffleRuby itself, or plans to implement it at Shopify. (Rest in peace, Chris, and may your memory be a blessing to those who knew you)

You have his name slightly wrong, it was Chris Seaton. Here was the announcement: https://twitter.com/flavorjones/status/1600436490885947393

thank you for the correction! typing with a hand injury today :-/

Re: Ruby 3.2’s YJIT is Production-Ready

#255

This is awesome. I am impressed. I recently wrote a toy compiler for x86_64. I use an external assembler. My dream is to write a JIT compiler runtime. https://GitHub.com/samsquire/compiler My understanding is that you generate machine code and then mprotect the code to be executable then jump to the void * as a function pointer to execute generated instructions. What I would like to understand more is tracing compile…

That looks so cool. Do you have any resources you would recommend to someone who want's to explore (or develop as you have) in this subject?

Write a C program that does something interesting or useful then compile it with -S and inspect the assembly.

I am a beginner at assembly and learned everything from GCC.

There's so many details. I learned about rbp+rsp registers recently. And from Reddit post on the compiler someone told me I need to keep the stack aligned.

Re: Ruby 3.2’s YJIT is Production-Ready

#257
post #157
post #147

Earlier quoted context omitted.

Well, in 2005, you didn't.

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

Well, the GP was very explicitly discussing the situation in 2005, which led to the then appeal of dynamic languages. Comparing with the situation in 2023 doesn't seem to contribute?

Re: Ruby 3.2’s YJIT is Production-Ready

#258

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.

Rails is like that first college girl/boy friend one had. Long gone, due to practical considerations, but that their fragrance, memories and love you felt for them then, is still buried somewhere deep in your heart.

Rather troubling experience are those bad days with your current real one, and you suddenly remember those sun kissed, beautiful days with your dearest ruby :D

Re: Ruby 3.2’s YJIT is Production-Ready

#259
post #235

Earlier quoted context omitted.

Looks like it’s still a WIP https://github.com/oracle/truffleruby/commits?author=eregon

With due respect to the tireless efforts of the TruffleRuby team TruffleRuby always seemed fated to be forever almost ready. I first came across it in 2013, I think it was, but there was always a not-quite-ready factor. If I remember the show-stopper was that it was unlikely to ever be Rails compatible but I may be wrong.

https://ruby.social/@eregon/109280839376585363

Tl;Dr it runs rails for a while already, it even runs mastodon.

Re: Ruby 3.2’s YJIT is Production-Ready

#260
post #142

Earlier quoted context omitted.

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?

Last time I tried Dart (2020?), it was pretty easy to confuse the type system and get it to just abandon all hope of typing a fairly simple expression. I remember the early Dart presentations in which the developers very clearly stated that they didn't even try to make the Dart type system sound, because they felt that it would complicate the life of users.

Apparently, these days, Dart claims to be sound... except they seem to have redefined the meaning of type soundness along the way: https://dart.dev/guides/language/type-system#runtime-checks

Post reply on HN