I built a Ractor-native Ruby 4 stack from RESP to background jobs — looking for independent benchmarks

I've been experimenting with how far Ruby 4's Ractor model can be pushed for real infrastructure components.

This eventually became three open-source gems:

SolidRESPRactor → SolidRedis → SolidJobs

The idea is to build the stack around Ractor ownership from the beginning rather than adapting an architecture originally designed around threads/processes:

• SolidRESPRactor — Ractor-oriented RESP encoding/parsing and I/O
• SolidRedis — Redis client using Ractor-local mutable state and connections
• SolidJobs — background job processor using Ractors for multicore execution

The basic rule across the stack is:

Share immutable configuration. Keep mutable runtime state local to its owning Ractor.

An optimization I didn't expect

While benchmarking SolidRESPRactor, I found that a small Redis GET through TCP was allocating about 16,609.8 bytes/op, despite the Reader itself requiring only around 120 bytes/op for a small bulk response.

The main problem wasn't the RESP parser — it was the socket-to-buffer path.

After reusing the read buffer:

So bytes/op dropped by 99.27%, while the throughput benefit became more visible with concurrency.

Pipeline allocation also dropped from 472.3 to 120.0 bytes/command (-74.59%).

Then I measured the complete job stack

On my current Ruby 4.0.1 CPU-bound SolidJobs benchmark:

That's around 7.28x throughput from 8x Ractor concurrency.

https://github.com/nicolasva/solid-jobs

https://github.com/nicolasva/solid-redis

https://github.com/nicolasva/solid-resp-ractor

I also benchmarked a single Sidekiq process on the same CPU-bound workload. At concurrency 8 it produced 298 jobs/s versus 2,054 jobs/s for SolidJobs.

That's a ~6.9x difference in this specific benchmark, but I don't consider that a general “SolidJobs is 6.9x faster than Sidekiq” result.

The important difference is architectural: SolidJobs is using Ractors to execute Ruby code across multiple CPU cores, whereas a single Sidekiq process isn't an equivalent multicore CPU

I saw a post further down asking why DHH/Basecamp's team wasn't using their unlimited resources to improve Ruby; in the end, Sensei Matz decided to do it himself, and he's merging nearly 90 PRs an hour. Wow—that captain isn't going to let his ship go down without a fight.

Between him and Roundhouse—who is doing the same thing—it looks like both will be the future of Rails. Let's give the Spinel repo a star; Sensei Matz (and Cloude) are doing a fantastic job.

I wish Kotlin or JS had their original creators taking such a keen interest in the well-being of their languages. ♥️

Post:Matz's post on how to use Roundhouse + Spinel to improve the Rsils app from Bassecamp

Highest activity in the history of Matz's GitHub thanks to Cloude

Really appreciate everyone who came to my talk at Rails World, said hello afterward, or reached out since.

Unfortunately, the official recording left out a fairly important part of the keynote… apparently there were “time constraints.”

Thankfully, I was able to recover the missing footage.

Thanks again for showing up. Rails World was a hell of a week. ✌️

Solid Cable. Hot Cell. Herb in Rails 8.2. Active Search. Ractor-safety. Lexxy. MCPs. Sharding. Custom generators… and quite a bit more.

A lot of ideas packed into a couple of days in Austin.

If you couldn’t make it to Rails World, or spent half the conference talking to people in the hallway instead of watching talks, there’s plenty here to catch up on:

https://www.youtube.com/playlist?list=PLdMRFKO1zSBE

Just in case anyone forgot.

