Rails vs Rust in 2026, after HEY moved its backend

The creator of Rails is rewriting his flagship product's backend in Rust, and he announced it in the opening keynote of the Rails conference. Anybody choosing a stack this week has to get past that before any argument for Rails is audible, so this page starts there and does not soften it.

What DHH announced, and what he did not

On 23 September 2026 DHH opened Rails World 2026 in Austin. The @rails account summarised the talk as being "on the age of AI agents: why 37signals has gone 'pencils down' on handwritten code, why Rails' convention over configuration is built for this moment, and why the only play left is total optimism." His own post put the first half of that more bluntly: "It's pencils down, people. Writing code by hand is no longer an economically viable skill for most programmers at most companies. But the future of making software has never been brighter. Don't you dare black pill this beautiful moment!"

The product announcement inside it is the part that matters for a stack decision. HEY 2.0 will be native apps on every platform plus a Rust backend, which DHH said is efficient enough to serve HEY's peak traffic on a Raspberry Pi, all of it coded by agents directed by programmers and designers. On the language he added the line that travelled furthest: "I love Rust! Rust is amazing ...if you never, ever, EVER have to look at it yourself."

Nobody here watched the keynote. The video is at youtu.be/vDjW_dRyKXY and the session is listed on rubyonrails.org/world/2026, and every quotation above is attributed to the post or the report it was read in rather than to the room.

What was not announced is worth as much as what was. The keynote named HEY. 37signals shipped Basecamp 5 in June 2026 and discussed it on the official On Rails podcast in an episode that is otherwise about what is coming to Rails. So the accurate sentence is that one product's backend, at one company, is leaving Rails, and that this is neither a deprecation nor nothing. What DHH actually said goes through the keynote's claims one at a time.

HEY has three things your product probably does not

HEY runs at a scale, with a staff, and against a hardware bill that almost no product making its first stack decision shares. Each of the three changes the arithmetic of a rewrite.

The hardware bill is the one with public numbers on it. 37signals writes about its cloud exit at basecamp.com/cloud-exit, and the reporting around it, The Register's in May 2025 among others, puts the shape of it like this: an AWS run rate above $3.2 million a year, roughly $600,000 of Dell gear at the start and something closer to $800,000 later, a projected $10 million saved over five years, and 18 petabytes of Pure Storage bought for about $1.5 million to operate for under $200,000 a year. When you own the machines, halving the CPU a request costs converts into fewer machines on the next purchase order. On a rented dyno running one process, halving the CPU a request costs converts into the same invoice at the end of the month.

The workload is the second difference. A paid email host is inbound SMTP, storage, full text search and a lot of long lived connections. Forms over a database is not that workload, and a backend tuned for the first tells you very little about the second.

The staff is the third and the least discussed. A second language is a permanent tax: two deploy paths, two dependency ecosystems, two sets of people who can be woken up at night. 37signals can pay that tax out of petty cash. A founder and a contractor cannot.

The Raspberry Pi claim is a claim about the client too

HEY 2.0 changes the language and the client in the same move, and only one of those two is a Rust story. Native apps on every platform mean the server stops rendering HTML, stops shipping view templates and stops serving an asset pipeline, and answers with data instead. Rendering and delivering views is most of what a Rails server in an application like HEY spends its CPU on. Subtract that and the remaining backend is dramatically smaller before anybody has chosen a language for it.

Commenters on the Hacker News thread about the keynote made exactly this point, and it is the thing to check when a real number is eventually published. A comparison that swaps the language and the architecture at the same time measures the pair. It does not attribute the result to either half.

None of that says the claim is false. A Rust service answering JSON from a machine in a rack may well fit on absurd little hardware, and there is no reason to doubt that 37signals measured something real. What it is not is evidence for rewriting your application. The measurement that would carry that weight is the same API shape on the same hardware with one variable changed, and nobody outside the company has it.

When a compiled backend is the right call

Four workloads justify the second language on their own, and none of them is "the app feels slow".

Sustained CPU work inside the request is the first: transcoding, parsing large payloads, compression, cryptography, anything you cannot push onto a queue or into the client. The second is connection count, where memory per connection is the ceiling rather than requests per second. The third is a latency budget measured in single digit milliseconds, where interpreter overhead is a fraction of the product rather than a fraction of a page load. The fourth is a binary you ship to somebody else's machine, where a runtime plus a lockfile of gems is not an option. 37signals has a fifth that most companies do not: it owns the machines, so CPU is a capital expense it controls.

