Why is Ruby losing ground? It's not because the language is "dead" - it's because our tools haven't evolved to meet modern performance and stability needs.
I built Rage to give Ruby teams the missing pieces they've been looking for in other ecosystems.
A thread on the mission behind Rage:
The common Ruby advice - “default to threads, only reach for fibers if you’re I/O-heavy” - is backwards.
The worst case for a fiber-based server is thread level performance.
The downside isn’t really there. The upside is.
What happens when you move two production Rails apps from threads to fibers?
6x and 10x lower p95 latency under load. 0% errors.
Real endpoints, real traffic - not micro-benchmarks.
https://t.co/0nG7wMb7Dk
Rage has official OpenTelemetry support.
Those parallel traces? That’s just fibers doing their concurrency thing without you having to worry about it.
Works with any OTel-compatible backend.
@hschnedlitz@excid3 I can see how it makes sense at scale, but for small-to-medium teams, gems give you community support, security patches, and new hires already know the tool. Hard to replicate that with a custom build.
Looking forward to hearing your take on this!
Speaking at @BalkanRuby in two weeks on Rage:
• Linear Ruby that runs async - no callbacks, no new syntax
• Promise.all-style concurrency with fibers
• 2.6x throughput improvement in real-world benchmarks
Why “works with everything” means “optimised for nothing”.
Phlex components that update themselves on the page in real time. No JS. Rendering and event handlers in the same class.
Built on Rage’s fiber runtime + SSE.
Code: https://t.co/TxcQktLZPs
Live demo: https://t.co/w5GYbSh105
The result: you process more requests before degradation kicks in. And when it does, it’s graceful - the same TCP-level queueing every server relies on.
A server’s job is to process requests. Let it.
Unbounded concurrency sounds scary. But it’s actually how most of the internet works.
Rage is fiber-based. If a request comes in and can be accepted, it gets a fiber and starts processing. This sounds scary, but it’s actually a feature. 🧵
And under load, backpressure happens naturally - compute still takes time. The even loop slows, the server stops accepting, requests queue in the socket.
Same outcome as with Puma. But it happens later - when the server is actually saturated, not when an arbitrary limit says so.
Unbounded SSE streams are now live in Rage!
• Attach connections to named streams
• Broadcast from anywhere (including background tasks)
• Multi-server sync out of the box via Redis Streams
There’s a sense of liberation I feel when building with Rage. Not benchmarks - the quiet confidence that your app can handle whatever you throw at it, without you doing anything special.
This safety net is why people love Go so much. We just need more of it in Ruby.