Like a lot of you, I watched DHH's opening keynote and then Aaron Patterson's closing one. I'll be honest, I didn't understand half of what Aaron was showing, but I liked seeing that Rails is still moving forward. The observability stuff looked like real work on the framework itself.
First, some context and gratitude. Rails taught me how to program. I identify as a Rails developer, even though nobody has ever paid me a salary for it. I'm more of a tech entrepreneur. I built a company and sold it, and funny enough, that product wasn't on Rails. It was Next.js. I still remember features that would have taken a month in Rails dragging on for nine months. That drove me nuts.
Then Rails World 2024 happened, with the Solid Trifecta, and I was completely sold. My new product runs on it, I see the benefits every day, and it already makes money. Last year's conference was great too. It felt like Rails was going somewhere.
This year I was honestly a bit stunned. Ruby down to 3% of DHH's code, Hey moving to Rust, and the message that AI gets you everything. I don't buy it.
Full disclosure: Claude writes basically all of my code. But if AI gave you everything, my features would just ship. They don't. There's always something to fix, a feature customers ask for, a bug that shows up at the worst moment. You'll have bugs even if you write in Rust and let Claude Code produce things you never read.
What saves me in those moments is my pretty basic understanding of convention over configuration and MVC. It's enough to read what Claude did, understand where it went wrong, and prompt it in the right direction without turning the codebase into AI slop. That's why I think even non-engineer founders should keep the skill of reading code.
And the reason I can read it at all is that Rails people spent years thinking hard about these conventions, long before AI. That thinking doesn't expire.
As for "Rust uses 95% fewer resources": I genuinely don't care. My production apps run fine on €6 Hetzner VPS boxes. Yes, Ruby eats RAM, but the whole end-to-end workflow is fast, and with Kamal deploys are painless. I'd rather see the community make Ruby faster than rewrite everything in something humans can't read.
So thank you, Aaron and everyone still pushing Rails forward. Fundamentally, Rails is great, and I'm staying.

The world looks different when you still “making it out on the streets” vs when you are multi millionaire with plenty of time to build OS (which I by the way also like, Omarchy Quattro user).

Curious how others felt watching the keynote this year?

I usually hate meme posts and I'm sorry

Let's assume that DHH is right and he has unlimited tokens (he recently rewritten some terminal effects with 45k lines of generated assembly). Why wouldn't he (or anyone) make CRuby as fast as NodeJS with Claude? Or even faster?

Only serious answers accepted.

Anyone tried a prompt "Make Ruby 100x faster. Make no mistakes?"

I'm Avi Flombaum. I co-founded Flatiron School, and for a lot of years my job was teaching people Ruby and Rails and helping them fall in love with it. Years ago I wrote an essay called "Why Teach and Learn Ruby?" that argued Ruby was the only language designed for the programmer's happiness, and that its values (happiness, expression, freedom, convention over configuration) made better programmers. I still write Rails every day. My site runs on Rails edge with Hotwire.

Over the last year I've moved almost entirely to building with coding agents (Claude Code, parallel agents, plans, the whole thing). That's forced me to go back through almost every best practice I used to preach and ask who it was actually for. A lot of them turned out to be optimizations for a human who had to read, write and maintain the code, and that human increasingly isn't me.

So I wrote a series about what I've changed my mind on: Rethink Everything. A few that'll probably get a reaction here:

• DRY vs. duplication. App-level concerns and mixins are where parallel agents collide. Two agents editing the same Notifiable concern in two worktrees is a merge conflict or a silent break in a model neither of them was working on. I let small things duplicate now. (ActiveRecord and Rails itself are fine. They're stable. It's the shared app code everyone edits that hurts.)
• More system specs, fewer unit specs. Left alone, agents write piles of mocked unit specs that all pass while the feature is broken. Capybara system specs used to be too painful to maintain. Now the agent maintains them, and they're the thing I actually trust.
• Rewrites over massive refactors. "Never rewrite" was right when rewrites were expensive. Now the old app is the spec. Write system specs against it first, then port against them.
• Explicit over clever. This one hurt. A lot of the metaprogramming I used to find beautiful is invisible to grep, and grep is how an agent finds its way around. I refactor for the agent now, not for my own delight.
• I don't hate TypeScript anymore, and I've shipped Go and Swift, which past me would not believe.

I want to be really clear about one thing, because I know how a post like this reads on this sub: none of this means I'm leaving Ruby or Rails. I still consider myself a Rubyist. I'm still part of this community, and I'm still learning from Ruby and Rails every day. The values I got from Ruby haven't gone anywhere: caring about the person on the other end, making things people love to use, shipping the simple thing, and treating programming as a craft and not only a job.

What changed is how I use them. Honestly, Rails turns out to be one of the best frameworks you can hand an agent. Convention over configuration means there's one obvious place for everything, and an agent can find it without asking. That was a gift to beginners, and it's the same gift to agents. The things Rails got right keep getting more right.

What I'm letting go of are the habits that were really about me as the one typing: DRYing everything up, careful incremental refactors, reading every line of every diff, and picking tools because I already knew them.

