I've set this up in a staging environment of one of our apps to take a look. The staging environment we use for one-offs is on Heroku (can stand one up/down quickly), and the first issue is that a lot of the 'easy to deploy is a feature' PAAS platforms is that they bill by web/worker size restricted by memory rather than just pure virtual CPU power. Render etc all does this as well, and the memory headrooms are low.<p>This means that you often have to deal with, say 512 MB per instance, and then if using something like Puma, have to work out how to split concurrency vs memory footprint. What I'm finding is that v3.2 YJIT loves memory, so I have to trade off that, which means less concurrency per process. Benchmarking it quickly, the 15% gains I might get on the thread aren't worth having to move to just 2 threads on a 512 MB instance versus the 3 threads I can get with YJIT not enabled.<p>I think it's really neat and will continue to track it, but the performance in terms of memory trade-off isn't there quite as yet for our app profile. Not sure if others will find the same, but I guess its if their production environments aren't PAAS's with low memory headroom or not.
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. <i>Great</i> or elegant niche languages put me in bad position so far. (Also sick of developer complex)
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.
This is awesome. I am impressed.<p>I recently wrote a toy compiler for x86_64. I use an external assembler.<p>My dream is to write a JIT compiler runtime.<p><a href="https://GitHub.com/samsquire/compiler">https://GitHub.com/samsquire/compiler</a><p>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.<p>What I would like to understand more is tracing compilers and how they optimise hot loops. And how they deoptimise and optimise at runtime based on runtime information.
I'm still a shameless ruby fanboy at heart. To be fair, its almost all devops type tasks but there is something about that language that just clicks with me, and while I def have to use python more than ruby, I still love ruby.
I'm pretty sure (there isn't a lot of info on how to enable it in production workloads) we're running YJIT in production and didn't notice any improvement in load times, CPU usage or anything really. If any slightly higher metrics across the board.<p>We're using Rails as API and web frontend with a pretty high number of requests per second, so I was hoping we'd see something. Does anyone have any experience rolling it out?
It's been a sec since I've used Ruby. How's the typing story? Seems like Sorbet is doing quite well, but are there comprehensive typings for the ecosystem, like TypeScript? Because with ergonomic, comprehensive type checking and a JIT, Ruby might be a tempting option again.
I'm so grateful for these geniuses working tirelessly on improving the language and runtime, and it allows me to just add an argument and magically my code runs faster.<p>It's been fascinating following Maxime working on Yjit.
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.<p>I first time learn Ruby from zero to "hero" in production confidently is in just under a week. And as far as i know, no other language could bring me such experience.
It shows that Ruby still has life left in it yet. The language itself is wonderful, there's a great ecosystem of tooling but the performance was always lagging. Hopefully some of this makes it a choice for people once more over other more esoteric languages. My only concern here would be the time and sunk cost fallacy of someone like a Shopify working on a Ruby JIT. It reminds me of when Facebook was working on the HipHop VM for PHP code and compiling PHP to large C++ binaries. I mean I get it, you have millions of lines of code, you don't want to rewrite it, but I often wonder, is there a better solution to this? Is there just a natural path towards, write new things in a new language and leave the old behind? Genuine question, because I'm not talking about rewriting the stack, I'm just talking about not investing significant amounts of time in low level infrastructure that's totally unrelated to business priorities. Yes fast code means better user experiences but often there's alternative ways around this than doing some literal JIT compiler work.
I use Ruby and Chef at work (MAANG).<p>For side projects, I use Rails 7 to get things going and replace components selectively with native extensions and separate processes.<p>It's all about productivity, especially when small, because performance is rarely an issue.
You love to see the continued investment in this language. I've been using Ruby for about a decade and I'm still enjoying writing code in it. I hope the language continues to improve and the community stays vibrant.<p>I can remember about 8 years ago someone telling me how they were worried Ruby (and Rails) was dying. At this point the community could dry up and I think I'd still stick with it.
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
> Multiple large clusters of servers distributed across the world, capable of serving over 75 million requests per minute<p>That doesn't say anything at all sadly.<p>Ruby people seem to be sensitive when someone asks them about performance, my last question about that was downvoted heavily here.<p>I don't know any Ruby, I know how much Go can handle with the stdlib, a single non-parameterized route, returning "hello world". On my machine xeon e3-1275v5 with 8 threads 1000 concurrent wrk about 220k/ rps. Errors start appearing (aka non-200 results) between 5000 and 6000 concurrent.
Don't forget to ulimit -n 10000 or more before you start wrking.<p>Alternatively can you provide a simple single route hello world in Ruby so I can bench it myself with this Ruby 3.2 YJIT? Maybe also how to build and run?<p>Yes, I'm being serious.
I'm also guessing that Ruby with Rails has a large overhead compared to Go and just the stdlib. So that comparison wouldn't be fair, but I guess it is what it is, since we're talking semi real world scenarios (yeah don't get your ocd panties in a bunch) and Rails AFAIK is the standard for Ruby web development while the stdlib in Go is also used quite often.
Is there a name for this syndrome? The same thing happened at Github. Ruby and Rails are slow enough in production that they dedicate a specialized, long-running internal team to it. This team doesn't contribute directly to the product. They hire core Ruby and Rails maintainers, also not to contribute to the product, just to try to help improve their slow software. It's a dream job that shouldn't exist.<p>If you tell me that Ruby and Rails scaled for Github and Shopify, be careful using that as an argument for choosing Rails for your company. Rails definitely didn't scale for Github, and doesn't appear like it scaled for Shopify, until a manager greenlit a year long JIT project unrelated to Shopify. If your company has as many resources, free cash, klout to hire core Ruby maintainers, and enough downtime you can throw a few engineers at a non-product problem for a few years, then sure, go ahead and use that reasoning.