Pinned Tweet
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:
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:
1
0
9
856
Just reproduced the official Basecamp’s Pi benchmark with Rage.
Rage replaced Rails+Puma+Resque+Redis, handled 10x clients, with ~22x the deliveries per second and ~4x less memory per connection.
Rage replaced Rails+Puma+Resque+Redis, handled 10x clients, with ~22x the deliveries per second and ~4x less memory per connection.
1
0
5
130
The most common piece of feedback I got about Rage? “API-only sucks.”
So I shipped the official Inertia.js adapter. Auto-starts Vite in dev, pre-builds assets for prod, exposes Inertia props out of the box.
What’s your next excuse?
So I shipped the official Inertia.js adapter. Auto-starts Vite in dev, pre-builds assets for prod, exposes Inertia props out of the box.
What’s your next excuse?
2
2
5
348
Rage just got daemons.
Rage::Daemon lets you run long-lived background processes alongside your app.
No external process managers needed. The processes your app depends on now have a home inside the app, supervised by the framework.
Rage::Daemon lets you run long-lived background processes alongside your app.
No external process managers needed. The processes your app depends on now have a home inside the app, supervised by the framework.
0
1
7
1,144
For several months, I wanted to optimise the code in Rage that schedules fibers to be woken up at a specific time. The plan was to use skip lists.
Last week, @maciejmensfeld’s compilation of Ruby performance PRs got me inspired, and I decided to give it another look 🧵
Last week, @maciejmensfeld’s compilation of Ruby performance PRs got me inspired, and I decided to give it another look 🧵
1
0
2
135
Looking back at the previous example, if 1000 fibers try to fetch a connection from an empty pool, each new timer will be `Time. now + 5` - i.e. higher than the previous one.
Which means that if we first check the last element in the list before doing the O(N) insertion, we can get constant-time insertions in the most common scenario.
Which means that if we first check the last element in the list before doing the O(N) insertion, we can get constant-time insertions in the most common scenario.
1
0
0
63
Benchmarks across a full request cycle - request in, connection pool, database query - show the 2.2x to 4x improvement. In 30 lines of code.
Simplicity-driven development wins again.
Simplicity-driven development wins again.
0
0
0
32
Recurring background tasks in Rage are one config block away.
Background tasks run on fibers - light, fast, and in-process.
Background tasks run on fibers - light, fast, and in-process.
1
0
11
999
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.
The worst case for a fiber-based server is thread level performance.
The downside isn’t really there. The upside is.
0
0
2
68
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.
rage-rb.dev/blog/2026/05/1…
6x and 10x lower p95 latency under load. 0% errors.
Real endpoints, real traffic - not micro-benchmarks.
rage-rb.dev/blog/2026/05/1…
0
0
1
75
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.
Those parallel traces? That’s just fibers doing their concurrency thing without you having to worry about it.
Works with any OTel-compatible backend.
0
0
0
67
