The API looks nice on the surface, but this will be expensive to operate due to Ruby and Rails’ lack of support for concurrency. Everything is blocking, which is not a great match for the async nature of interacting with these models.
Well instead of looking at the two first hits of Google I spent several years on a platform team of a multi billion dollar company using mostly Rails and worked on solving real world problems caused by Ruby/Rails’ design choices which lead me to believe that Ruby concurrency as of today is hot garbage.
They need fundamental breaking changes to the language to fix this, which means people won’t be able to use their beloved pile of 438 gems that haven’t seen a commit in 7 years. If I had to bet, I’d say the language is dead. It might still be a nice niche language for easy prototyping, but the world has moved on to async/await (js/python/Rust/C++) or stackful coroutines (Go).
Unfortunately, 5 years after the release you linked, almost none of this has made it to Rails or even to relatively new libraries this post is about. The reason (imho) are unfortunate design choices in how the language incorporates concurrency - it’s just not well done.
This will synchronously block until ‘chat.ask’ returns though. Be prepared to be paying for the memory of your whole app tens/low hundreds of MB of memory being held alive doing nothing (other than handling new chunks) until whatever streaming API this is using under the hood is finished streaming.
Yes, it does. Ruby has a global interpreter lock (GIL) that prevents multiple threads to be executed by the interpreter at the same time, so Puma does have threads, they just can’t run Ruby code at the same time. They can hide IO though.
Concurrency support is missing from the language syntax and this particular library as a concept. This is by design, to not distract from beautiful code. Your request will make zero progress and take up memory while waiting for the LLM answer. Other threads might make progress on other requests, but in real world deployments this will be a handful (<10). This server will get 10s of requests per second when something written in JS or Go will get many 1000s.
It’s amazing how the Ruby community argues against their own docs and doesn’t acknowledge the design choices their language creators have made.
I don’t know why “number of companies using language X” is a metric that is used here. Wordpress is serving 43% of websites on the internet as of 2025, so we should all be learning PHP!
That's very nice, but not in itself a good argument for language use. If you count using a system written in a language, then almost every programmer uses Ruby daily as both Github and Gitlab are written in Ruby. Similarly you probably interact quite frequently with (banking) systems written in COBOL, but nobody would call COBOL a popular language.
This solves the problem of slow transport between your frontend and your backend, but it will still incur a lot of unnecessary load on the database as well as compute on your backend (which isn't normally a problem unless you're using something really slow like Rails).
Why? Queries would still have to be done. Yes, a few things would be duplicated (authentication), but on the other hand, queries can be cached at a more fine grained level. It's easier to cache 3 separate queries of which one can be re-used later, than to cache one monster query. s/query/response
I personally don't think there's much value in writing assembly (vs using intrinsics), but it's been really helpful to read it. I have often used Compiler Explorer (https://godbolt.org/) to look at the assembly generated and understand optimizations that compilers perform when optimizing for performance.
Your commented is directly contradicted by the article.
> To make multimedia processing fast. It’s very common to get a 10x or more speed improvement from writing assembly code, which is especially important when wanting to play videos in real time without stuttering.
They said they prefer intrinsics which the article says are only about 10% slower(citation needed), you misunderstood and made a comparison against scalar.
Personally I'd say the only good reason to use assembly over intrinsics is having control over calling convention, for example the windows CC is absolute trash and wastes many SIMD registers.
Is it? To me it seems like Ruby is declining [1]. It's still popular for a specific niche of applications, but to me it seems like it's well past its days of glory. Recent improvements are nice, but is a JIT really that exciting technologically in 2025?
Ruby will probably never again be the most popular language in the world, and it doesn't need to be for the people who enjoy it to be excited about the recent improvements in performance, documentation, tooling, ecosystem, and community.
I think ruby can get popular again with the sort of contrarian things Rails is doing like helping developers exit Cloud.
There isn’t really a much more productive web dev setup than Rails + your favorite LLM tool. Will take time to earn Gen Z back to Rails though and away from Python/TS or Go/Rust.
My impression is that a Rails app is an unmaintainable dynamically-typed ball of mud that might give you the fast upfront development to get to a market or get funded but will quickly fall apart at scale, e.g. Twitter fail whale. And Ruby is too full of "magic" that quickly makes it too hard to tell what's going on or accidentally make something grossly inefficient if you don't understand the magic, which defeats the point of the convenience. Is this perception outdated, and if so what changed?
If the the Twitter fail whale is your concern, then your perception is outdated. Twitter started moving off Ruby in 2009. Both the CRuby VM and Rails have seen extensive development during that decade and a half.
I never worked at Twitter, but based on the timeline it seems very likely they were running on the old Ruby 1.8.x line, which was a pure AST interpreter. The VM is now a bytecode interpreter that has been optimized over the intervening years. The GC is considerably more robust. There's a very fast JIT compiler included. Many libraries have been optimized and bugs squashed.
If your concern is Rails, please note that also has seen ongoing development and is more performant, more robust, and I'd say better architected. I'm not even sure it was thread-safe when Twitter was running on it.
You don't have to like Ruby or Rails, but you're really working off old data. I'm sure there's a breaking point in there somewhere, but I very much doubt most apps will hit in before going bust.
The CRuby VM, or the CRuby interpreter alone is at least 2-3x faster since Fail Whale time. And JIT doubles that to 4 - 6x. Rails itself also gotten 1.5x to 2x faster.
And then you have CPU that is 20 - 30x faster compared to 2009. SSD that is 100x - 1000x faster, Database that is much more battle tested and far easier to scale.
Sometimes I wonder, may be we could remake twitter with Rails again to see how well it goes.
My issue with Ruby (and Rails) has always been the "ball of mud" problem that I feel originates from its extensive use of syntactical sugar and automagic.
Rails can become a ball of mud as much as any other framework can.
It's not the fastest language, but it's faster than a lot of dynamic languages. Other than the lack of native types, you can manage pretty large rails apps easily. Chime, Stripe, and Shopify all use RoR and they all have very complex, high-scale financial systems.
The strength of your tool is limited to the person who uses the tool.
Python? Ruby with YJIT, JRuby or Truffle Ruby usually beats python code in benchmarks.
I haven’t seen a direct comparisons but I wouldn’t be surprised if Truffle Ruby was already faster than either elixir, erlang or php for single threaded CPU bound tasks too.
Of course that’s still way behind other languages but it’s still surprisingly good.
In my work I’ve seen that TruffleRuby codebases merging Ruby and Java libraries can easily keep pace with Go in terms of requests per second. Of course, the JVM uses more memory to do it. I mostly write Go code these days but Ruby is not necessarily slow. And it’s delightful to code in.
> Python? Ruby with YJIT, JRuby or Truffle Ruby usually beats python code in benchmarks.
Isn't that moving the goal post a lot?
We wen't from 'faster than a lot of others' to 'competing for worst in class'.
I'm not trying to be facetious, I'm curious as I often read "X is really fast" where X is a functional/OOP language that nearly always ends up being some combination of slow and with huge memory overhead. Even then, most Schemes (or Lisps in general) are faster.
Being faster single threaded against runtimes that are built specifically for multithreaded, distributed workloads is also perhaps not a fair comparison, esp. when both runtimes are heavily used to write webservers. And again, Erlang (et al) come out faster even in those benchmarks.
Is TruffleRuby production (eg. Rails) ready? If so, is it that much faster?
I remember when the infamous "Truffle beats all Ruby implementations"-article came out that a lot of Rubyists were shooting it down, however this was several years ago by now.
Moving the goal posts? Perhaps I misunderstand what you are asking.
Python is the not the worst in class scripting language. For example perl and TCL are both slower than python.
Originally you just asked, "such as" [which dynamic language ruby is faster than?]
Implying ruby is slower than every other dynamic language, which is not the case.
JRuby is faster than MRI Ruby for some Rails workloads and very much production ready.
Truffle Ruby is said to be about 97% compatible with MRI on the rubyspec but IMHO isn't production ready for Rails yet. It does work well enough for many stand alone non-rails tasks though and could potentially be used for running Sidekiq jobs.
The reason to mention the alternative ruby runtimes is to show that there's nothing about the language that means it can't improve in performance (within limits).
Whilst it's true that ruby is slower than Common Lisp or Scheme, ruby is still improving and the gap is going to greatly reduce, which is good news for those of us that enjoy using it.
Thank you for a great answer; I did not mean any ill will and apologize if that was how it came across.
Perl, Tcl, Smalltalk etc are basically non-existant from where I'm from, so they didn't occur to me.
Perhaps I'm projecting a lot here. I have worked a lot in high performance systems and am often triggered by claims of performance, eg. 'X is faster than C' when this is 99.9% of the times false by two orders of magnitude. This didn't happen here.
Java's Hotspot was originally designed for Smalltalk, and SELF.
Two very dynamic systems, designed for being a complete graphical workstation, Perl, Tcl, Python, Ruby were as originially implemented, not even close of the original Smalltalk JIT paper from Peter Deutsch's paper"Efficient Implementation of the Smalltalk-80 System." in 1984!
the ruby is faster than c is because of the yjit. they are moving a lot of c ruby standard library and core language stuff into ruby code so the yjit can optimize it better. akin to java and their bytecode being able to optimize things on the fly instead of just once at compile time.
No one uses Ruby because it is fast. They use it because it is an ergonomic language with a battle-tested package for every webserver based activity you can code up.
Crystal is an ergonomic language, too, looking a lot like Ruby even beyond a cursory glance. What Ruby has, like any longstanding language, is a large number of packages to help development along, so languages like Crystal have to do a lot of catching up. Looking at the large number of abandoned gems though, I'm not sure it's that big a difference, the most important ones could be targeted.
I'm not sure that has any relevance when compared with Python or JS or Go though, they seem to have thriving ecosystems too - is Rails really that much better than the alternatives? I wouldn't know but I highly doubt it.
> is Rails really that much better than the alternatives?
I really think so. I've _looked_. I've tried all sorts of other web frameworks. And, admittedly, I am most familiar with Rails, so I'm maybe a bit biased. But it's hard to find anything that comes particularly close to the productivity of using Rails. The tooling's great, the ecosystem is great, it's organized well, the documentation is good. It's just... really a pleasant experience to use.
Elixir's Phoenix comes pretty close, as does PHP's Laravel, imo. Special shout out for Rust's Loco, too, which is relatively new, but looking potentially promising.
I recommend giving Rails an open-minded tire kicking. I think you'll be surprised by how quickly you can get going.
I've used Rails (I've possibly committed to it, though I've forgotten if I have), my point is that I don't know those other languages' frameworks well enough to judge the difference, but I don't see any complaints.
You even seem to admit as much while being most familiar with Rails. Do you know anyone who'd love to switch over? Or would you choose it ahead of a competitor if you were green? There'd have to be a large competitive advantage.
I’d jump ship if there was a mature, stable competitor in the Typescript ecosystem.
Unfortunately I think language differences mean it’s going to be a long time before anyone catches up. Ruby just makes for some really interesting wizardry that as far as I can tell isn’t possible (or perhaps not as ergonomic?) in Typescript.
Furthermore there seems to be a cultural difference. I haven’t met many JS devs who came to the Ruby side and were like, “Aw shit this is better.” (I’m one such dev, but I hated Ruby and Rails for a really long time before I changed my opinion and embraced it.)
But at this point in my career I value stable boring technology way more than my personal taste du-jour so I code in Ruby and really love Rails.
I am still hoping once Crystal stabilise on Windows ( Currently it still feels very much beta ). They could work on making compiling speed faster and incremental compiling.
Unfortunately it is, because too many folks still reach out to pure interpreted languages for full blown applications, instead of plain OS and application scripting tasks.
When people say these apps are IO bound, what they actually mean is that they are memory bound. While Rails is waiting for IO due to its lack of concurrency support and the ubiquitous use of global variables in the ecosystem, a passenger worker is taking up >300mb of memory for a medium sized Rails app. Server memory limits the amount of workers you can have waiting like that, which in turn limits overall throughput per server.
That may be true for very memory constrained platforms like Heroku, but is a non issue at larger scale.
Taking your figure of 300MiB per process, and assuming you might want to run 1.5 process per core to account for IO-wait, that's 450MiB per core (ignoring copy-on-write).
If you look at various hosting offering, most offer something like 4GiB of RAM per core (e.g. EC2 "general purpose" instances).
As for the lack of concurrency support, Active Record has asynchronous queries since a few versions, and is now even async/fiber compatible. So if you truly have an app that would benefit from more concurrency, you can do it.
They mean the app takes data from one place, does a trivial computation, and pushed it at another place. So pushing data around is all the application does.
And they don't know both such places are actually faster than the trivial computation because their code runs way slower than the ones at the origin and destination.
reply