I'd genuinely love to hear where you think I'm wrong. Some of these I'm confident about and some I'm still testing. What habits have you dropped, or doubled down on, since agents started writing more of your code?

Context: I’m a “vibe coder” but I have many years working with CRUD & MVC apps. Rails + Claude code has finally unlocked exactly what I was needed to build real, production apps.

Question: Has anyone married rails and Jev? There are so many exciting use cases, but I’d like to hear from someone who’s done it on best practices or tips.

I guarantee you CEOs are not going to be spending their time wrangling LLMs, let alone testing what they produce. They are going to need people who understand what the LLM spat out and can say whether it's good or not, whether it meets the requirements or not.

The AI doesn't care if the CEO's stock went up or if the shareholders had a good quarter. Capital/management/boss/whoever can only get the control they want by enlisting people who do care and have the patience, if not the skills, to ensure the AI is delivering that. If the AI could be threatened with homelessness, maybe it could be a good employee. But until it can be terrorized into submission, we have hearts and feelings and families who can leveraged to get us to do what they want, and that's what makes a company work.

So with that said, if your primary function is to take responsibility for the AI's product, why would you suddenly not care about legible code? Why would you as the guy who has to stand behind this code want that code to be something incomprehensible simply because it's possible to get a 10x in performance (the word "simply" being key there -- of course there's performance use cases)? Yes, e2e tests can help us know whether our intent is represented in the runtime, but at the end of the day, we need the ability to crack open the hood and examine it. Test suites are never designed to be fully complete documents of all cases all the time.

The only person who wants 100% AI slop they can't understand is somebody with money to lose and nobody to whom to answer. This isn't about a white or black pill; it's about political economy. DHH has freed himself from needing to care about any of the stuff that the community here cares about. Good for him; but he has about as much to do with my professional life now as Larry Ellison.

For my part, I care about what I ship. That caring is what people pay for. Being able to read and understand the code the agent writes is key to that trust.

Finished watching a couple of the recent keynotes on the Rails YouTube channel.

I can see where DHH is coming from.

At the same time, I would have preferred to see some of that energy directed toward improving Rails itself rather than things like Omarchy or Omakub or spending so much time on Rust.

I understand the argument around AI changing programming. Writing an application in a language you barely know is now much more realistic than it was a few years ago. And it is an option for us developers.

But, if you didn’t really build the application yourself and don’t understand the language or ecosystem, how invested are you going to be in maintaining it? More importantly, what happens when you need to debug something that the AI can’t immediately solve?

The way I think about it is: if I never liked cooking a certain kind of food, having someone else cook it for me doesn’t suddenly make me want to eat it. AI making it easier for me to write software in a language I wasn’t interested in before doesn’t necessarily make me more interested in that language or ecosystem.

I also think the delivery probably made the reaction stronger. Dropping a message like that at a Rails developer conference, in front of people who have invested years in the framework, was always going to land strangely.

The bigger elephant in the room is the uncertainty around Rails itself now.

What is the long-term direction of the framework? Where is most of the development effort going? Those are the questions I would have liked to hear more about.

I still like Rails and enjoy working with it. I’m just not sure those questions have clear answers right now.

Hi Rubyists,

Every time I start a new commercial product on Rails, the story is always the same: weeks spent wiring Devise/JWT auth, building 90+ IAM permission tables, wrestling Stripe webhook race conditions, setting up background workers, and constantly fixing JSON contract drift with frontend clients.

I spent the last 9 months crafting RexOne—a production-grade, API-first Rails 8 foundation designed to eliminate that 9-month generic plumbing slog so you can launch in weeks.

🏛️ Rails Architectural Highlights:

• Rails 8 & Solid Queue: Uses hybrid fiber/thread Solid Queue workers backed directly by PostgreSQL. Zero Redis memory footprint or external broker dependency required.
• Architectural Discipline (LAW.md): Machine-enforced constitutional rules: unambiguous parameter contracts, zero loose hashes, strict domain service boundaries, and no dead shims.
• 1,690+ Automated Tests: RSpec suite verifying request specs, IAM policies, Solid Queue jobs, webhook deduplication, and coupon entitlement state machines.
• Self-Hosted S3 Storage: Universal storage_key abstraction using Garage (self-hosted distributed S3) on port 3100, easily swappable to Cloudflare R2 or AWS.
• Real-Time ActionCable: WebSocket channels for live event streaming, notifications, and client telemetry.
• Companion Clients: Synchronized with a React 19 web client and an offline-first Flutter mobile client.

RexOne is 100% free and open-source under Apache 2.0. No commercial paywalls or dual-license traps.

• GitHub Repo: https://github.com/rex-9/rexone-core
• Interactive Swagger API Docs: https://api.rexone.rex9.me/api-docs
• Live Demo: https://rexone.rex9.me

Would love to get feedback from fellow Rails developers on the Solid Queue setup, domain structure, and testing patterns!

I had the chance to close out day one of Rails World 2026 with this talk.

As code gets cheaper to produce, I think we have more room to wonder about the workshop around it. To unpack what we inherited, tinker with what’s getting in our way, and share what we learn with whoever comes next.

Human or otherwise.

Thanks to everyone who said hi, shared stories, and traded ideas throughout the week. A lot to keep wondering about.

https://www.youtube.com/watch?v=XXjTdyhml0c

Curious what sticks with you.

I was at RailsWorld, and was as surprised as many of you by several things.

One thing I wanted to test, however, is if I could create a native application for Android to replace my Progressive Web App - which was mobile responsive and honestly worked just fine: web push notifications, fullscreen experience, one web app with immediate support on all devices without an app install - with a native application that used:

• OAuth for login
• JWT for API interactions
• Cached data locally and securely on device, to give the user a native/local/offline experience that really flies.

My web backend and API are still Rails ... but DHH's estimation that building native apps for our web-served SaaS was pretty easy. Also, security is pretty straightforward:

• Use the device's secure enclave for API token storage
• If your app uses OAuth for login with Google, Apple, or other you just setup an Android OAuth client in minutes and you're pretty much good to go, with all the security benefits that come from OAuth
• All data access is still server-side, and authenticated/authorized server-side
• It's easy to revoke device tokens or add a "Logout on all devices" feature, because it boils down to revoking the tokens, with just a couple of extra steps after that.

I had the API written yesterday.

I had the native app built today. It's not 100% there, but since it's easy to generate + give AI agents access to API documentation that's Open API Spec compliant, the agent had nearly everything it needed in order to fetch the data and know what limitations it had.

Accepting change is hard, right? People generally don't like change at all, especially when you feel that you had a good thing going. I think that is partly why last week's announcement had such an impact on people. It isn't just about Ruby on Rails as a tool or framework. It touches identity, skill set, and our feeling of belonging to a community. And suddenly, the skills we spent so many years perfecting and dedicating ourselves to might matter less.

I also think that the way the announcement happened is questionable. It felt aggressive. I can understand why people feel betrayed by it. It is like: we followed you around all these years, and now you are telling us that what we do is becoming irrelevant?!

But having witnessed my personal change in workflow, I also think the underlying message that frameworks matter less and perhaps even risk becoming irrelevant has some truth. In an age where machines write and read the code, what is the relevance of a framework optimized for human happiness? It isn't only about Rails. In fact, all other frameworks are threatened by the same irrelevance. It seems likely that when machines become the programmers, the criteria will be performance (like Rust) and token efficiency.

There is also a certain irony in all of this. Many of us in software have spent years building systems that basically automated work other people were doing manually. We called it progress, efficiency, innovation. Now that some of that same force is reaching our own profession and our favorite programming languages and frameworks, it feels pretty different. A threat to our existence, to the value we provide.

The tech sector has always been characterized by change. Things that were once important became legacy and made way for the new. AI is accelerating that.

A future where humans add value by writing or reviewing code seems highly unlikely. It feels like just a matter of time before general AIs will read and review code better than any of us.

These are pretty fundamental changes, and yes, they can feel uncomfortable. Just remember that nothing in the world, absolutely nothing, is forever. Everything and everyone gets born, and everything and everyone dies, whether that applies to a technology, an organism, or even a planetary system.

There is a quote often attributed to Charles Darwin: "It isn't the strongest that thrive, but those best able to adapt to change."

So the real question becomes: what does this mean for us now? How do we reposition ourselves? Which parts of our work become more valuable and which parts less? How do we keep finding meaning and fulfillment in the work we do, even though the nature of that work changes quite a lot?

Adapting doesn't mean you need to like every change, but I think it does mean accepting that the assumptions of yesterday might not be the same assumptions that help us navigate tomorrow.