- 86comments
- 38comments
- 22comments
- 1comments
- 362comments
- 13comments
- 5comments
- 94comments
- 118comments
- 212comments
- 55comments
- —discuss
- 37comments
- 373comments
- 606comments
- 154comments
- 24comments
- 29comments
- 382comments
- 140comments
- 407comments
- 18comments
- 56comments
- 47comments
- 23comments
- 12comments
- 128comments
- 665comments
- 22comments
- 4comments
From the talk it’s clear, Rails needs to be forked.
isn't https://mosscap.dev/ a fork?
So it seems this started because of DHH. Let's judge the technology by the technology, else we are just taking a holier-than-thou approach whereby we think we are better than others because we don't commit certain sins, which is a real problem because when we look inwardly and honestly we shall see that we are guilty of many of the same sins. Let's judge the technology for the technology itself and leave personal ideology out of it. My 2 cents (which will inevitably be downvoted)
I think one can just wait till DHH loses interest, can't be long now.
While I mostly agree with DHH's take on this particular technological cycle, this is a very well thought out criticism.
Rails, or even more so php have VERY little to bring to the table in 2026 going forward. Rails (ruby) is still a saner language than PHP, but as slow as php is. (granted ruby is not idiotic like PHP and runs rather than start/die).
If you go the LLM route something like Go is probably the goto default for MOST networking/web-first apps. You get static types, and a fast compile cycle (rust is still very slow here), and IF you want more from the language you can use something like Lisette (https://lisette.run/).
Bottom line is dynamic languages are obsolete. There is really no benefits from using them outside very small throw away scripts.
Well that's not something you say in a Rails conference, best language or framework for a project has been debated before I was born and will continue to be
Why would I bother with anything but Laravel for small CRUD apps? Not having to think about concurrency is neat, having tons of abstractions built by people with 50x my experience is neat, just being able to get going is neat.
Building the things I've built using Laravel with Golang would probably take 10x the development time as I have to handcraft everything Laravel already natively provides. Or I have to trust 100 packages from 100 different random devs to simulate the Laravel experience in Golang.
I would have been more interested if he'd spoken about improvements actually in the Ruby world.
There fast JITS like YJIT, ZJIT, JRuby and TruffleRuby.
We also have static typing with RBS and an AOT compiler in Spinel and we have embeddable Crystal.
The speed of TruflleRuby or Spinal with RBS isn't that far behind Go.
And here's a Ruby advantage for you, Ruby even with static typing needs fewer tokens from your context window to represent the same solution as verbose Go.
DHH's own pitch for HotWire was that it allowed a native experience without having to bow to Apple app store review process. Where's that gone?
There's lots of positive things that DHH could have spoken of but didn't.
The summary is exactly why a lot of people is upset.
I've seen this one a few times lately. People should stop building UIs, nobody wants to interact with a UI. Everyone's app should just be an API that you can use with a chatbot. Except for my app — my app is a handcrafted miracle of artisanal UX and its UI will change the way you see the world.
It's exactly the old argument, just now with LLMs in the place of shell pipelines: in terms of functionality and value to users, software ought to be malleable and composable. We've known it since the eighties. But the model of selling a piece of software as a product as if it were a pair of shoes is incompatible with that. You need a big monolithic application to justify users paying a bunch of money for it, and you need it to have a fancy interface that makes an impression. And the whole software industry is built on top of that model. Where monolithic software is completely unfit for a purpose, like when it needs to be a component of a larger system, we rely on (mostly unpaid) OSS.
Except now LLMs let you, with very little technical know-how, plaster a ‘programmable’ interface on top of unstructured data/interface meant for humans, and because that's what we actually want, of course everybody does that. So the end result is a wildly expensive pipeline from API to UI and back to API again. I wonder how long the legacy ‘human-oriented’ layer in the middle, and the industry that's been built on top of it, will last.
(Separately, chatbots are not great as a UI for most things, and the problem of building the universal UI still also stands. But it turns out for a lot of things people would rather have a bad universal UI than a good special-purpose UI for each task.)
Same happened when the first smartphones came out, and everything was about "mobile first". Everyone will use their mobile phones for everything, desktop is dead, every app should be primarily designed for smartphones, everything comes after. Turned out smartphones just another interface that are good for some things, and not good for some other. Same for the "cloud native" movement.
I see this sentiment a lot, but UI has a greater purpose than just serving the customer needs, it also be used to shape them.
Imagine if instead of going to the grocery store, you called a number and told them what you needed. Sometimes you don't know everything you need. Sometimes you end up discovering something new and buying it even if you didn't plan on it.
I don't think that is what everyone wants, or at the very least its not what I want. My ideal software has a well designed and thought through user interface for the primary interactions, allowing me to think about the goal I'm trying to achieve rather than how I'm manipulating the underlying data model.
Additionally to that please also provide access to the underlying data. Ideally in the form of a locally accessible API but I'll accept a remote one if necessary, provide a CLI on top of that as well if you like.
I think chat is a great entry point for many experiences. The approachability and flexibility are unmatched.
A question becomes, how do you evolve a chat experience to task specific actions?
I’m building an app to explore scripture. Chat is an amazing starting point. But it’s terrible once you get into reading the actual scripture.
I think we will see more of this in the future. Here is how I’ve envisioned evolving an experience out of chat. Curious if others have their own ideas.
https://trysojourn.app
If the UI is completely local and the chat is not, then I prefer UI.
Rails is dead.
Its founder has converted to AI driven Rust.
He has a point. Anything you could build in Rails you can now build in fast reliable type safe memory safe multithreaded Rust in minutes.
DHH will bring his tribe of true believers to where he has gone, where he has set up a new sideshow tent.
Do you follow the leader.
Is it Rails that you follow or is it DHH?
It is pretty obvious rails is dead as it hangs massively on its founder for good and for bad.
And it is quite telling that he prefers to kill it off like this rather than handing the reigns over to someone else.
A technical note - the big difference is that a design with a number of fat clients don’t need server side rendered html - that lowers the load on the server regardless of the programming language.
You can probably write quite light json apis in Ruby and the performance of them will be dominated by network and db usage anyways compared to a similar implementation done in a compiled language.
DHH's keynote was like listening to David Brent give a motivational speech.
"Some of you will loose your jobs. I know, I know. Gutting. Gutting. On a more positive note, I'm getting a promotion. So every cloud. Oh, you're still think about the bad stuff aren't you?"
You have to laugh about it because he's kind of making himself irrelevant too. We listened to him because of Rails not Hey or Basecamp. They were just application of Rails as a technology.
If he no longer has a vision for Rails' niche, what do we need him for? What's his pitch?
He might as well just be a Danish Barry Gibb impersonator that can't sing but instead drones on and on about politics. :P
The article forgets one thing, how DHH started his talk: he asked the audience how many people still codes by hand, and only 5 people raised their hands.
I was also waiting for some cool talk of some change, as I loved the simplificiation that Rails has done last year, but I also understand his point of view: he could either speed up the development of rails with AI (what Bun has done), or just say that it's mature and it doesn't matter anymore and it's better to not ruin a mature system.
That was something of a public speaking trick, though. “How many of you are STILL doing X” is never likely to get many people to put up their hands. The speaker is framing it as stupid and backward.
Every piece of software has an expiration date. You can extend its lifespan, but technology keeps moving. What was considered standard on the backend five years ago may look completely different today. I think that's a good thing. Rails worked extremely well for its time, especially around 2007–2015, but it started to show its age as newer, more capable languages and runtimes matured.
We should be celebrating the fact that we can now port almost anything with far less effort, or modernize an existing stack to meet today's performance expectations, requirements, and engineering standards.
Whats the expiration date on, say, the windows 95 version of paint? Because it still loads just fine on my current windows computer, does everything I'd expect from a paint program, and gets out of the way when I don't need it anymore
Honestly Rails being finished it's that bad. If you aren't writing the code by hand what benefit is it really bringing to you now?
Rails niche was fast setup/low starting out costs and relatively constrained/medium maintenance costs. To get this you traded performance and type system. The latter usually resulted in increased maintenance costs as test suites ballooned to compensate.
These days fast setup is simply a product of AI, every ecosystem now offers fast setup. Maintenance costs are now about how token efficient it is to find and fix problems. Test suites are going to be huge everywhere now but there is some chance languages that require less to accomplish more will win on token efficiency and be favored.
Humans aren't the dominant factor in programming language design or selection anymore, that is a fact at this point it just hasn't sunk in for everyone yet.
We are only ~6mo in to agents being good enough to write code. A year from now our profession will be entirely changed. Agents will get better (how much? don't know) but importantly they will definitely get cheaper and access will be broader. Which is really the point DHH was trying to make.
Access and economics are finally going to do what no-code failed to do, which is democratise software. Maybe not to the point that everyone writes code or even that shit programmers are good, but it will enable shit programmers to write Rust which was literally impossible 6mo ago and they will have better programs as a result.
Which is the other thing he touched on. Good programmers are going to excel here and great programmers are going to dominate. I'm already seeing the 10x programmers hit 100x and 1000x with more access doesn't seem out of sight. It's also restoring the will to create in a lot of people that lost the passion for the mechanical part of programming, unlocking the experience and skill of these people that were otherwise considering cashing in the bag is huge.
So yes. Rails is done but what is coming next is way more exciting. I'm with DHH here, be glad it happened but get moving on where things are going to be instead of clinging to the past.