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-...
Ruby 3.2’s YJIT is Production-Ready
251–260 of 304 posts
Re: Ruby 3.2’s YJIT is Production-Ready
#252I 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.
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
#253Earlier 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.
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
#254Earlier 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
Re: Ruby 3.2’s YJIT is Production-Ready
#255This 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?
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
#256Re: Ruby 3.2’s YJIT is Production-Ready
#257Earlier 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?
Re: Ruby 3.2’s YJIT is Production-Ready
#258Glad 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.
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
#259Earlier 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.
Tl;Dr it runs rails for a while already, it even runs mastodon.
Re: Ruby 3.2’s YJIT is Production-Ready
#260Earlier 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?
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