Pretty cool. Tbh, the benchmark result improvements are not as big as I'd expect (ie, the biggest improvement is "only" 41% compared to non-JITted code) but speedups are speedups and this is pretty nice considering you can get it for (almost) free with a single command line flag.
There are plenty of Ruby JIT in the past which shows order of magnitude improvement in micro-benchmarks but doesn't even run rails. ( I think to the point people gave up making JIT for Ruby )
So running these complex code, not only just those heavy benchmarks like railsbench but also their production code all while passing their test is pretty damn impressive if you ask me.
And as pointed out both inside the rubykagi talk and twitter, there are lots more optimisation in the pipeline.
At the scale of Shopify, those improvement could easily be million dollar saving per year.
Maxime explains in the video[0] that they have other optimizations planned but haven't implemented them yet. It will be very interesting to see the impact :)
Without knowing against which benchmark these numbers were measured make them pretty much meaningless. YJIT achieve a 700%+ speedup on some micro-benchmarks [0] too (see `30k_ifelse` and `30k_methods`).
But that's nowhere near the gains on more macro benchmark or real world code. I wouldn't be surprised if that 170% was on a similar micro-benchmark.
I would guess that the difference is static type information. Similar to how PyPy is faster than CPython, but Cython (and probably Nuitka and MyPyC) is faster than PyPt.
JITs don't need static type information, because they have that information available to them anyway. Cython is not a good example for performance comparisons, because while you can compile Python code unchanged with it, the performance gains are very modest, as Cython still uses the full, unabbreviated Python data model; it only cuts out the overhead of the CPython bytecode VM: everything else is still there, and that's what dominates. Cython also allows you to write C-with-a-Python-syntax, which then has the performance profile you'd expect from C - but you're not writing Python any more.
> JITs don't need static type information, because they have that information available to them anyway.
I've heard that V8 can specialize functions but will sometimes unspecialize them if you use them with unexpected types. Using static typing can push your code into patterns that "helps" the JIT, even if it doesn't use directly the type information that you wrote.
Even that's not very large. Moving from a bytecode VM to a JIT is a big jump in codebase complexity that all future maintainers and contributors to Ruby will have to take on. The set of people who can contribute to a JIT is much smaller than to a bytecode VM. I'd guess one or two orders of magnitude.
I can't see that codebase complexity being worthwhile unless the JIT at least gives you something like 2-3x better perf across the board. In Java and JS VMs, you do see an improvement of that scale.
That's an interesting take. It seems like Matz and the rest of Ruby core don't see this as such a big deal though as this is going to get merged. I can see the added complexity but this can just be another piece of Ruby core maintained by a few experts, no? Seems like most Ruby contributors specialize anyway.
And even then, I haven't benchmarked myself, but I wouldn't be surprised most NES emulators written in C or other native languages out there would do way more than 150FPS.
Edit: and it doesn't really matter either way because while useful, optcarrot is a very different workload from what Ruby is generally used for.
very different workload from what Ruby is generally used for.
Ruby is generally used for a lot of things, including scientific computing. I'm using it to process sound and make videos about sound, for example. Audio processing isn't too far off from the type of hot loop an emulator would have, so I hope to see benefits from YJIT in my own work, and will also try TruffleRuby once I've finished my current round of video editing.
Who cares if they do more than 150 FPS, when humans cannot see more than 60 FPS, unless we are talking about VR, which is nonsense for a NES emulator anyway.
Trying to win the benchmarks game makes people lose sight from what actually matters.
SPA would never had taken off if it wasn't for the work done in JavaScript JITs.
Similarly, Ruby JITs can open doors for just being the language used for Rails applications.
> Who cares if they do more than 150 FPS, when humans cannot see more than 60 FPS
Things in 120 FPS feels smoother than in 60 FPS. Less than 60 compared to 30, but it's still noticable. I don't know the exact mechanism, but I suppose that's because the real world has no concept of FPS and what we see is continuous, so our eyes are used to seeing something like this.
Back in the day, I used JRuby because it was the only way I was able to run Ruby on Windows 2003 servers that I was forced to use while working for the Federal Government. (Yes, Thin and Mongrel existed, but their perf on Windows was REALLY bad)
Was it fast? No. Was it "good enough?" yep. It never fell over.
I keep seeing small incremental speed improvements and overall these changes amount to a compounded effect over time. Yet we keep hearing that ruby is dead or rails is dead and the very fact that we have large companies like Shopify or Stripe working hard to make the language and tools faster is proof that this is not dead...
When people say Ruby is dead, I dont think any one actually meant "dead" in literal sense. Even COBOL is not dead.
A more correct term from their POV would be Ruby is dying, roughly translating to Ruby is not growing. Or what they really meant is Ruby as a market ecosystem is shrinking.
And you have to take in the context from the one speaking of it and the one listening to it. The ecosystem is practically dead in many places on Earth. US and Japan tends to be the only place with a large enough sustainable market. ( And US is big enough that you could segment it into multiple different market ) The only place in EUR that seems to be doing ok with Ruby Rails are Germany and UK. But even then I am suspecting both may be on the verge of decline if not already declining. So if someone saying it is vibrant in US and someone listening to it say from China or Eastern Europe then they will obviously have disagreement.
Ruby as a language has always been the odd one out in the Top 10 ( or at least used to be Top 10 ) where it has very little to particularly zero resources backing. Every other language on the list has FAANG behind it in one form or another.
But now with the help of Shopify, Github and Stripe. I believe the future of Ruby Rails is pretty damn good. Now both YJIT and Rails are tested Shopify and Github production code base. And YJIT manage to speed up one of the slowest part of Rail, ActiveRecord.
Rails 7 and Ruby 3.1 may be the renaissance of the ecosystem.
I don't think the speed of Rails will lead to a renaissance. Rails was very popular at one point because it allowed you to ship a MVP way faster than with the alternatives. It was also at the peak of Heroku, so the ops part was easy. These days it's not true. Pretty much every major language has a viable Rails alternative (except JS for some reason). You could argue that we've grown backwards, as it seems that deployments are harder than before, and same with building things. I think it's a symptom of the industry being dominated again by a few big players, so the ecosystems are optimized for them.
What we might see is less people moving from Ruby/Rails to X because of speed, but that's about it.
We also might see more people moving back to Rails because of speed, because as they probably know now after rewriting in a different ecosystem... it was usually their app code that was the problem.
I don't think that's true. Sure some people will do rewrites for no reasons, but they aren't usually the type to then go back to something once it has improved, since they weren't after real world metrics and improvments but novelty. Maybe a bit to try the hotwire stuff before going to Phoenix, Go, Rust or even Nim.
Haha, I should note I wasn't actually very serious they would move back. I just wanted to highlight that a lot of people have moved off Rails for {insert other thing here} because they just have no idea how to debug or analyze performance and bottlenecks. I've fixed a lot of Rails apps as a consultant, and its almost always bad DB usage (AR queries or lack of indexes) and/or lack of caching.
I do think Ruby will make a more compelling case against its peers (php/python/node). Especially against php it can win some market share since Ruby is perceived as a cleaner language. Also to this day Node hasn't come up with a big Rails like framework. It can't hurt is all I am saying, developers seem to be thoroughly impressed by this type of big corporate backing even if it means very little for their day to day usage.
> Especially against php it can win some market share since Ruby is perceived as a cleaner language.
I don't think that's how people choose languages. Ruby had a lot of momentum in the US, but never really got that in Europe. PHP is very popular here, and I think most of the time people will choose it over Ruby because that's what people around them know, and that's what popular.
Python can do basically everything Ruby can, (web and scripting mostly), but can also handle pretty much anything else. If you're starting out today, it's probably a better choice than Ruby.
> Also to this day Node hasn't come up with a big Rails like framework.
In a way, React is the big Rails-lile framework. Just like with Rails the frontend wasn't the most important part, with React the backend isn't the most important part.
I do agree that Rails and Ruby getting faster is good. Having a JIT usable with regular code is honestly great!
React offers an unopinionated path for the front end only, thats not really Rails. I agree php has tons of momentum in Europe. Its also probable some people will get sick of it eventually and hoprfully Ruby is now a more viable option. Php is the most hated technology in the last Stackoverflow survey, thats pretty bleak. But yeah I tend to agree its mostly momentum based and Python and Node ate a lot of Ruby's lunch. To me Ruby is nicer so I am sticking to where I am happy.
> React offers an unopinionated path for the front end only, thats not really Rails.
I would argue that they are close, with Rails getting less and less "convention over configuration" with time, and people focusing more and more on the frontend. They were made at different times and it shows, with React leveraging plenty of ways to not really write backend code anymore (GraphQL, things like Prisma, Firebase).
> Its also probable some people will get sick of it eventually and hoprfully Ruby is now a more viable option. Php is the most hated technology in the last Stackoverflow survey, thats pretty bleak.
Most developers don't even know this survey exists. I'm far from a PHP fan, but the group of people that use PHP and hate on PHP is a small minority of PHP users and haters. Ruby and Rails are mostly unknown in France for example, while everyone knows Java, PHP.
> To me Ruby is nicer so I am sticking to where I am happy.
That's the important part! At the end of the day, they are relatively equivalent tools and we are humans, so emotional attachment matters. The diversity and cross-pollination benefits everyone (except beginners).
> The diversity and cross-pollination benefits everyone (except beginners).
Interesting take, never thought about it like that; it always seemed terribly inefficient to me people are maintaining date libraries in 50 languages.
But I guess you're right it would have been really boring if we only had one way to do things.
Usually when you're creating a new language, doing the basic (date library, JSON parsing, HTTP server) is a good way to get a feel for it. I do wish we could reuse more parts though, like a high-performance JSON parser or HTTP server.
It isn't just speed. I dont view this as a developer or engineering prospective.
Ruby Rails has always had a difficult value proposition to business / project owners. Why should you pay for a project written using Ruby Rails? Because developer likes it isn't a good argument. They want an abundant of developers to choose from, easily affordable, and knowing they wont have problem finding another developer 10 years down the road. That is why PHP and Java, despite getting zero love on HN are thriving everywhere.
They dont need to understanding the beauty of Ruby Rails. But they understand any Internet business will require accepting payment and hence should know Stripe. They will have at least heard of e-commence giant which is somehow making rounds in mainstream media for taking on Amazon. ( Whether you agree with that view or not ) And they are now a $170B market cap with a P/E of 70 [1]. Any project management or business owner would have at least heard of GitHub. And Gitlab if they require on premises / open source alternative. They would have stumble across Internet forum moving to a new and similar looking system called Discourse.
Basically they can piggyback on the success of these companies. And you no longer need to use hype to market Ruby Rails as a product, but actual data and evidence from current sustainable business. And these business are working together to invest into its ecosystem, the performance benefits are the counter argument when Ruby Rails will inevitably be questioned about its perceived performance limitation.
So may be not renaissance, but real opportunity for growth. Whether the market or community could capture on this is of course not always certain. but at least a fighting chance.
But yes. I do agree modern deployments sucks. I have always saved this sentiment from other discussion hoping when the right moment / submission I could get other's view on it. I also agree on many things have grown backwards in catering for big enterprise. Luckily in Rails small and medium enterprise are well represented by BaseCamp.
[1] I used to quibble when people say Shopify is an $200B market cap company. Market cap doesn't mean a thing without profit. But it turns out Shopify is much much bigger than I thought. They just made their first $1B+ quarter revenue in 21 Q2. They are no longer some company with idiotic high market valuation. They are real business.
Ruby is used in France, Nehterlands etc. Sure its no way near Python/Node/js but I do think its "sustainable", e.g you will have Ruby jobs there 20 years from now.But yeah php is freaking huge in the Netherlands, maybe this type of headlines will help change that.
No one says that Ruby is dead, beyond in the rhetorical "as the cool new thing" angle. But sure, there are companies that were started with Ruby back when it was the cool thing (2008 - 2011ish), and inertia, along with a heavy dose of cargo culting, has them doubling down. If those companies started in 2019 they'd be all in on Go. Today...I don't know...Rust?
I posted a couple of weeks back that it is remarkable that almost all Ruby advocacy/development comes from Shopify, and here is yet another example. Similarly, recent claims about Ruby's growth among the "top N websites" was more than 100% accounted for purely by a quirk in the way Shopify implements their storefront (as a subdomain which allowed Shopify's choice of technology to trojan horse in the metrics onto hundreds of thousands of domains).
Clearly people make solutions with it, in the same way that people made remarkable solutions with PHP.
> If those companies started in 2019 they'd be all in on Go. Today...I don't know...Rust?
Not a chance. Dynamic languages, especially Ruby, are way more productive than Go and Rust. Go is basically a less complicated, vm-less Java and Rust is a safer C++. Neither compete with Python, Ruby, Javascript or PHP.
I'm not sure what "not a chance" is referring to. Do you doubt that companies are being built around products not built in dynamic typed languages?
Because there are loads. I mean, almost every major technology company on the planet.
Indeed, there are lists of the "biggest" YC companies and it's remarkable how stratified the core technologies are with the launch year. Around 2008-2011 and it was Ruby all over the place. A number of recent companies list Go as the foundation of their solution. Recently Rust has started to appear in the lists.
Shopify is successful because of a business model at the right time and right place. That they use Ruby should be ancillary, but the company seemed to have hired the "big fish in a small pond" from the Ruby world so now they're cargo culting hardcore with Ruby there, making Ruby their core technology identity, to the point that they're spending enormous engineering effort to gain the benefits that everyone else is enjoying for free with alternative platforms. Which...they can afford it. But it doesn't make it right.
> I'm not sure what "not a chance" is referring to.
That a business that would use Ruby in 2009 would use Go for the exact same thing in 2021.
Of course companies use low level tools.
But is any startup going to use the Rust version of Rails for their website? No. And on the flipside, is anyone going to use Ruby for some highly intensive numerical computation? No.
Businesses usually use more than 1 tool. Need fast computation? Use Go, Rust, C++, Java, etc... Need to prototype a CRUD website super quickly? Ruby, Python, PHP, JS. This isn't exactly a rule, but Rust isn't meant to replace Ruby any more than Ruby was meant to replace C.
"That a business that would use Ruby in 2009 would use Go for the exact same thing in 2021."
Companies are building the same sorts of solutions in Go today that they built in Ruby in 2009. Loads of web applications are being built in Go.
Like I said, around 2010 even payment (e.g. the fundamental opposite of where a dynamic type system makes any sense) systems were being built in Ruby because it was the hotness. Though no one has wed themselves to an ephemeral choice quite like Shopify has, and most other examples from that era now have a rich, diverse technology platform.
"Need to prototype a CRUD website super quickly? Ruby, Python, PHP, JS."
That's like the first 0.05% of a product. Like building your GUI in Adobe XD.
> Like I said, around 2010 even payment (e.g. the fundamental opposite of where a dynamic type system makes any sense)
What does a type system have to do with payments? The implementation of numeric types matters more, you can use a statically typed language but if you're using plain floats for a financial app you're going to have a rough time. Also a type system doesn't prevent math errors.
Ruby is also strongly typed so it's not like you can just mix up numeric types, plus has numeric types (BigDecimal) that are suitable for financial calculations (to be fair pretty much all languages do, even JS).
> Companies are building the same sorts of solutions in Go today that they built in Ruby in 2009. Loads of web applications are being built in Go.
Is there a single example on the level of Stripe, AirBnb, TripAdvisor, Shopify, etc...? Even early stage?
I don't see any Go equivalent to Rails, Django or Laravel. Most Go applications seem to be either back-end micro-services and it seems to mostly be in use in larger organisations. I have never seen a startup with <5 people using Go although I'll admit to have not looked that hard.
> That's like the first 0.05% of a product.
Is it? Tons of startups started without much more.
Yup. But I'd say part of the reason the ecosystem is so big is a testament to Ruby's productivity.
Go seems great in a team environment for enterprise software, Rust seems great for software designed to last forever, but I've never met anything that's as good at simply hacking together a solution like Ruby (maybe R for stats and related things). You can build software that does things extremely quickly.
I would be curious to hear what someone who’s written both go and Ruby with a type system (forget what it’s called) is.
My view from the outside is that while Rubyists have correctly figured out that being strongly typed is an advantage, it’s an awkward retrofit, and just starting with a language that has a native type system would be better.
To your point, the calculation as a N-thousand person profitable company is very different from what those companies would pick today were they starting from scratch.
I worked on Ruby code at Stripe using Sorbet and currently work in a Go code base full time now!
Sorbet is pretty incredible and IMO was a huge benefit in a massive code base. Not having to worry about nil checks and always knowing the shape of the input data to functions was immensely valuable. It made data transformations really easy.
I'm also a big fan of sum types which is available in Sorbet. It made expressing failure conditions with data really easy to do, and obvious to users of your code. This wasn't a pattern used everywhere though which is understandable given that it came much later in the Stripe code base.
Go is actually a pretty nice language. It really is easy to pick up and be pleasantly productive in it. The built in libraries are extremely good, and the eco-system seems to favor using as many of the standards where possible (e.g. http middlewares all use the same patterns, no matter which framework you choose).
I really dislike error handling in Go though. It's hard to actually know what errors you're receiving from functions you're calling, especially as they trickle their way up. For instance, if you're wanting to display certain error types to your users, you have to hope you've enumerated all of the potential errors returned and handle them in a janky manner (errors.Is / errors.As).
I also really dislike that lots of things can be nil, and the compiler won't really help you there. You just have to know that some things are interfaces vs others being structs.
The way interfaces are defined and used in Go are quite nice and it ends up being really easy to refactor something slightly to make it easier to test.
edit: summary, I think I would agree with you that starting with Go is likely the better option for many types of backend services. Ruby on Rails is still really hard to beat for productive web oriented services though, and I think you could do pretty well mixing the two together.
Well the advocacy comes from Stripe as well (depending on how you define advocacy exactly) and Github. Those are the big corps running huge Ruby monoliths. Is that remarkable to you in the sense you would expect more effort from other Ruby companies? I think Shopify and Stripe is pretty much enough in terms of resources. I think Cookpad and Heroku also pay for some core Ruby/Rails members to work on it full time. How much more do you need?
I have another way to look at the same thing. Ruby/Rails as a development language/framework is great and no doubts about it. I used it for many years. Would I recommend it for any new project / startup now (other than a simple CRUD with a handful of users) - No.
Shopify or Stripe are huge companies with massive codebases in Ruby, perhaps so complex that they are better off making investments in Ruby performance rather than re-writing their stack.
In fact, the very fact that these companies have to spend so much time trying to make Ruby work well tells me that something is not right.
For a startup which has limited resources why should I wait for 10% improvements in Ruby performance every 6 months, when I can already get on the rocket-ship of performance that is - Node.js or JVM or even Elixir. Kotlin for example even writes a bit like Ruby, has some decent frameworks available and will give me magnitudes of performance on top.
You choose Rails because you can build extremely fast with it (for a variety of reasons). The number one risk to a startup is not finding product market fit. Therefore, building fast is paramount. It doesn't matter how much load your product can handle if you never get the load in the first place.
I would absolutely recommend Rails for most startups whose central product is a web application.
> I would absolutely recommend Rails for most startups whose central product is a web application.
I think that depends on the product. I'm working on your usual "unbundling Excel" product, and I don't see what Rails has to offer over Django or Laravel. Maybe Rails has a better integration for "you don't need to write JS" stuff like Hotwire? But other than that, I don't think Rails is still the silver bullet that it once was.
Django and Laravel are both fine options, yes. Depends on the talent and network you already have really. The point is use an MVC framework with a mature ecosystem.
I tend to disagree, this was true few years ago but there are now tons of frameworks / boiler-plates which also enable devs to launch fast and stay fast e.g Phoenix
Yes, Rails is very mature but the difference is not that huge anymore.
Yes. Because Rails decided what the "Golden path" was 10 years ago, but pales when having to do real-time anything, concurrent anything, parallel anything, etc. also, scaling tends to be expensive.
I will admit that rails ecosystem is much larger and often you have multiple libraries that do the same thing and you can pick and choose and those gems/libraries have been around for a while.
Phoenix you can spin up a SaaS platform with realtime messaging and event handling the way you could spin up a blog with rails 10 years ago.
The bottom line is it doesnt matter in 95% of cases for the average SAAS company whether you choose to build with Node or Python or Kotlin or Ruby. They all work and modern clouds make it pretty easy to scale them. So it comes down to personal tastes. Some people will never want to use Node, and some feel the same about Ruby.
I like Ruby and I'd write a lot more Ruby if I bothered to learn Sorbet. There still isn't a language that scratches that itch of productive web development with minimal boilerplate. I've mostly started to feel uncomfortable with dynamically typed languages with lots of mutability.
I watched that last night, it was a great talk. Enough technical details to understand the how without getting bogged down in the intricate details.
Although it did remind me that I've not touched assembler in about 20 years and now I feel oooold :)
I'm really quite optimistic that this will see some good improvements in the next few years as they work through some of the CRuby bottlenecks that he mentioned.
I'm still learn about JIT but what happen if we JIT everything as in every single line of a Ruby app? Will it be way faster? So we don't have to wait for the JIT to compile during production?
You may want to look into TruffleRuby from Graal, with the "--native" flag. Particularly some of the writings Chris Seaton (project lead/founder) from Shopify has about it:
