Proposal to Merge YJIT into Ruby
bugs.ruby-lang.org
bugs.ruby-lang.org
It was a minimal pure ruby service deployed as a tomcat servlet.
Despite not using any heavy weight framework (eg. rails etc.) its performance (after warmup) was nowhere close to "almost C like".
JVM gives you true multithreading etc. but claiming that JRuby performance is C like is just misleading.
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.
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.
I don't, but you said "almost C like".
"C like" as in the human doesn't see a difference.
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.
Everyone who uses features such as fast-forward and run-ahead.
Was it fast? No. Was it "good enough?" yep. It never fell over.
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 may be based on wildly different benchmarks, but still sounds much more compelling than 7-40%.
I wonder what drives the difference...
As I hinted in my post, it might be more instructive to see if programs compiled with MyPyC or Nuitka run faster than PyPy or GraalPython.
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.
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.
[0] https://speed.yjit.org/benchmarks/bench-2021-09-28-070945
Regardless, I hope to hear of some kind of apples-to-apples comparison as the respective projects progress!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
:)
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.
I would absolutely recommend Rails for most startups whose central product is a web application.
Yes, Rails is very mature but the difference is not that huge anymore.
Is Phoenix really that close to Rails in terms of ecosystem system maturity? I haven't done any real world work with Phoenix. So I couldn't judge.
More often that not most people suggest Y is close to X. And the difference is not that much when Y is already 80% to X.
Reality is that 20% is a huge difference. That takes as much time to reach the previous 80%.
And this could be used across many different subject / domain. It is a common error in comparison.
The only thing that came close or even exceed Rails ecosystem is actually another dead or unpopular language. PHP with Laravel.
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.
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.
Did you just say that investing in language performance is a red flag?
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.
What we might see is less people moving from Ruby/Rails to X because of speed, but that's about it.
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!
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).
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.
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.
Performance, for the most part, can come later. Good enough is good enough.
For those curious about what it brings to the table, just follow Maxime's link to RubyKaigi 2021.
30min talk. Slides are here: https://rubykaigi.org/2021-takeout/data/slides/Maxime-YJIT-R...
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.
Noticed for a while, before Swift was even an idea, Apple toyed with Ruby as the next Mac OS X language.
Things did not worked out as planned and the main designer created RubyMotion out of that effort.
great!
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: