I believe with version 3.3 Ruby is back in a big way! The language focused on developer happiness and derided for its slowness is slow no more.
YJIT is an amazing technology, and together with other innovations like object shapes and various GC optimizations, Ruby is becoming seriously fast! Big Ruby shops such as Shopify [1] have been running 3.3 pre-release with YJIT and reporting double digit percentage performance improvements.
Personally I'm really excited about Ruby and its future. I can't wait to start working with Ruby 3.3 and using it on my client's production sites...
I don't know if a slight performance increase is going to sell anyone on ruby but I'm glad they're making incremental improvements on things. Being overly concerned about performance is almost always premature optimization, and ruby is more than fast enough for everything I've ever asked of it (including the binding glue between our redis DNS record storage and PowerDNS, where the entire stack serves half a billion queries a month across 14 tiny VPSes without even a blip on htop). I probably could have just used ruby instead of PowerDNS but it's generally not great to roll-your-own on public facing encryption, HTTP, DNS, etc. It wasn't really a performance consideration for me.
The recent irony of the web is anyone that implemented a web app with "slow" ruby and backend rendering now has the fastest page loads compared to bloated front-end web apps backed by actually slow eventually consistent databases that take seconds to load even the tiniest bits of information. I see the spinner GIF far too often while doing menial things on the "modern" web.
I always do this when I see large-sounding query counts; a month has a lot of seconds in it, and it’s easier to visualize only one at a time: I can imagine hooking a speaker up to the server and getting a 14Hz buzz, or do a quick mental arithmetic and conclude that we have ~70ms to serve each request. (Though peak RPS is usually more relevant when calculating perf numbers; traffic tends to be lumpy so we need overhead to spare at all other times which makes the average much less impressive-sounding.)
Indeed it's just the most performance-critical part of the stack that happens to involve ruby because I needed a shim between redis and powerdns. I write it as a quick hack years ago and have never had to make any changes to it.
I think that shim still uses ruby 2.6, I may try to upgrade it to 3.3 with yjit and see what the latency drop is, which is probably a more interesting number anyways, but again only really matters for a single caching request that only happens once in a while.
The real reason I continue to use ruby is because it's a quick way to get things done on business logic heavy web apps, but I continue to be impressed how much I can get away with using it for things it's really not known for being good at. I run into people often that refuse to use it for absolutely anything because there's a perception that it's "too slow", but when pressed I learn that they're not really working on anything that requires high performance provided by more esoteric languages with stricter memory management that is very likely nerfing their productivity unnecessarily. My goal here was to push back on that perception a bit, not to make the dns shim sound impressive.
The reverse is good also. 0.00005 vs 0.005 cents/request seems very close as a human. But considering that times the seconds in a day or month results in very different values.
I also like to double check these kind of numbers and basically agree with your take. Although, I like to use a 28 day month and an 8-10 hour day rather than assuming smooth traffic over 24 hours. Even with all that, 1/2 a billion is well under 50 req/sec which is not a big deal for the rendering servers. All that traffic coming together on a database server might be a bottleneck though.
Yea 14 qps isn’t high performance. I think the parent comment is right that most people don’t work on high performance software and so Ruby will work fine.
But something to keep in mind. I’ve seen servers before that could serve in the 100,000 QPS range on a single instance! They weren’t written in Ruby.
Ruby the language may be fast but the whole ecosystem is painfully slow. Try writing a server that serves 1mb of json per request out of some db query and some calls to other services. I get 100 requests per second in Rails. Same service rewritten in go serves 100k requests/s.
Why Rails, instead of a lighter-weight framework, if performance is such a priority? Obviously that wouldn't get you to [anywhere near] the performance of compiled Go code, but Rails has a lot of overhead.
What database is on the backend, and is that db serving cached content? What happens if you cache it with e.g. redis to avoid the heavyweight rails ORM stuff?
Do you have granular benchmarks for the db query, requests to other services, and the web processing itself (using artificially pre-cached responses from db and those other services)?
Why not something like Sinatra so it’s easy to prototype and move on from there if it’s still not good enough? What you’re describing isn’t that complex and the base Ruby language is so much better than Go.
You’re likely in one of two situations as a businesss:
* You’re a struggling startup. Development velocity trumps literally everything. Your server costs are trivial, just turn them up.
* You’re a successful business (maybe in part because you moved fast with Ruby), you can pay down the debt on that absurdly large response. Chunk it, paginate it, remove unnecessary attributes.
Sorry I was oversimplifying. Most of the data for the response comes from the db with some API calls for authorization and some auxiliary data. Benchmark was actually hitting the DB. Quite a bit of the 1mb response size is redundant (json-api format).
But you could return the 1000 objects (or less? 1000 records sounds like a lot for any UI to show at once) of 1kb size and allow the clients to request specific pages with a request parameter. There may be applications where you need to ship the full 1M records I guess, but that seems like very much an edge case as far as web apps go.
True, you would not return 1000 objects at once to the frontend.
I first thought it's just a backend use-case, where processing 1000 records in a paginated result is common, but the parent mentions "rails", so it sounds like a frontend use-case.
1,000 records is absolutely not a lot on modern computers or connections. On a business LAN, this request should take well under a second full latency.
On an average mobile connection, it’s maybe a second or so.
You’re right. It’s not a lot for a machine. The point isn’t the speed capability. It’s why? What UI has 1,000 rows in, e.g., a table all at once (much less 1M)?
Many plots contain thousands of data points. Eg: 10 x 100 heatmap which supports sorting by various metadata. This is a common visualization for biological data where your data matrix is samples x proteins, so potentially much larger than 1000 data points.
“Why would I pointlessly accept this clear case of massive technical debt for literally no reason what-so-ever?”
Rails does not present any sort of promise that go does not also present, so just saying “yeah, I’ll handcuff my app like this cause I feel like using Ruby” is, frankly, absurd.
When you ask the right questions, you never land on Ruby, and that’s why Ruby continues to decline.
Ruby is concise compared to Go though. I like Go and but when I use it I have to accept that I'll write (and debug) at twice as much code as I would do in Ruby.
If you're mostly just loading data into a large fast cache, lines of code may be a more critical dimension than execution speed.
That's how well designed Rails projects work and you get most of what you need straight out of the box.
Edit: clicked the link; it's 10%. I don't think that's going to make any difference to the perception of Ruby's slowness given that it's on the order of 50-200x slower than "fast" languages like Rust, Java, Go and C++.
Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime. In any case, it's still early to determine the impact on performance from upgrading to Ruby 3.3. I guess we'll be able to tell more in the coming months.
How much of the time in a given request is even spent in Ruby code? The majority of web apps that were slow and I got a chance to analyze were spending much of the time in DB queries and slowness was usually due to unoptimized DB queries. Even endpoints that were fast, still spent a large percentage of their time not in Ruby but in DB and service requests
That is true, yes, but still comparing e.g. Rust vs. Ruby I'd think Rust spends anywhere from 10ns to 100ns (outside of waiting on DB) and Ruby no less than 10 ms. Still pretty significant and can add up during times of big load.
Also I remember Rails' ActiveRecord having some pretty egregious performance footprint (we're talking 10ms to 100ms on top of DB waiting) but I hear that was fixed a while ago.
My point was that if we look at Rails performance going up 10%, what does that mean for time spent in Ruby. I'd believe anything from a 15% to a 80% reduction of time spent in Ruby code
I wasn't trying to say that Ruby indeed is 80% faster, but that it's pretty much impossible to drive actual Ruby speed up from Rails numbers, since we don't know nearly enough about the Rails app
I suspect there's not just one cause of slowness here. Pure language benchmarks also tend to rank Ruby very low. So I'd wager that a fast Ruby framework would still lose to a fast Go framework.
Absolutely, I should maybe clarify that I did not mean to say that we can fully rule out the language itself as a cause of the poor performance, Ruby always perform worse than Go in this example for obvious reasons.
But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion! And that is what I was trying to point out.
> But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion!
I did not claim that in general sense, I said it with the context that even if Ruby got accelerated a lot then that's still kind of inconsequential because most Ruby usage is Rails.
Apples to oranges again. A more relevant comparison would be Ruby to Python and in recent years Ruby has edged ahead in performance if you factor-out Python's C-based libraries such as Numpy.
If we're comparing "programming languages that can be used to make websites" then it's totally apples to apples. Ruby and Go (and Rust, Java, etc) are all valid options and so I think it's smart to compare them before starting a web project.
I haven’t used Python in years but from what I’ve understood by reading other comments, factoring out C-based libraries would rule out a large portion of what makes Python so popular. Especially on the scientific side.
Can we stop with these useless comparisons? 10x-20x, 100x, 200x out of context means absolutely nothing.
All these micro-benchmarks shootouts means nothing either. Is anyone running a mandelbrot or pi-digits SaaS company? I'd think not.
Similarly saying Rails is slow out of context, means nothing, Rails is "slower" than Ruby micro-frameworks X because it does useful things the other doesn't like CSRF protection etc. If you don't need these features, turn them off and Rails will be about as fast as these frameworks.
If anything annoys me more than clueless people shitting on Ruby for bad reasons it's Rubyists spreading FUD about Rails.
Perhaps it's misleading to throw around specific numbers like 100x, but Ruby is certainly orders of magnitude slower than languages like Go or Java. Both of which are not exactly known for their speed (compared to C++ or Julia, for example).
"speed" thrown without context is meaningless. It's one property of a tool among many others you generally have to trade for.
Some use cases with small margins call for the utmost efficiency to be viable business. Some use cases just need decent efficiency and are happy to trade some efficiency for some other properties.
Many successful people and companies are happy with Ruby, can we just give them a break? Or is there somehow some moral duty to use the "fastest" language available regardless of whether it makes any kind of business sense that nobody told me about?
On the other hand, why is it wrong to say Ruby or Rails is slow? Especially in the context of Java or Go? What is wrong with accepting a simple ground truth that is compiled language is and will always be faster than an interrupted language, even with JIT.
For Rails I often compare to it another CRUD app, StackExchange [1] using ASP.net And the easiest real world comparison with Rails App would be Cookpad. Are we not seeing at least 10x difference if not more.
Is Rails fast enough? That depends on the context. Everyone's business model is different. It is almost definitely fast enough for most SaaS cases.
> What is wrong with accepting a simple ground truth
Where am I denying that? Saying that one of the most dynamic language is slower than Java or Go it's such a truism it's pointless.
What annoys me is the figures quoted. I can craft you benchmarks were Ruby is barely any slower than these two, or benchmark where it's 1000x slower. So which is the correct number to quote?
> For Rails I often compare to it another CRUD app, StackExchange [1] using ASP.net
This makes zero sense. You said:
> If you compare pure Ruby without Rails to fast language like Rust, Go and Java. It is probably closer to 10-20x.
> The 100x to 200x mainly comes from Rails.
So somehow you are blaming Rails for making Ruby 10 times slower whatever that means. That is a stupid statement that you took out of your hats and that doesn't reflect any reality. Please stop doing that, it's really unnerving for the people who maintain these projects.
Building a web backend with C++ is a very dangerous and complex ordeal, you're extremely likely to expose memory based vulnerabilities to the entire world.
Google, Facebook, Amazon and Twitter beg to differ (not completely C++, but for services where it makes sense). Also nginx, passenger and other parts of your Ruby app.
Shrug, you have no idea what you are talking about [1]. Also nginx and passenger are webservers and claiming they are not part of your web app is a pretty wild claim when they literally send http responses to browsers (unlike memcached).
I think you're the one who got confused with the context here.
We're talking about web-app, not microservices.
We're talking about CRUD with DB migration, sessions, caching, etc.
I recalled Google's dl.google.com was implemented in C++ and Brad F rewrote it with Golang. We're not talking about microservice that serves file here. We're talking about the main web application that serves wikipedia, youtube original version (they might had revamped it sometime post acquisition with web gateway and bajillion microservices), Google Search (was Java servlet), Facebook original web-app (was PHP, became HVVM/H4CK.
So yes, I _know_ what I'm talking about in terms of the context of a web-application here. Do you?
RoR and whatever C++ based web backend there is count as a valid comparison in my book. But comparing the languages itself is maybe a bit off.
On a side note, you can actually compare their performance here if you’re really curious. But take it with a grain of salt since these are synthetic benchmarks.
Web backends in Rust and C++? Not saying web frameworks in these languages don't exist but to claim they're anything other than curiosities is misleading. In any case, good luck with the fraction of a millisecond such languages gain you while waiting on database i/o. There are use cases for switching to a compiled language like Rust or C++. Web back-ends isn't one of them.
Nah. One rust based server can power the same number of connections as 10-100 ruby based servers.
This is not just “pretend database IO” problem. This is actual cost that no business should accept on the basis of “but but but database IO (that I’ve never actually measured, but it’s an easy cop out because I read it on medium once).
But you factored-out developer productivity. What you gain in reduced server costs is lost many times over in developer productivity. Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++. They did the math and the business case for Rails was more compelling.
Let's not act like everyone who tries Rust gives up. OK? Sure it's definitely more difficult but people are learning and practicing and the pool is slowly expanding (me included, though I am not at production-grade experience yet).
> What you gain in reduced server costs is lost many times over in developer productivity.
Are you exaggerating for dramatic effect? I'd say depending on your people's seniority the productivity loss is anywhere from -50% to -500%, which is hardly "many times over".
You absolutely do iterate slower with Rust writing web backends -- no two ways about it. But you also (a) exaggerate the multiplier and (b) underestimate the long-tail of gained productivity that a language like Rust brings to the table (strong static typing et. al.)
And even if we take into account your comparison between server costs and programmer productivity -- there are areas where correctness and speed are more important than Joe and Susan being able to crank out 17 CRUD endpoints this week. I feel that this nuance is often ignored.
> Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++.
I have worked with Rails for 6.5 years and they knew no such thing. They treated server costs exactly like they treated programmers -- a necessary evil, a cost center that (currently) cannot be optimized away.
I am consistently blown away by the protected and downright pampering environments that some HN people have lived in. It's pretty brutal out there though, and somebody has to point that out to you every now and then, lest you forget it (which it seems that you did).
> They did the math and the business case for Rails was more compelling.
They did no math, except one: how easy it is to hire 5 new devs in the next 1-2 months. No other analysis was involved whatsoever. Again, I've looked from within, a good number of times.
---
I am all for an informed debate but that seems to be difficult with you as you resort to exaggerations and dramatic language.
For the record, I don't do my main work neither with Ruby on Rails nor with Rust (though I know both, or should I say I knew RoR because I haven't used it in a while now). I got no horse in the race, I am simply looking for an objective discussion based on merits that can hopefully ignore network effects and popularity. Technologies absolutely can and have won by utilizing network effects and popularity (see: Python) but that does not say much about their objective merits.
>I have worked with Rails for 6.5 years and they knew no such thing. They treated server costs exactly like they treated programmers -- a necessary evil, a cost center that (currently) cannot be optimized away.
Luckily we now have company that is large enough with incentive to optimise it.
Rails is no more productive than go, and a developer taking 20 extra minutes (frankly, not likely, even if we’re talking rust) to write go rather than Ruby is not going to cost more than the $1000 a month the extra Ruby servers cost you just to run.
It sounds like you haven't worked with many startups which is where Rails has been the goto option for a very long time. Rails is a framework. Go is a programming language. Show me a Go command line which sets up a fully-baked MVC app complete with data model, migrations, CORS, caching, asset pipeline, mailer, mailbox, chat(Action Cable), job queue and a Hotwire equivalent. While you're baking all of that yourself I'm launching our MVP. There's Buffalo but you compared Go with Rails so I assume you meant rolling your own using just the Go standard library.
I think that’s as far as the grand scheme of a project goes, coding productivity is a myth.
Can a python or ruby dev bang out Advent of Code faster than I can in zig or rust? Sure. Is advent of code representative of a multi-year long business system where coding is 15% of the time cost at the high end? Nah.
When you look at the actual bills and where the actual time goes, spending time on optimizing the code pace of a MVP is simply not valuable. You’re saving a small percent of a small percent of time at the beginning to accept using languages that are not know for their steady state support ability.
Yep, agreed on all accounts. People simply love their languages and will point out any area they "win" at, even if it's inconsequential and not at all important. And that's happening a lot, including TechEmpower benchmarks, speed-to-first-MVP, and many others.
I skip Ruby hype but I know RoR and I use Golang professionally to build microservices serving Fortune 10,50,100,500, whatever and I wouldn't use Go to build a web-application.
Golang for microservice that relies on other microservices are great (i.e. my Golang service doesn't handle authN/authZ, but another service does), Golang for monolithic web-app that has to handle db migration (yeah I know something exist), implement multiple crud objects (remember, Golang microservices typically has smaller context and challenges than a medium size web-app) is pain in the ass!
PS: cut my teeth in Java servlet/jsp, moved on to Spring Framework+GWT, skipped RoR went straight to JS and ended up in Golang for the last 5+ years. I'm not Rails worshipers but I'd probably pick Java Spring ecosystem over Golang for monolithic web-app.
Yes and no, some languages like Python and Ruby do introduce overhead even in conditions where waiting for the DB is 80-90% of the time spent on a web request -- that much is true. But the database I/O problem is definitely not pretend. It's very real.
They all have their niches. Rust is difficult but rewards you for your persistence.
I do appreciate Rust a lot but nowadays find myself reaching for Golang more often. I simply don't have the extra time and energy to learn the final more advanced Rust pieces in my own leisure time so I'll learn it whenever I can but yeah, in the meantime: Golang to the rescue.
> I simply don't have the extra time and energy to learn
Nobody does these days. Language is just a tiny piece of the whole Cloud ecosystem aside from k8s, docker, different storages (elastic, rdbms, mongo), different monitoring/metrics solution, etc.
I work for a company that is testing Rust and the complain was that the tooling wasn't there compare to Golang.
Well I don't know if this is a shallow generalization or just observation but in case it's the latter: I am a senior dev with too much stuff in my hands already, and my personal life's list of pleasures comprises of 2 items: sex and sleep. I figured that at 40+ that is VERY NOT OKAY and I am working to change it.
So yes, I no longer will sacrifice personal time to hone my programming weapons.
Or as we say here in the Balkans: "The quality of the music depends on the tip to the musicians".
Found nothing that would impress me. Ruby syntax? Who cares? Compiled and with better performance? Well, what's wrong with Golang and Rust? They do fantastically well.
I don't see what niche is Crystal trying to cater to. Other languages have better compilers and a bigger, more developed ecosystem.
I am not interested in being put in a corner where I have to defend web backend creation that I don't even practice. I only said it's being done by people. Feel free to reject it or degrade it as being "a curiosity", from where I am standing reality disagrees with you though.
You're right about that, and that's something I believe the Ruby team is struggling with, to show where Ruby is useful outside the Web field. Everyones picture of Ruby is web related thanks to Rails, there is no question about it.
And I find that bit sad because Ruby is also good at other things like building cli apps (have a look at Metasploit for example) & gluing different moving parts together, creating your own DSL thanks to its flexible language structure.
I wouldn't say Ruby is better than any other languge though, all general purpose language could probably achieve the same result, it's just a matter of taste.
We're venturing in the not exhaustively objectively proven benefits and virtues of strong static typing but nowadays I reach for Golang and not for shell scripts (or Ruby, or Python).
Why?
Just today I again had to do Homebrew cleanups so one recipe can install. Likely my fault, 100% sure about it, but I just need non-confusing tools in my life.
...Or I kept grooming my homemade cross-machine provisioning scripts (i.e. install baseline tools like git and a few others, and then bring my up entire environment along) and in the end it still couldn't source a script that is right there in the file system and even after I made sure it got sourced, it still couldn't find the stuff inside it... while all other 20+ such similar `source stuff.zsh` work just fine.
At one point you do get fed up. (And yes I know this is not strictly related to strong static typing; it's just one example of a thing that will reduce bug surface.)
Ruby is easy to write. And that's the problem. People tried to do too much with it. And it's early glory of including a gem that monkey-patches the core library APIs did not do it any favors either.
Nowadays I don't appreciate unbridled freedom as much. I appreciate and even enjoy constructive limitations. Truth is we can be very much like kids and should be protected from harming each other.
But yeah, that's venturing into philosophy which was not the topic.
TL;DR: Ruby is fine but is fairly limited for my taste. My needs are far bigger and they also include maximum 50ms of startup time.
>But yeah, that's venturing into philosophy which was not the topic.
I guess you touch on something why many of the discussions on HN and Internet fail to get the point across, when you could have someone in their 10s or 20s who couldn't understand it. Just like how we were told when we were young.
>Nowadays I don't appreciate unbridled freedom as much. I appreciate and even enjoy constructive limitations. Truth is we can be very much like kids and should be protected from harming each other.
It is unfortunate this line of fine balance thinking is not well understood by many, young or old.
It may be worth comparing this new JIT to fast implementations of dynamic languages, like LuaJIT or SBCL for Common Lisp (SBCL is an AOT compiler and not a JIT though).
I'm so glad that you said this and weren't downvoted into the ground. Honestly, Ruby needs to die. It performs like a go cart in a Formula 1 race. I'm actually just exhausted watching smart people tell me this is a language and toolchain worth dedicating brain cells to.
What a bizarre take. Ruby is primarily used in web applications, where round-trip http requests, database queries, and other 10s-of-ms things are commonplace. Ruby is very rarely the bottleneck in these applications. Choosing to make your job significantly more challenging in order to maximize the performance of a small portion of the total response time of a web application is not, in my estimation, a smart decision.
There's always this rift between the "language is slow" crowd and the "but it's not the bottleneck" crowd. I think this comes from the types of applications you work on and their scale.
I work at what a company that's not particularly large. Our original API is a Django monolith that serves about 1000req/s.
While you could argue Python isn't the bottleneck, Django often is. I hear the same feedback from colleagues that work in Rails. Not only do we run into issues with latency per request but we have to run a significant number of Kubernetes pods to serve this workload. With c#, golang, java or a similar language we would only require a handful of pods and drastically cut our compute costs.
Even for web workloads, these slow interpreted languages and their developer experience optimized frameworks absolutely do become a bottleneck and claiming they don't (or that you need to be at Google/Facebook scale before they do) is false.
Everything is a tradeoff but the way I think of it: speed is a feature.
Further, with a lot of the batteries-included web frameworks you end up with a ton of suboptimal database queries (e.g. unintentional query-in-loop). Some would argue that you can just profile your code and optimize the hot spots, but I would tend to think it still slows you down quite a bit overall.
One of the biggest breaking changes that EF Core did was to explicitly disallow such generated queries that required application-side evaluation and could not get compiled to pure SQL (you can get other behavior back with a toggle but it is discouraged).
I strongly believe it is wrong to do otherwise and is a source of numerous footguns unless you invest in tracking them down.
I will admit I'm behind the state of the art with EF, but I switched to dapper in the early days of dotnet core and never looked back. It gets out of my way so I can properly utilize postgres' advanced features like jsonb while cutting out a lot of the boilerplate associated with hand-rolled queries.
Dapper is great. I'm very happy that there now exists an AOT-supporting flavour of it too: https://aot.dapperlib.dev/
As for EF Core - it very good as of today (has it ever been bad?). You can transparently compose your queries with `context.FromSql(...).SingleAsync()` which will use string interpolation API to consume your plain $"SELECT * FROM {myTable} ..." and make it injection-safe and transform passed arguments as appropriate. It's quite handy.
You're literally the exact person I'm talking about. No serious application developer who's interested in speed is working in Ruby. This isn't my opinion. I don't care personally, it's just a fact if you care about reality. When Netflix announces that they use Ruby because it performs faster than Node.js, I'll change my opinion, because my opinion is based on facts and not feelings. I didn't make Ruby, so whether it does well or fails isn't personally important to me. If Ruby was the fastest interpreter, I'd be pro-Ruby but it absolutely isn't and pretending it is is depressing and shows you are making political or selfish decisions, not practical ones.
Most of your comment is about what you think I think, and not a lot about metrics, data or examples where Ruby performs beyond my interpretation. I think that says a lot right there.
Nobody is pretending Ruby is the fastest interpreter. Who are you arguing against? Rubyists generally consider Ruby “fast enough”. Which it is, for many applications.
For every engineer insisting Ruby is fast enough in a situation where it is not, there are 1000s in environments where Ruby absolutely is more than sufficient, insisting it’s too slow.
It doesn't answer the question of why you would choose Ruby. Honestly, you all sound like you got a Sega Genesis for Christmas, while everyone else got a SNES. You can tell other kids on the playground that Genesis has better graphics, but the spec sheets don't lie.
You're trying to make it seem like it's a wash, because "scripted" but it's not. Node.js outperforms Ruby in every department. And it's based on one of the slowest scripting languages of all time. Ruby is a dead language in many countries.
In Canada, you would have to travel the country to find a Ruby job. And if you don't think in American-centric terms, that is meaningful.
Fine analogy. Plenty of people liked the Sega Genesis more than the SNES. (I think a more apt analogy is more contemporary consoles, where the lowly-spec’d Nintendo competes just fine against the competition’s higher performance units. People like Nintendo for reasons other than the spec sheet.)
I enjoy writing Ruby a heck of a lot more than I do writing JavaScript. I like the object model. I like Ruby’s standard library. I like the Ruby community. I like the tooling: irb is fantastic. Bundler is still one of the best package managers around—makes npm and yarn look silly by comparison.
The spec sheet just does not matter for virtually any of my work. Switching to a less enjoyable, more performant, language might make a 60ms response time average become 55ms. Who cares? That performance difference was even bigger 15 years ago, and it didn’t matter then. It matters less today.
GitHub, Shopify, Airbnb, Netflix (yes! Even Netflix!), Soundcloud, Kickstarter, etc. etc. all use Ruby today. It is a fantastic development environment when you’re more concerned with doing your job, and less concerned with performance pissing contests.
I'm a Nintendo die hard fan boy, I don't care about speed. I learned how to "code" in ColdFusion. I am all for the underdog POV.
We're talking about performance because of the context, which is – there aren't the jobs to support the language's continued growth and dedication. We're talking about speed because there needs to be a defining reason to continue using a language and develop in an ecosystem that isn't moving at the growth of other communities.
If Nintendo Switch had 4 games, and they all looked like dog piss - asking why would I bother wasting time with Switch is a valid opinion.
There's also this insect-minded logic of only being a "front end developer" or "back end developer", and that mindset is furthered by languages that don't bother speaking the language of the web. If I learn javascript, I can be both - pretty much on day 1. If I learn Ruby and Javascript, great. How easy is that to do for a junior developer just getting out of school? Not widely.
Ruby and Python are the only two ecosystems that seem to prioritize developer happiness. They're a pleasure to work with. So they're not going to die anytime soon.
Python might be popular but developer happiness isn't a concept I'd associate with the language. There's no joy in being limited to single statements in lambdas, for example.
One area where Ruby could help improve developer experience is by providing a better debugging experience. I feel incredibly spoiled with Chrome Dev Tools. Meanwhile the last time I tried debugging heavy metaprogramming Ruby code it was a pain to figure out what was happening.
We ban most meta programming in our own code. While the meta programming solutions are fun and clever they are often more code than a functional version and hard to maintain.
We do allow the occasional use of “send” but try to avoid it. Dynamic method definitions are strictly banned.
heavy metaprogramming in any language is going to be a pain to debug so i'm not sure what you're expecting but there are tools to help. you can also call source_location on some method to figure out where things exist.
I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years. I never thought Ruby would have a shipping and production ready JIT before Python. And Prism, Lrama, IRB. A lot of these were discussed in previous HN submissions.
But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async. Especially in the context of Rails. I am wondering if any one are using these features in productions and if you could share any thoughts on the subject.
> I never thought Ruby would have a shipping and production ready JIT before Python.
This is entirely predictable - Ruby does not have a big scientific computing community which happened to depend on every implementation detail of the hosting interpreter.
The problem is that Numpy is not in fact anything close to a thin wrapper around BLAS/LAPACK like people seem to think it is.
First of all, it contains a ton of custom C code, which to some extent could be extracted to a separate library in theory, but isn't. Second, a lot of that custom code interacts deeply with the Python C API, which historically was very open-ended. Even getting it to work on another implementation of Python was a challenge that took a long time to reach baseline usability.
You could forego Numpy and call out to a library like Eigen, but even then you have a huge amount of work ahead to achieve anything resembling feature parity.
There's a talk from a couple of years ago by one of the YJIT developers that discusses this in some detail and it's more interesting/complicated than that. The whole thing is worth checking out but the specific section starts here
> Really? What’s so significant with this release?
I think the Prism parser update is a standout highlight for me. This is the start of many new static analysis tools for ruby.
It's also significant that RBS type information is starting to be used in IRB autocompletion. Previously RBS has been an interesting experiment but hasn't had much practical use compared to Sorbet.
Ruby seems to now have good answers to non-blocking IO (async fibers) and tooling questions (ruby-lsp). We're starting to see YJIT performance improvements starting to compound with more to come too.
That all seems significant to me. Thanks to everyone involved.
The one thing I genuinely don't understand is why there is no single task queue that works across ruby and python. I get that at some point people just started making http based microservices to pass information around, but at the end of the day a simple task queue that has a unified storage format across both is a better way to connect ruby(rails) based with the ml stack. There are probably thousands of custom rabbitmq or redis based private company solutions out there.
That's awesome. Any idea why he doesn't just supersede Sidekiq with that? I spent quite some time hacking my own solution.
I just looked at the source, I guess Mike has been mostly working on both projects on his own for the last 4 years, so Faktory has a lot of features that require the enterprise license.
I wonder if he could change the situation it he markets a bit more to the python and more specifically Django community.
It is pretty cool. I’ve been using it for 3-4 years as a queue between Ruby and Node for scraping tasks. Ruby queues the work, a node worker does the downloading, and a Ruby process parses and loads data. It works incredibly well in my use case and has saved me from having to shift everything to one language or the other. It’s been very reliable.
Because people running sidekiq with their Ruby app on production don’t care about cross-language queue. If you pay for Pro or Enterprise you don’t want any major changes that are potentially breaking.
Sounds like Mike found a good feature that would encourage companies to purchase a license. I have a tremendous admiration for the business he's built.
My customers are using Celery for Python and Sidekiq for Ruby. Those are parts of Django and Rails web apps. Those customers don't mix languages so they don't need workers able to run code in multiple languages. One of them is also using SQS though so we could receive a JSON in a server written in any language, do some processing and return the result. However the database of that app has been "destroyed by design" by using Django's ORM inheritance (my suggestion: never use it) so nothing can interact effectively with it except Python code using the same models.
By the way, celery was born as a protocol spec to support multiple languages but never moved past Python. I can't google a quote for that, I remember I saw it years ago in the documentation somewhere.
I can see that it was born that way, but nowadays most job queues say, don't touch the wire protocol, it's not intended to be used directly.
I still think Rails has the best ORM design I've ever seen, iterated with practical applications. Django's ORM and migrations are, for lack of a better word, odd.
I'm a bit surprised that people here argue that no one using Rails would ever want to interface with other languages. Most big companies do. How can you not interface with python these days.
Looks to me like celery might just be the only job queue left like that. Might be worth writing a current ruby en-queuing library for it. Retracting my previous statement about ActiveJob since it would probably be too much effort to execute anything bidirectionally.
I think the poster is specifically referring to using inheritance in Django ORM, where if you had e.g. a model Book and then a model Novel that inherits from it. In python these are modeled as a class inheritance hierarchy, and Django (at least, by default) creates a database table per class in the hierarchy. If you have 3-4 levels of inheritance, that's 3-4 extra joins per query.
This. That customer of mine started a project a few years before hiring me. They used inheritance and each model is scattered around a number of tables. No external tool can sensibly access that database, except that very Django app and its manage.py commands. Add a similarly enthusiastic use of apps under the same main directory and the database is a mess of long named tables with a tangle of relationships between them.
We started another project later on and we planned the database first. We wrote one model per table, no inheritance, only a few cleanly delimited apps. We still use makemigrations and migrate but if we want we can write a piece of software on any language to access that database.
We use that, a base model and some mixins, but we use Meta.abstract=True (or similar, not at my desk) on the parents and have not noticed any issues, though have not looked for them either! Should I be concerned?
Looks good. There's a new IRB, the interactive Ruby interpreter, with better autocompletion and debugging. Most of the Ruby 3.3 changes will lead to improved developer tooling. The language API is largely unchanged and consistent with previous releases. I wrote a guide [1] for the update to Ruby 3.3, with notes for each of the various version managers.
> Name resolution such as `Socket.getaddrinfo` can now be interrupted. Whenever it needs name resolution, it creates a worker pthread, and executes `getaddrinfo(3)` in it.
Do other language runtimes do similar things? Creating a thread sounds too heavy, though it might not matter in practice. As per their own benchmark, the overhead is minimal but still not zero.
10000.times {
Addrinfo.getaddrinfo("www.ruby-
lang.org", 80) }
# Before patch: 2.3 sec.
# After ptach: 3.0 sec.
100.times {
URI.open("https://www.ruby-lang.org").read }
# Before patch: 3.36 sec.
# After ptach: 3.40 sec.
Is this because all of the I/O operations in the standard library have to support async/fibers?
My impression is that everything was migrated to be asynchronous by default, unlike in Python where all of these operations were reimplemented in the async "color". Is that true?
The getaddrinfo interface does not expose the fd so you can monitor for readiness. Several languages have the same problem with it, some with similar solutions (go outsources getaddrinfo calls to a thread pool)
Ruby is basically a less popular but more elegant Python. It’s a solid general purpose language, but especially good at shell scripting, data munging, etc.
If you’re fluent in Node and Python it should be quite easy to learn. The downside is it’s not going to do anything fundamentally new for you coming from those languages. The upside is mostly aesthetic, Ruby offers and encourages really beautiful ways of expressing code, and it’s neat to experience that.
Having tried to use Ruby for text processing specifically, I'm not sure I agree it beats Python at that particular task. Maybe I'm just used to the Python way of doing things, but I found it difficult to work with the lack of first-class functions and iterators/generators, as well as the general iteration protocol.
> but I found it difficult to work with the lack of first-class functions and iterators/generators, as well as the general iteration protocol.
Ruby has iterators/generators. It doesn't have first-class functions because it doesn't have functions at all, but blocks/procs serve the same purposes.
No, blocks are not first class (procs are, and procs are the closest thing Ruby has to functions, and a method definition can bind convert the block passed to the function to a proc if a first-class value is needed.)
Blocks are a syntactically special single argument to a method that can either be yielded to (a Ruby construct similar to a function call but which only applies to the block passed to the current method) or converted to a proc (but the latter only as part of the method definition, since they aren't first class and thus cannot be manipulated or referred to directly.)
No, in Ruby lambdas are lambdas (and are a special type of proc); the longhand way to create a lambda is to call Kernel#lambda and pass it a block (though modern Ruby has a special shorthand syntax for lambdas, as well.)
Blocks are sort of like anonymous function literals that are not first class, one (but no more than one) of which may be attached to a function call.
I think you may just be used to Python still relying on functions for string processing, where Ruby has methods on the String class for manipulating strings.
It seems to me that Python still has these holdovers from when it was not fully object-oriented, where a lot of string and data structure manipulation is done with language-level functions rather than methods on the objects, which can be quite confusing.
As I said, claiming that ruby doesn't have first-class functions isn't "meaningfully true". Ruby does not have functions, only methods. But that's mostly irrelevant.
> The identifier of a regular "function" in Ruby (which is really a method) cannot be used as a value or passed. It must first be retrieved into a Method or Proc object to be used as first-class data. The syntax for calling such a function object differs from calling regular methods.
> Ruby doesn’t have first-class functions, but it does have closures in the form of blocks, procs and lambdas. Blocks are used for passing blocks of code to methods, and procs and lambda’s allow storing blocks of code in variables.
> but especially good at shell scripting, data munging
Add to this also Shopify, Github, Gitlab, Basecamp and some others and you will see that Ruby can be use for more than shell scripting and data munging. Yes they are Rails but Rails is written in Ruby so they are Ruby.
I think Ruby is much better at shell script like tasks and interactive / exploratory programming for system tasks compared to Python or Node. Use it as “better bash” or
“better Perl” and it’s worth it. I primarily work in a Typescript codebase, but regularly reach for it as a tool to wrangle log data, semi-structured text, or do regex rewrites of a bunch of files.
Ruby is also very fun, probably the most fun language I’ve used regularly. That makes it its own reward.
This is very intriguing, could you please elaborate? I have been looking for a better bash for scripting stuff without all the bash and sh-isms and gotchas.
Some of the most enlightening books I’ve read when I was first learning Ruby were Text Processing in Ruby, and Building Awesome Command Line Apps in Ruby 2. They each reveal certain features and perspectives that work towards this end, such as text parsing moves, Ruby flags to help you build shell 1-liners you can pipe against, and features with stdio beyond just printing to stdout.
Then add in something like Pry or Irb, where you are able to build castles in your sandbox.
Most of my data exploration happens in Pry.
A final book I’ll toss out is Data Science at the Command Line, in particular the first 40 or so pages. They highlight the amount of tooling that exists that’s just python shell scripts posing as bins. (Ruby of course has every bit of the same potential.) I had always been aware of this, but I found the way it was presented to be very inspirational, and largely transformed how I work with data.
A good practical example I use regularly is: I have a project set up that keeps connection strings for ten or so SQL Server DBs that I regularly interact with. I have constants defined to expedite connections. The [Sequel library](https://sequel.jeremyevans.net/) is absolutely delightful to use. I have a `bin/console` file that sets up a pry session hooking up the default environment and tools I like to work with. Now it’s very easy to find tables with certain names, schemas, containing certain data, certain sprocs, mass update definitions across our entire system.
```
# Something failed, and not everything loaded as you expected
# explore explore explore…
Just like with work in the shell, you have a really easy time iteratively exploring the problem and building up your answer. The ability to serialize your data you’ve found, and keep your favorite tools in your pocket feels extremely productive. And of course, all of this can be written in ruby 1-liner shell scripts, or more complex shell scripts to pipe in and out of other tools if desired.
The most interesting part IMO is how it's so similar to Python along many categories, but also so different.
Biggest example is how Ruby just loves Blocks. They're all over the place in the std lib, tons of syntax sugar for them, and countless DSLs built around them. All the standard functional stuff is there in the std lib and has been from very early on, so doing functional-style stuff is really smooth and reads well. In Python, you can technically do most of the same stuff, but it all seems a lot more awkward to write and to read (though maybe just my opinion from doing Ruby first). Python has lambdas, but it doesn't seem to like them much for more than trivial things. But instead functions are first-class everywhere.
I worked with ruby, ruby in rails(RoR) more specifically, a bit more than ten years ago(2011-2013). At that time it was already the afterglow of RoR, the framework for web development that had come to life in 2005 and raged between 2007 and 2009. The latest-technology-addicted crowd was jumping into the boat of node.js, that was crazy fast compared to anything done RoR, and API oriented development with angularjs. In 2013 RoR already showed its age as the standard ways of doing things with it was still the monolithic way and the framework was not transitioning very well to the new paradigm of frontend/backend development.
This introduction about a framework built with ruby and not ruby itself was necessary because even today, I would guess that 95% of all development with ruby is RoR applications. It's my understanding that ruby rose to prominence mostly because of ruby on rails, now that RoR is in a downward trend I think ruby will follow the same trend until it's reduced to a small community of enthusiasts in the same way that happened to perl.
As for the language itself I can't think of a single reason to opt for ruby over python or typescript. Ruby doesn't do anything better both in terms of language or platform than its already better established competitors.
Even Python's choice of naming and syntax to use these basic functions just hasn't been thought through as much as Ruby's implementation. There's a reason it's called the language of Developer happiness.
Ruby's community I've found is more focused on best engineering practices (like testing) than others, which is perhaps why RSpec and MiniTest are fantastic frameworks. The likes of PyTest doesn't even compare to what those two offer.
Plenty of reason above to use Ruby, and we haven't even got to Rails yet.
Kitchen sink isn't the best design imho. I see many of the additions are regexp functions. While I do use them it's rare because they quickly become unreadable. Agree with the python design to decouple and discourage them by requiring an import.
With the recent additions of the prefix/suffix methods I have no desire for any more.
Ruby and Ruby on Rails are not in a downward trend. There were maybe some year where the interest was decreased but in the last 2 years a lot of things happened: Ruby has a lot new features, Rails 7 is out and comes with a new approach to web apps like for example Horwire with the just released Turbo 8.
And there is a lot more: new conferences, new books and new gems.
(Shameless plug: I curate a newsletter called Short Ruby that covers news from Ruby world every week).
Maybe Ruby is not at the level where is was in 2007-2009 but it is also NOT in a downward trend.
This is only an article, but you will find the same point of view in many other places. The decline of ruby and RoR is obvious for anyone doing web development. Python is only getting stronger, Typescript the same, not to mention the statically typed competitors like Java with Spring Boot.
I wouldn't doubt that even languages like Go and Rust might surpass ruby soon in web development because as general purpose languages they are already more relevant.
I'm a former RoR developer and I took off the keywords ruby and ruby on rails from my curriculum because for me professionally it makes no sense to invest time in them.
There are some points from that article that are false: there are podcasts, there are collection of good Ruby gems, and analysis the unicorn companies that were started with Ruby (or Rails) is a biased analysis.
So, if you decide to switch, it is only logical for you to believe that the Ruby community does not bring anything new to the table. I am not saying it as a bad thing. I decided to stay with Ruby, so of course, I am looking for clues that my decision is still reasonable.
One point about your last phrase: the market for Ruby developers - especially seniors - is active. At least in my own corner of the internet.
Google trends says there's a decline. Admittedly this is interest from the general public, not the feature set or the active developer community, but still, it reflects something.
I admit that Google Trends shows a decline from 2004-2007 era.
It could be my optimism, or it could be that I am biased, but I have seen at least a flat line since 2022 in that graph.
As I said, I see an increase when I look at the number of conferences, books, or gems started. That is a strong signal for me that the community is growing, or at least the community thinks it is growing.
Ruby got nothing else bigger than Rails unfortunately no matter how people in that community is hyping Ruby out.
It's okay if Ruby and Rails on a downward trend it might pick up again in the future.
C'mon now, we all know that our industry is like a Fashion industry.
The only reason why Rails is making a comeback is because we're in tough time: no more VC money to hire tons of Engineers to build a web-app.
When money was flowing, folks tend to build over-engineered solution (microservice, mesos, container, k8s, cloud-y orchestration), when money is tight, folks tend to build simple stuff because of lack of resources.
But now there is another complication to an eventual reemergence of ruby on rails: the competition defeated the initial comparative advantage - i.e. the simplicity - of the RoR platform. The premises that justified RoR in the past are too weak today in my opinion. The framework was sold on how easy and no-nosense it was setting it up and start prototyping your commercial solution in a time where the competitors were awkward and epitomized by J2EE, where setting up and developing the most basic application was time consuming and complicated.
Today with Spring Boot, for instance, you can bootstrap and develop your app as quickly and easily as any other cool and alternative framework but with the advantage of using a really popular and fast language.
Technologies don't die quickly and COBOL and Perl are the living proof, but it's really hard to see a bright future for RoR and ruby and I think that most of their contribution was already given.
Spring Boot has been there for ages. It changes nothing really.
Spring Boot was created solely for spinning up Microservice quickly. This is a different segment than Rails.
Spring Boot was overtaken by Golang in the microservice arena in US hi-tech scene. There's just way too may Go-based infrastructure that boosted Go ascend to the Microservice arena from 2016/2017-today. My experience might be just anecdotes but I worked for multiple companies that used to be Java based shop and they all moved away from Java/Scala to Golang and build tons of microservices (whether that strategy is the right thing to pursue or not is a different discussion altogether).
Yeah, Spring Boot might eventually decided to "tack" on the UI option (thymeleaf) but it's too late. Hi-tech already jumped to the latest fashion: Go, docker, k8s, with some sprinkle of ELK and Prometheus for monitoring.
> It's really hard to see a bright future for RoR and ruby and I think that most of their contribution was already given.
They're going to sit nicely in the corner where they belong: web-app. Nothing more, nothing less.
I'd argue the one trending down is Spring, especially after they joined VMWare and now VMWare is part of Broadcom.
Take this with a lot of grain of salt from someone who was a staunch defender of Java during the Spring (DI, MVC), DropWizards, Hibernate=>JPA2 era, skipping Ruby/Rails hype. I moved on from Java to Golang in 2018-2019 and haven't looked back despite switching multiple companies. Prior to that, I was swimming in Java world with multiple companies.
Now that I'm back in the market for my own webapp (side project, fun), I'm not going to use Golang for good reason and I'm not planning to go back to the Spring world either. Rails it is for me...
> Today with Spring Boot, for instance, you can bootstrap and develop your app as quickly and easily as any other cool and alternative framework but with the advantage of using a really popular and fast language.
Looking at the Spring Boot guides, the amount of setup, complexity and lines of code just to get an application running with MySQL doesn't support this statement: https://spring.io/guides/gs/accessing-data-mysql/
Even 20 years ago this would be easier in Rails.
Or try building the blog demo that's build on the Rails homepage video in Spring Boot.
35 minutes to build a blog with rich text (including image uploads), live comments, notification mails and tests. And after changing the database to PostgreSQL, deploy it to production.
https://rubyonrails.org/
If you're productive in Node or Python, then learning Ruby would just be educational in that it's something else to use. Personally, I've found Ruby to be a great language in which I can be productive quickly, which is why I stick with it, but I've written Ruby code off and on for the last 15 years in various forms of production code. I think it's great to learn, but I wouldn't switch to it (or anything) if you're already productive elsewhere.
I’d genuinely love to hear more about what you find difficult about Ruby coming from a heavier Python or NodeJS background.
For me, coming from more of a Ruby background, I found Python and Node to not be too hard to understand, and my only nitpick would be on how eggs/packages were managed and dealing with dependancies.
In particular, Python dependancies compared to Ruby dependancies were more challenging initially for me. I’ve grown to appreciate Python indents and find it nice to read, but that was also annoying at first.
I’m primarily a Ruby dev, but still find most languages easier to work with.
Ruby itself is not the issue. The way people and frameworks (looking at you Rails) abuse its mechanics in pursuit of “clean code” drives me crazy. An incredible number of things are downright challenging to debug because of the insane flexibility of Ruby.
Not op but compared with Python it's heavier in the syntax department. You would have an easier time going in the other direction and encounter less situations where you have to stop and think about what to use in which situation while learning.
The biggest problem with NodeJS ecosystem is the type of crowd that gets excited over NodeJS: JS developers, some web folks.
NodeJS does not attract the kind of people who build ElasticSearch, Kafka, Hadoop, Spring Framework, etc so the quality of the libraries reflected of that the Web Developers crowd: the short-term Do-ers (need it today, let's build it, and let's move on to the next interesting stuff).
That’s an optimization that can be added later, with some nuance. IIRC Go had a similar situation for years; I remember setting GO_MAX_PROCS in my init() or main()!
You might be interested in Chris Salzberg’s Im [0], already usable on Ruby 3.2, or the discussion about the speculative “namespace on read” feature [1].
Implicit or explicit, I’m OK with the global namespace.
On paper it’s awkward, but in reality convention and social norms make it rarely an issue.
The global namespace only supporting exactly one version of each gem encourages a health culture of stable ABIs and deprecation periods too. An absolute dream compared to some language ecosystems
I'm feeling a bit ignorant, but isn't this a Rails thing and not a Ruby thing? I know that for most projects that's a distinction without a difference; but, that may be a decision from the Rails devs and unrelated to what Ruby's devs do?
Or I'm speaking out of my ear and completely wrong (and I don't know which :D)
It's a Ruby thing. Ruby only has a single global namespace, no imports.
If anything Rails autoloading (Zeitwerk really) make it much easier to find where constants come from as it enforce a constant name -> file name convention, so all you need is fuzzy file search.
You're right, implicit import (autoload) is an opt-in feature. Rails used to use autoload by default as of 3.x/4.x. It's been quite a while since I used Rails, so I'm not sure if this is still the case.
Ruby imports have always used a single global namespace. I'm not convinced that this is an issue in practice - it's worked just fine for several other languages.
There's a big difference between Rails autoloading and Ruby autoload, in that Rails is implicit and conventional from the constant name plus load paths, whereas Ruby is explicit as one declares where to find each constant.
I mean, only because it's possible to learn to live with doesn't make it pleasant. Especially for managing large projects it can get unwieldy. Most high level languages I can think of have moved away from this approach.
I used to be a huge Ruby fan but having exposure to Python where this isn't an issue, life is just easier.
It's a matter of personal preference and/or which one you've learnt to live with first.
I like how Ruby's imports work - just load a file, similar to C. On the other hand, modules in Python always felt like something to overcome rather than "just works as you expect".
To each their own, I guess. After working with python/lua, I really appreciate not needing to do manual imports all over. I'm glad ruby makes this so easy :)
Oh, and not needing __init__.py files in order to import something. Goodness, what an absolute pain.
I agree, but Ruby folks seem to consider C style transitive inclusion to be a feature. I found it and several other aspects of Ruby to be maddening (and productivity-sapping) for the 1.5 years I spent with an otherwise pretty nice language.
Anyone have a link to some good examples of using Prism? I was disappointed to not really see anything other than the “Notable API” from this release page.
It's nice to see improvements to Ruby, but the hype around a ~13% performance boost feels... weird.
It looks like a big leap, but when you compare the actual speed to _any_ other language you realize Ruby still has many, many percent to go to even be in the same game.
Because even this graph from your article doesn’t show that, unless you’re comparing JIT vs non-JIT. But JIT has existed for awhile now (not new in 3.3).
YJIT is an amazing technology, and together with other innovations like object shapes and various GC optimizations, Ruby is becoming seriously fast! Big Ruby shops such as Shopify [1] have been running 3.3 pre-release with YJIT and reporting double digit percentage performance improvements.
Personally I'm really excited about Ruby and its future. I can't wait to start working with Ruby 3.3 and using it on my client's production sites...
[1] https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...
Edit: add percentage to performance improvements.