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
Ruby 3.2’s YJIT is Production-Ready
161–170 of 304 posts
Re: Ruby 3.2’s YJIT is Production-Ready
#162Python 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
Python without its crazy amount of extensions in c-api won't survive.
Re: Ruby 3.2’s YJIT is Production-Ready
#163Earlier 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?
Re: Ruby 3.2’s YJIT is Production-Ready
#164Earlier 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…
What about Dart doesn't feel sufficiently typed for you?
Re: Ruby 3.2’s YJIT is Production-Ready
#165Earlier 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…
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
#166Earlier 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…
Re: Ruby 3.2’s YJIT is Production-Ready
#167Python 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
#168For 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 ...
Re: Ruby 3.2’s YJIT is Production-Ready
#169Earlier 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)
Re: Ruby 3.2’s YJIT is Production-Ready
#170Earlier 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…
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.