The cost of taking that call is not the learning curve, which agents genuinely flatten. The cost is that a Rust backend has no scaffold. Choosing one means choosing a web framework, an async runtime, a query layer, a migration tool, a background job story and a cache, separately, and then deciding where files go. One concrete example of the sort of thing each of those decisions drags in: sqlx checks SQL against a live database at compile time, so a CI box with no database either has SQLX_OFFLINE=true set and a .sqlx directory committed from cargo sqlx prepare, or the build fails. That is a good feature with an operational tail, and there are a dozen more of them, and not one is a convention an agent can assume without being told. Conventions are the context is the same observation pointed at the framework that does have them.

The constraint on a CRUD product was never the runtime

A two person product whose core is forms over a database spends its request time somewhere specific, and the interpreter is rarely it. The time goes into Postgres, into an HTTP call to a payment provider or a mail provider, and into a browser parsing whatever the page shipped. A request that waits does not wait faster in Rust.

Take the position plainly: if you cannot name the resource your slowest endpoint is bound on, a language change is not a performance plan, it is a rewrite with a performance story attached to it. The profile comes first, and it usually names a query plan, a missing index, an N+1 or a third party that is having a bad afternoon.

The other half of the constraint is how many decisions a small team can afford to hold open. Rails 8.1 shipped in October 2025 and 8.1.3 in March 2026, according to the Rails release blog, and the Rails 8 defaults put Solid Queue, Solid Cache and Solid Cable on the database you already run. One Postgres covers background jobs, the cache and websockets. That is not a performance claim, it is a claim about how many moving parts one person is on call for, and it is the axis where the two stacks are furthest apart.

What changes when the agent writes the implementation

Cheap implementation moves the expense somewhere else, and where it moves is review, tests and the size of the blast radius when something is wrong. Read the Rust line as an engineering position rather than a joke and it says the same thing: a language is worth its cost when nobody has to read it, because review has moved up to behaviour, tests and the shape of the diff. That is a bet about review, not about throughput, and it is a bet that a team of thirty with a strong test culture can make and a solo founder mostly cannot. A language nobody on the team reads is a language where review is a formality, and a formality is what an agent's confident wrong answer slips through. Reviewing agent written Rails and testing what an agent wrote are the two halves of that problem on the Rails side.

The @rails account makes the argument from the other direction with its own positioning line: "Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write and beautiful for humans to review." Fewer tokens for the same feature is a real property of a framework with strong defaults, and it is measurable, which is why token efficient Rails is worth its own page rather than a paragraph.

What none of that establishes: nobody at 37signals said anything about buying a starter kit, and a page claiming the keynote endorses one would be lying to a reader who watched it. The most the news supports is narrower and still useful. If an agent writes the implementation, the scarce thing is a codebase it can work in without guessing, and conventions, tests and a known starting point are what that means.

The position, and exactly what would change it

Rails is still the answer for one or two people shipping a database backed CRUD product in 2026, and performance is not the reason. The reason is that every part of a feature has one obvious place to go, so an agent writing it is recalling a pattern rather than inventing a layout, and a reviewer reading it knows where to look. The Rust equivalent of that agreement does not exist yet. Axum plus sqlx is a convergence, not a convention, and a convergence generates nothing.

Three things would change the answer, and all three are checkable rather than vibes.

A published measurement showing agent written Rust passing tests and review at a higher rate than agent written Rails for the same feature set would change it, and nothing of the kind was findable while writing this. A convention layer over the Rust web stack that removes those six independent choices and generates a project everybody recognises would change it, because the argument above is about conventions and not about Ruby. And your own profile, showing application CPU at the top of the list at your actual traffic, would change it for you specifically, whatever it does for anybody else.

There is a risk on the Rails side to state rather than wave away. A widely shared post published the same week under the title "It's the end of Rails World as we know it (and I feel fine)" argues the framework as it was understood is finished and that major releases past 8.2 are unlikely. That is a prediction rather than a fact, and predictions about Rails have a poor record in both directions, but a stack choice made this month is a bet on a maintenance curve nobody can see. The question is live outside Rails too: José Valim published on evolving programming languages in the AI era the same week, and nobody here has read it closely enough to tell you what it argues.

What this page does not cover

No benchmark here. Running Rails against a Rust framework on hardware nobody else has would produce a number that flatters whichever one was tuned last, and the honest version of that work is a week and a reproducible harness.

Nor does it cover the rest of the shortlist. Go, Elixir and the JVM are all reasonable answers to "the runtime is genuinely my constraint", and the keynote made this a Rust conversation rather than a compiled backend conversation.

Nor whether agents write good Rust. The only large scale evidence is inside one company and has not shipped yet, and repeating a claim about it would be the thing this page has spent eight sections declining to do. The same question on the Rails side is answerable, because the code is in front of us: driving Claude Code through a Rails codebase is the page that takes it up.