I'm wondering about what impact would this have in Basecamp's hosting bills...
I would be super interested to read about how many servers they run, etc.
Ruby 3.2’s YJIT is Production-Ready
201–210 of 304 posts
Re: Ruby 3.2’s YJIT is Production-Ready
#202Earlier quoted context omitted.
I used to have that attitude. Then I wrote my first Ruby project as an experiment. That was 17 years ago, and the majority of the code I've written since has been Ruby. What clinched it was that the first Ruby project I wrote involved trying to reimplement a piece of C code we had. It ended up 10% the size with more functionality, and it took me a tiny fraction of the time to write. If you write code the way you writ…
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…
Unfortunately static typing has turned into a religion.
IIRC someone looked at Github issues a while ago to understand the impact of dynamic typing on defect rate. What he found was that around ~1% of bugs in JS/Python/Ruby enterprise systems were type-related.
Re: Ruby 3.2’s YJIT is Production-Ready
#203Earlier 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…
Its all guts, feels, and "everybody knows" - but afaik there's been no hard proof about statically typed languages being superior to dynamically typed ones, or vice versa.
The big difference between the two that I noticed is that dynamic camp doesn't aggressively proselytize. And it doesn't shame infidels (it pities them, if anything).
Re: Ruby 3.2’s YJIT is Production-Ready
#204Earlier 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…
Unfortunately static typing has turned into a religion. IIRC someone looked at Github issues a while ago to understand the impact of dynamic typing on defect rate. What he found was that around ~1% of bugs in JS/Python/Ruby enterprise systems were type-related.
Did that include bugs due to encountering unexpected nulls?
Re: Ruby 3.2’s YJIT is Production-Ready
#205Earlier quoted context omitted.
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 ...
The solution is to be religious about testing and writing tests. If you've done it well, refactors are pretty safe and your objects are pretty well understood.
Both religions are leading you astray.
The solution is to become a software atheist and just break things down when they no longer fit in your head.
Interestingly, this seems to be what microservices originally were about until they got twisted by hype.
It is also what OOP was about, until it got twisted by another religion.
Re: Ruby 3.2’s YJIT is Production-Ready
#206I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?
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)
Chris Seaton
Re: Ruby 3.2’s YJIT is Production-Ready
#207Earlier quoted context omitted.
Ruby's typing story is still the worse-than-modern-Java boilerplate of writing loads of unit tests just to make sure an object is the type that you think it is.
This is not true. In Ruby, tests are the same you'd write in any other language. You test that things do what they are supposed to do, not the types of parameters or return values.
Ok but if you can't constraint the types passed to a function then the universe of objects you have to test is massive. For instance you may have a performance benchmark that checks that a certain operation runs in a certain big O -- say, you want to make sure a contains(collection, elem) functions runs in constant time. If you can't constrain the type of collection (to be some kind of Map, say) then you are left testing that all paths that call contain do so with a Map and not, say, a List. In a typed language the type system would ensure that for you.
Re: Ruby 3.2’s YJIT is Production-Ready
#208I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?
You can enable YJIT and get a ~30% speedup by passing an extra environment variable to your Docker container. Moving away from CRuby to an alternative Ruby is a lot harder than that. Also Oracle.
> Moving away from CRuby to an alternative Ruby is a lot harder than that.
In what way? Truffleruby passes over 97% of CRuby's specs and it runs on my command-line without any problems so far. It was easy to install too. I'm sure if I dig into those failing specs I'll find something but will it be important? I'd love to know.
Re: Ruby 3.2’s YJIT is Production-Ready
#209Earlier 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
TruffleRuby can’t run production Rails traffic today, and YJIT can.
The README states "TruffleRuby runs Rails". Anything specific?
Re: Ruby 3.2’s YJIT is Production-Ready
#210Earlier quoted context omitted.
Shopify like many other successful Ruby shops were successful because of the speed of development. The cost of hosting is secondary and any company the size of Shopify can afford to involve a small team to reduce hosting costs... with impact for the developers happiness to boot.
I wonder if YJIT actually did decrease infrastructure costs for Shopify, seeing as it requires ~3x more memory. For my business, it’s come out about even. But a >30% decrease in response time is worth it, for me at least. I run many small servers (2 processes each), but IIRC, Shopify runs beefy servers. So may be different for them.
> as it requires ~3x more memory.
Not sure were you've seen this, but that's absolutely not normal. The YJIT memory overhead is certainly sizeable, but is generally at least an order of magnitude smaller than that.