I was hoping there will be news on Rails 9.0. Feels like this is the end of Ruby Rails.
Hey is not even a Ruby Rails App anymore. And indirectly admitting Ruby is slow considering they manage to cut 99.9% of CPU with their rewrite in Rust.
I hadn't connected the dots until you mentioned it, but yeah this keynote indirectly says it's the end of Ruby and Rails. Ruby was designed to be coded by humans, and DHH says it's the end of coding by hand.
Unfortunately yes because Rails has always been a framework of extraction. Now they are not even coding anymore there is nothing to extract. No one is a programmer but everyone is a maker.
I actually believe new frameworks and languages will pop up that are explicitly made to supercharge agentic engineering workflows. We're still super duper extra early! November last year was the START of all this. We're still in September! Not even one year has passed!
It doesn't make much sense to use a human language like Ruby and leave so much on the table when you can use a language like Rust or C to squeeze a LOT more out of correctness/types/performance.
Those performance numbers mean nothing considering they went from rendering every single view of a highly interactive app solely on their servers to moving all rendering to the clients. It’s possible the backend logic of the app could have run on 10 hosts running Ruby as well.
I agree it seems like the end of Ruby on Rails. I personally hope a fork will come along as a spiritual successor, because I still love building web apps this way.
I don't understand what is supposed to come next. So its not Ruby on Rails anymore. What is it? Are agents going to magically convert all the RoR ecosystem to Rust or Whatever?
But yes, I think RoR's selling feature was developer ergonomics, which suddenly seems less of a benefit if developers aren't the ones writing the code. Readability and conciseness still has benefit, but the trade-off of worse performance (and less static checking) is suddenly more questionable.
Shit, I'm also hosting with them. Somehow I missed that post. I've been watching Kurt's AI-pillness advancing over time, but I didn't expect it to metastasize so quickly.
What a strange time. Kurt himself writes that they've had the best quarter ever, and yet he feels confident enough to steer the ship in a completely new direction.
Readability and conciseness still has benefit, but the trade-off of worse performance (and less static checking) is suddenly more questionable.
There is an issue with this idea - we write software, we read it, we make sure it does what it should do, that it’s implement in a sensible and efficient way, and, most importantly, we make sure the tests do what they should do.
If you no longer write the code, it’s harder to understand it. If you don’t write the tests, you need to trust the LLM did both jobs correctly (multiple adversarial LLMs can help), but, ultimately, it’s code you can no longer claim you understand. And you can’t really be sure it does what you want until you understand it.
Write a solid piece of software by hand. Spend 20 plus years working all the bugs out and perfecting it. Build a giant community around it. Then use llms to rewrite it in another language, as the last step. Once that becomes unmaintainable, and there really is no community you can start over again by writing another working piece of software in a new language, perfecting it, building out a large community and then at the final step translate again with an llm, repeat.
Concerns with his politics aside, I do think there's a truth to what he's talking about here, and that he is just spelling out the reality that developers are, or shortly will be, facing. For many this will be deeply uncomfortable to hear.
It is notable that his perspective in this talk is very much from a developer-user side rather than someone who is responsible for the framework itself. That surprises me, and I suspect it is not a good omen for Rails.
For all of this embrace of agentic development, there is nothing here on how they are adapting the framework for this new agentic development reality. Agents do currently work well with Rails, but there's nothing here pushing things forward as best as I can see.
I know for my own projects I've largely moved to Elixir/Phoenix, for similar reasons to his use of Rust... I didn't want to have to learn it, but now I don't have to and I get to benefit from its strengths.
I literally just patched an AI-generated API endpoint on a new service at work that shipped without any auth whatsoever, because AI was re-implementing the auth token check method individually in each child controller instead of implementing once in a before_action hook. That's Rails 101 stuff and the app is small. It was so obvious that I saw it right away just reading the code, I didn't even set an agent loose to do an initial inspection. It was a real "yeah I still got it" moment for me.
I'm on board with the idea that agents are going to write most of the code, but not checking it is just insane to me, based on some of the things I've seen committed in commercial codebases recently.
One of the strengths of Rails was that it helped developers who maybe didn't always know the "best way" to build things to build in a standards compliant way – not that you couldn't do things like return a 200 for Not Found if you really wanted to etc.
I'm always pleased when working with a dev who has Rails experience even if they've since moved stack, as often they have picked up and learned the value of these good behaviours. Perhaps it's as much a community thing as a framework thing, or combination of both.
Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.
Interesting that all the patterns Rails adopted for humans to write better code can't easily be funneled into the LLM doing the job now. Seems like it should be.
I think the issue with Rails, as a long time developer in that ecosystem, is that much of the default assumptions are a) not common (not so far off-piste that a human can't get used to them, but outside the center of the bell curve), and b) not explicit. So it's very common to do things like install a plugin that has across-the-repo effects but that is only documented in e.g. the config directory and the bundle. Unlike, say, NPM, when you install a new package where you explicitly have to e.g. import it everywhere you want to use it.
As time has gone on Rails has gotten better about this, but it still means that "your rails" and "my rails" are different enough that AI could easily get confused.
As you say, the other aspect is the intense dynamism which works against AI, which again prefers to have everything explicit and reasonable about from the text.
So I ended up going back to Javascript after a brief 12 year digression into Ruby. I still love Ruby but it's just not the right language for the current environment and team structures - typescript is "worse is better" in the right ways that it's a much better choice for both frontend/backend being the same and better type systems.
Types are great. No nulls are great. Exhaustive switches are great. Derive macros and Serde are great. Detailed errors are great.
However Rust has one serious problem, BUILDS. It’s slow and it takes up a ton of space and memory. You will be working around this on any sizeable codebase. Using cargo check to ration your compiles, a dedicated build box, etc. Now imagine you're using it for a web application with compiled maud templates... you're potentially waiting minutes to see your changes.
If we accept that over half of the people building with rust are using agents (I'm sure this is much higher in reality), then you should also accept that there is a ton of time and resources spent on building / compiling. Optimizing this should probably be a top priority. They need someone who will be fanatical about shaving time and memory use from the build process.
Yeah. I'm going through an exercise right now with a large codebase where I'm split some of it up into crates so that iterating on specific parts incurs less build overhead. Literally changing my architecture... which annoyed me a bit, but it does make sense.
Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.
Maybe there will be one day, but what are the odds that it will meaningfully move the needle for existing platforms such that manual code review is unnecessary? "Blindly trust the output" is not a feasible security posture today.
I still review PRs, but rarely suggest changes. The most meaningful reviews come from our review bots. I mostly review broad architectural decisions as a way to keep abreast of changes in the codebase. There's a cohort of engineers I work with who I would be perfectly okay with letting the clankers review, approve, and merge their PRs. But there's a larger cohort of engineers who need what I would call a directional code review.
Agile is dead. It presumed writing the code was the slowest part of the cycle. Now it makes more sense to only start writing code when the requirements are known as the code is quick and low cost to change if/when the requirements change later.
That surprises me, and I suspect it is not a good omen for Rails.
I had a fairly opposite reaction: Knowing what you can't be and how much less important your past work is going to be is good. If there are good reasons for more people doing less in Rails, then the creator is probably the person you want to be most level headed about that.
I find it interesting to see the different dimming levels of comments in this thread. This person calling DHH a fascist and racist is undimmed while the previous much more mild (but implied right leaning) comment is almost disappeared.
I think a lot of people haven't actually watched his talk and don't understand what he is saying. If you watch the talk, he is not anti-rails. He is just very pro- agentic coding.
What he was saying in his talk was that his customers (people using Hey for email and calendar) never really wanted hybrid web-native apps, they want native apps (like most people prefer on mobile). His business could never afford to have a dev team that built and supported six different native apps, so they always built using hybrid web-native stuff using Turbo Native.
Now that his development team has access to agentic coding, they can build and maintain six mobile native apps. For his app, the back end part then becomes small and simple and they can reimplement it in rust to reduce server cost.
His point wasn't that rust is better than ruby, or anything like that. His point was that agentic coding allows smaller teams to do bigger things. For most people building on rails, their customers don't need native mobile apps (I know mine don't) and for them Rails is a fantastic choice for agentic coding.
Rails is so into agentic coding that they publish benchmarks of how effective different models are for building with rails:
TLDR: DHH isn't anti-rails, he is pro-agentic coding. Rails is great with agentic coding. AI doesn't mean layoffs, it means your teams can do much more than they could do before.
When I started as rails dev in 2013, it was really the top solution for producing MVP fast. Now, I don’t think that’s the case and most of the incentives are gone if we are no longer writing code by hand
It looks like he spent about 4 minutes out of the 1:03 making that point.
I can't but help think that he would have spent longer on it if that's what he really thought.
I don't think he believes in Rails any more.
It's clear that he was more excited about thing that are not ruby or rails and now considers rust better suited to the output of AI.
To be honest, I could see rust taking over from typescript/javascript as an output language for the web too. If no one needs to read source code any more why not use rust for everything?
Rails is so into agentic coding that they publish benchmarks of how effective different models are for building with rails
To each their own, but I think using Rails in the era of agents is probably a mistake. It has 2 big problems IMO.
(a) A ton of footguns that an agent can and will miss on occasion, and as we manually review less and less code, we will also miss it, and
(b) security on the web has become increasingly important due to hostile AI agents, and while rails has great secure conventions (see (a)), it's still easier to screw up something and not catch it until after it's deployed because there are simply less guardrails in place (dynamic types, no compile, slow tests, generally bad performance profile).
Rust is used a lot. Elixir/Phoenix comes up often. You’re looking for something statically typed with string guarantees and as FP as possible to make unit testing easier.
Rust for sure. Builds become a problem eventually though. Elixir is much more interesting now that they added types (I think they're doing more with this still?). I quite like Gleam from a human (non-agent) perspective.
In my experience, Go. It was designed to be idiot-proof. It's very verbose, not very expressive, compiles fast for quick feedback loops, strict autoformatter, plenty of examples in models' training data.
the only substantive difference I've noticed is between languages with a proof system and those without, where with a proof system is orders of magnitude better for agentic work.
Not sure if you’re speaking from experience or just being theoretical here. We’re using Rails and it’s been great. Maintenance and upgrades have been a breeze.
All this static vs dynamic stuff doesn’t really matter anymore. AI doesn’t care. You just need to close the feedback loop with tests, linting, a compiler, or whatever else gives it a clear signal.
Do the teams fully understand the code that they are committing? Are the teams reviewing each others code or are agents? When agents do all the coding, and perhaps the reviewing, and the patching what is left of the team? People lose connection to their work, and the social bonds between workers begins to erode.(1) DHH's speech seems like a weird eulogy for the entire Rails community, although many of us saw this coming several years ago.
Also, I hate native apps. FWIW most devs I know actively try to avoid them.
Most devs I know who hate native apps are either web devs trying to embed web tech into everything they touch, or they just hate Apple.
Most users don’t care. What they do care about is performance, and native is usually the easiest way to get there.
For your AI workflow questions, it depends. With or without AI, those decisions depend on the organisation’s direction, the team’s capabilities, and their preferences. Did your org have a single answer for the best programming language, framework, or workflow even before AI? There was never a single right answer to any of that.
I hate native apps. There are use cases better suited to native apps but often it's just not what I want.
You have little to no control over privacy, tracking or advertising compared to the web. That's left to the original developer and there's nothing you can do about it.
You can't do things like disable autoplaying videos. Often you can't even copy text without taking a screen shot. On a phone it's also much easier to zoom random parts of the screen in a browser compared to a native app.
There are legitimate reasons to prefer the web to native apps.
One of the things I admire most about Basecamp is that they are a bootstrapped, profitable business. There's no shame in running a business this way. The world would be more resilient if more business owners grew sustainably instead of soaking up endless invester funding and losing money year after year before enshittifying in a desperate attempt to repay their overlords.
His business could never afford to have a dev team that built and supported six different native apps
I have a hard time believing that, considering his hobby of racing cars and commissioning one-off hypercars. Unless it's that his business could never afford that dev team after DHH takes his salary.
as a solo: you can build and ship more in your own time
as a startup: you can iterate and scale more with more velocity and less growing pains
as an enterprise: people with ideas but not a technical background can put their tokens where their mouth is and build their own interfaces, personal apps, ask their own questions, ship their own features without having to navigate layer 8 and play games for resources
At least within my circle, that’s not really the case. Instead, what I’m seeing is more of a hiring freeze, with the budget being used to empower existing employees through AI. Which I think is a more reasonable take.
Why does it sound like layoffs? If you keep the team size the same and use the productivity increase to deliver more business value, how is that layoffs?
If I figure out a way to make my workers produce 10 times more widgets each, it doesn't automatically follow that there is a market for the extra 9 widgets. Otherwise I would have hired 9 extra workers before that invention to fulfill the market demand.
Making the widget cheaper doesn't necessarily create demand either. I will not buy 10 times more toothbrushes or writing pens if their prices suddenly decreased to 1 cent.
The demand for software or features will not increase at the speed of our ability to produce them.
TLDR: DHH isn't anti-rails, he is pro-agentic coding.
That's an opinion, not a summary though. The way how DHH behaved is really awkward in the last years. See the "let's shoot down wolves" blog entry here:
That DHH is into AI agents everywhere is easy to see, but if you go to rails-con, would you not expect this to be about rails as such, and people? Now it's about rust - and AI. Controlled by big corporations. Yikes - some people must be upset about having gone there to listen to DHH preaching about an agentic future.
Edit: I also watched parts of the recent youtube video about rails. I could not focus on the content because DHH's style was so strange. I've seen that style before - nothingburger talks. Look at phrases he used such as "I have retired from being a professional programmer/software engineer". This is all aimed to hype up "agentic coding is the future". Rails is dead - that video is all the proof one needs. DHH shifted gears to AI, and it is quite similar to when he first promoted rails. But now it is about AI, not rails.
It seems to me, so far, everyone moved one level up.
- A layperson can now build one a solo developer can do
- A solo dev can now build what an agency of web development can do
- An agency of web development can now build native apps similar to what large corporation can do
- Large corporation can now tackle even more ambitious projects
Which makes sense given what got automated. This is with the current tech, people still exploring the full potential, but if that turns out to be the case then I'd argue the software market will grow substantially and we are just having an adjustment period.
There is nothing wrong with designing like in the year 1999. But claiming improvements when all great websites like Amazon in 2004, the original GitHub, Google etc. were before AI is a bit weak.
He is just promoting Shopify's vibe coding for merchants. I bet on Shopify pivoting to vibe coded Rust soon because of "security".
But he himself promotes such a future too. This is a conflict of interest.
You can say "ride the wave", but this is more - this is helping the wave become huge. And cashing in too. Sorry, but I no longer buy any of what these guys do. To me they seem like BigBro ad-clowns.
Agents do currently work well with Rails
According to whom? And not everyone wants to become dependent on corporate-agents sucking them dry financially. We all know the increase-in-cost will come with regards to tokens, after the get-hook addiction phase is over.
Nothing that he said is just him espousing the truth. It is the world as he and all the other AI-pilled people wish it to be. It is a world they want to convince everyone is inevitable. There are still a lot of people outside of tech bubbles that don't like the direction AI is going and don't want to embrace what these companies are doing or how the government is handling it.
And honestly, do people really think everyone is just going to become an "energized creator"?
AI is not as big of a productivity boost as compilers were but it is not zero. Back then, SQL was created and marketed as something “managers could use”, another parallel to the current cycle. This whole hype cycle is something we’ve seen before and IMO, we should know better how to handle it this time around. It’s a bit disappointing to hear the same arguments every time.
This has nothing to do with programming or productivity. I am addressing the fact that people like DHH and his fans are in the habit of framing the future as written and that you can either embrace it or get crushed. Embracing it is giving OpenAI, Anthropic, et. al your approval to keep on going. I'm not denying that AI can do the job a lot faster.
Keeping the comparison to compilers, people in the 60s refusing the transition weren’t crushed, their skills were devalued. The open models work well enough at coding to keep up without buying OpenAI or Anthropic products.
Concerns with his politics aside, I do think there's a truth to what he's talking about here
One thing the AI era has changed for me is how easily I spot Gell-Mann amnesia, of which this is an unfortunately strong example.
His politics, even putting aside their nature, are framed with deliberate misuse of facts and data; why would he be someone to listen to in any depth on any other topic?
The Gell-Mann amnesia effect is a cognitive bias where a person spots major errors in a media report on a topic they know well, yet completely forgets that unreliability and trusts the rest of the same publication on unfamiliar topics.
Yes. I am broadening the definition of "media" and "publication", maybe, though it is posts on his own publishing platform and performances at his own breakaway conference.
But if someone misrepresents deliberately on a topic of polarising importance, why would you spend any time listening to them on any other topic?
I would (still) listen to him if I did not know he wrote stupid wrong things on other topics in bad faith.
Apparently somewhere between a third to a half of American scientists believe in some kind of god. Not to denegrate those who believe, but that's some kind of compartmentalization going on. Politics isn't any different. I dunno, I guess I don't have much issue listening to people with whom I disagree. Some people just get stuck on things. I do to, and maybe I'm the one that's wrong.
Gell-Mann amnesia assumes a journalist is not an expert on _anything_. In this case, DHH is (according to some) an expert on software but it's much less clear he's an expert on politics. So I'm not sure Gell-Mann amnesia applies here, it's maybe more like Nobel disease, where you're an expert on one thing and assume it "transfers" to other fields.
I have a background in sociology and urban planning. It's very clear that DHH is not an expert on politics. His blog posts demonstrate a very elementary understanding of the topics he covers. He doesn't even understand statistics.
Thank you for mentioning the effect by name. I read first about it 20 years ago, memorized it under a totally different name, and was never able to find it again.
Where did he say that? I listened to it yesterday and AFAIK he only said "I don't know where the line between native vs web will end up in the future" (now that we can generate native apps easier)
Keep in mind DHH is working on an email app, it makes sense he sees native as the default option for that over pushing everything through the web when the barrier to entry lowered dramatically.
Hotwire is not explicitly a cross-platform concept. It's primarily a way to build web apps in the browser which is not going away any time soon. The only difference is in 2026 you're just more likely to vibecode a native mobile app than build a web/React Native version. Likewise you may build a native Desktop version instead of an Electron wrapper.
The issue with native apps is that you have to convince people to install them. If I had one app for each tab I open in my browser my phone would be a mess and out of free space. Then you slow down the delivery of features and bug fixes because you have to go through the app stores. You can't deploy something every day or more often.
So even if we can generate an app easily now, is that a wise choice for every business?
Rendering HTML on the server was kind of how IBM mainframes talked to their 3270 terminals, only that HTML is a lot nicer than 3270 streams and HTTP is human readable.
Server side rendering makes sense for mostly static content, but for web applications, a front end framework and a back-end API are a much better match.
I sat front row for David's talk yesterday morning. Having talked with him the day before, I’ll admit… I wasn’t particularly surprised (nor unprepared).
A bit of a field report from #RailsWorld: the vibe here is far from doom and gloom. Quite the contrary. Wherever our industry is headed, most of us are still employed as menders… tending to systems that customers rely on and businesses are quite happy to keep paying for.
Most of us aren’t waking up to a blank canvas and designing the architecture of the future. We’re inheriting decisions made years ago, updating old patterns, working around constraints, and keeping this shit running reliably.
I think these newer tools give us an opportunity to wonder a little more about the systems we’ve inherited. To unpack why things work the way they do. To tinker with assumptions we haven’t had the time, confidence, or permission to revisit… and share what we learn so the next person, or agent, has an easier time.
That deployment model we picked eight years ago? Worth another look. Some of our web apps probably wish they were native apps. And there are plenty of architectural decisions we’ve been living with mostly because… well, we’ve been busy living with them.
There’s plenty of understandable anxiety about what these tools mean for our work. I’m increasingly curious about what they give us permission to revisit.
Once my keynote is published, I’ll share more about a little programming-language-adjacent framework I’ve been working on for approaching exactly this kind of curiosity.
To be fair, this is true of most of AFK world. Things start seeing a lot less doomy and gloomy when you're actually outside talking with other humans. Seems to mostly be online and various darker corners where they're dooming and glooming.
the algorithm is programmed to deliver it. Better engagement metrics with misery and anger than joy and hopefulness. (yes I know that you will reply 'but I prefer the joy and hope', but that's not the case across the wider population)
I get why DHH would be really happy about getting rid of engineers. It's less clear how this isn't a little bit gloomy for the engineers.
Is the idea that they'll switch to doing "product owner" roles overseeing agents? I don't see that employing the same number of people or paying as well as engineering used to.
To be honest I expect that that role to suit different people to those that used to be engineers.
If this feels gloomy to some people, it's because it is.
I don't think that hiring the engineers was ever an option. He said that he couldnt maintain six native apps before agentic coding. The business never even considered expanding headcount by 6X to do it, it was a complete nonstarter.
There is no fixed pie of work that AI is taking from us. In this circumstance, increased productivity caused the company to just make more stuff, not lay off people (or avoid planned hires).
How can Rails live long if no one creates new things with it? Our web applications aren't like the Pyramids at Giza. DHH literally said that even without a blank canvas (Hey's backend) they were still able to re-write the backend in Rust and are not looking back.
That sure sounds like any savvy business should pivot away from Rails and Ruby in general as fast as they can, assuming they have tokens to burn. Personally, I built my career on Python, but any new thing I build is almost always in Go or Rust. Why mess with an interpreter if you don't have to?
He clarified today, saying he would build any new app today in Rails. Should that app become so popular that it would benefit from Rust, he would rewrite it in Rust.
There is a world of difference of having tens of millions of dollars and paying hundreds of dollars a month for AI subscriptions vs someone making 100k / year doing the same.
For the DHH's of the world that's not even something to think about, but for most people who are working (even in tech), now we're talking 2-8%+ of your income depending how much you use AI. Just to have the "luxury" of being able to experiment with it. I use air quotes on luxury because I personally find a lot of AI results to be quite bad, but then again, I'm not spending hundreds of dollars a month on the premium models.
I’ve made a similar point to my colleagues recently about cross-platform vs native apps. If we’re using AI anyway, do the arguments we made years ago still hold today?
I know some people might disagree, mainly because AI isn’t a new architecture or a new programming language in the traditional sense. But I still think it’s worth revisiting the assumptions and having the discussion.
Depends a lot on the token budget I think, different situations for established businesses or strapped founders vs side hustles or hobbyists. So in a way you outgrow Rails or frameworks like it once you can afford a software factory on autopilot 24/7.
Serious question: Is there a framework that is better suited for agents? There must be something out there that makes agents fly through development with minimal token expense.
An agent that was looking at the log output from a program in a typical language, and also looking at the code for that program, would have a lot of unanswered questions related to "how do I iterate on this?" Maybe there's a kubernetes cluster involved somewhere. Maybe it there's a cloud storage bucket. Maybe there's dashboards and metrics and telemetry hosted by servers that the agent doesn't know the name of.
Elixir runs on the BEAM which lets you do hot code reloading process at a time. And these are much more lightweight than your typical OS process. So you can do things on the BEAM which would be just crazy to do on other achitectures. Like if you have a server which needs to support a million users, it would be insanity to run a million separate OS processes for the job. But BEAM processes are so lightweight that you can do that, which gives each one isolation from misbehavior of the others.
And since these support hot code reloading, without restarting the BEAM's OS process, you can patch the code for your user's sliver of the server and do a sort of "what-if" experiment. Other architectures would require you to implement separate test environments or complicated feature flag systems, but the beam lets you just reach out and change it for just the process you care about--you're not baking the experiment into an OSI image or anything so dangerous as that... blast radius is kept small.
And the steps for carrying out this experiment, it's all doable at the elixir shell. You connect to the BEAM and make changes. That's a tremendous reduction in context that an agent needs to load--context which would otherwise instruct the agent about how to reason about the deploy process and how to wall off your experiment from others so as to not cause problems with it is just answered implicitly by how the BEAM works.
Elixir compiles to BEAM bytecode, so you get all of this because the BEAM is cool. As for Elixir as a language... I don't think there's anything agent-specific about it. Gleam might be a better choice since it's statically typed and also compiles to BEAM bytecode except that it's not as popular as Elixir, which is probably more important.
You can also do all of this in the language that started it all: Erlang (Java : JVM :: Erlang : BEAM) but it's not exactly fashionable at present (similar to java vs like... kotlin or clojure or something).
Disclaimer: I'm more of a fan than a seasoned pro. I'd love to actually be working with this stuff daily, but my team wouldn't have it because they prefer familiar things and pain.
I maintain Elixir and Rails applications. In my opinion, almost all LLMs handle Elixir better. I suspect, though do not know, being an immutable functional language and composing applications in a functional style makes it easier for the models to "reason" about the code and state. I learned very quickly that this is my preferred language for that very reason.
Additionally, the features available in the BEAM and OTP mean the agents have built-in tools for many things that would require reaching for 3rd-party libraries or even additional services. This means less variability in design as the models will happily use all the language features human developers would have to learn about and understand over time to use effectively. Not that this isn't important, but I believe models do a better job steering you to obvious and optimal solutions with Elixir.
The new type system is only going to make it better.
Yep I find Elixir very enjoyable with agents at the moment, I've been developing a lot in it. It helps that I already liked the language and the platform, and now I just have the ability to build out my ideas faster.
I think they're good at it for a variety of reasons, but it likely helps having a smaller and newer community than many languages, meaning less out of date guff clogging up the LLM sources.
Worry not, for I am using Claude right now. I would never question the doctrine of AI usefulness and productivity. Please scrap that J'accuse draft, sir, for I would never commit blasphemy against AI, I promise.
It's still early days, I'm hesitant to claim the death of software engineering. It's good now because LLMs were all trained on actual human output. One possible future is a slop death spiral.
I sure as hell am never again releasing human-authored open-source in a way that can be scraped. My Github is now relegated to the lowest quality slop from the cheapest models.
So far a Rust rewrite's success rate directly, probably super linearly, correlates with the presence of a good, well designed test suite. This is why Bun's rewrite and others are successful. I anticipate that this will be true for the 37Signals rewrites.
I want to learn a couple of things once they are done:
1. Once the test suite assistance is over, how do features get built in their backends and continue to maintain the same quality. LLM test writing is a bit trickier as it often favors what Randy Coulman called tautological tests back in the day. It takes a lot of work to get them not to do this, so I am guessing folks at 37Signals will read at least this part. I can't imagine zero Rust read at all.
2. Over the years they had a few innovations in their domain design, ones that Rails made easier to do, for instance their delegated type pattern. Will Rust replicate this, and how would one know without reading it, or perhaps it does not matter? Furthermore, how do newer patterns emerge? and how does our arsenal of better abstractions keep growing?
I don't have the answers but I am glad there is a chance we can learn said answers.
I really enjoyed DHH's keynote speech using his own family lineage story via the art history intertwined with technology evolution portrait paintings -> photography pictures as analogy of what's happening right now in the technology landscapes.
He may be racist but what a great orator! (Who else does that apply to?) Can't really disagree with him about the AI stuff either. I mean maybe it's a bit premature but if it isn't true now it will be in 5-10 years.
I guess the death of Ruby is a silver lining to AI at least.
So the keynote mentions that in a perspective you are going to be a "maker of things" rather than a coder. But, nobody is asking, in a perspective, why would anybody use the stuff you "make" rather than using AI directly? All of the notion of apps disappears, in a perspective.
Because it does take some skills, judgement, taste, knowledge, time and effort to build things. He said it is not very different from directing a team of contractors, and also said that a 10x dev in now 1000x with a tool like this. He also gave the parallel of photography to address this point, that people were forced to be more creative and adapt.
But I assume you didn't use to build anything substantial.
Business people I work with tend to have all kind of ideas in different places, I cannot count all the Trello boards they have abandoned. Users are usually lazy and don't want to fill in data properly, well yeah chatbox with llm is cool interface, but you still have to enforce structure for data so it is useful.
With AI problem is still there "garbage in, garbage out", models are not going to imagine correct data to fill in blanks, in the end if you need someones birthday, someone has to type it in.
Web app I am working on is organised only because we get engineers and quality assurance and we get paid for maintaining application. Data is structured and we can deliver insights because the application enforces structure.
There are far more requirements than AI can deliver on its own.
I have a "cooking notebook" of recipes, cooking techniques and notes, that over the past ~15 years or so I've migrated from Evernote to Notion and most recently to Bear. I've built this all up over time, and don't really want to just ask ChatGPT instead.
I have a pretty solid idea what the 'perfect' custom app for this would look like for me at this point. I've toyed with the idea of vibe coding it, but I simply don't have the time to get it built, test it out, and refine it to the point where it'd meet the vision of what I want.
Bear isn't exactly what I want but it's close enough right now to warrant using it and paying for it. And it seems to have a decent team behind that's going to spend time continuing to build and improve it so I don't have to.
I think the perf jump from Ruby to Rust is much greater than .NET Core to Rust. Not much will change in .NET land for the foreseeable future. I see this migration happening from Ruby and others so it is not surprising from that aspect.
Also - what he is talking about was true for well over a year. It is just that a lot of day-to-day gaps between prompt and output were closed in the meantime. In a sense, Ruby on Rails/37 Signals is a late adopter.
Haven't watched the video, but I've been spending a few hours the past week re-acquainting myself with Ruby before diving back into rails introductions.
Ruby is an interesting language to work with. I don't know it like Python, but it's a language that finds problems developers would run into and built solutions in to make it easier.
As for Rails, as a total novice: It is a lot of Convention over Configuration, and it's almost a second language on top of Ruby. Everything works together implicitly so you have to recognize what's happening when you look at the code. I don't know if any Ruby/Rails oriented IDEs exist that guide the developer with hints and shortcuts to how the pieces of a Rails app fit together, but it sure would be handy.
I can see how typed, high-performance languages with explicit references to all the integrations would be easier for AI to handle. But as long as humans sometimes have to look at the code, I would think Rails still has a place.
weird talk; is not reading any code _at all_ is the new standard now? I do happily ai-slop side projects here and there but seems like just going full steam ahead _at work_ is ok? sorry, I meant - is the future now? xd
How a developer oriented conference can give one minute of screen time to a by now fully open, mask off, racist / fascist is beyond me. Does the Rails world don't know, or don't care?
Edit: it's his conference because the actual Rails conf banned him. Sad victory I guess.
Okay, I'll bite. What did he do that's racist and fascist. And please provide receipts.
For reference, here are the definitions:
racist: a person who believes that a particular race is superior to others, or who discriminates against other races
fascism: any right-wing, authoritarian, nationalist ideology characterized by centralized, totalitarian governance, strong regimentation of the economy and society, and repression of criticism or opposition
A lot has been said about DHH, but, I think the moment where you can see that the guy has _clearly_ lost it is this quote:
It is impossibly fast. And you know what? The binary? Half a megabyte. Half a fucking megabyte. I— you could fit that on a floppy disk almost. With a little compression. This is the other payoff.
The guy now(?) thinks like a lossy abstraction that speaks in tropes.
He has become the LLM - I would say, if I didn't know that even a 9B one can tell me with absolutely certainty how much space there is on a fucking floppy.
There is no reason to get into all the politics stuff when this is where the guy is at. Basic fact retrieval.
(Pedantically, one could now argue that it was not clear which floppy format the guy was referring to. And yes, that would be true, but by thinking that thought, you have thought about the sentence more than its author has.)
He is a provocateur, many things to ponder. Rust fans are jumping up and down that the backend is going to be in Rust. That's not what he saying though, his rewrite snapshot had a bunch of languages with Shell being 26%, Python 13% and Rust 7%, in the previous version Ruby was 55%. His comment on Rust was "I love Rust! Rust is amazing ...if you never, ever, EVER have to look at it yourself." It's going to be interesting to see where this lands in one year when a bunch of projects have been rewritten by Agents in Rust and our Rust Hero shows up and has to maintain that code. Seems like a Zen kaon to me - if you don't read, write or have to understand Rust but the Agent does, is your program safe or performant. Your intuition of what safety is or performance no longer comes from looking at the source code but something else and in the next turn your entire Rust code base could get optimized to some IR or assembler that you no longer can even understand!
I was hoping there will be news on Rails 9.0. Feels like this is the end of Ruby Rails.
Hey is not even a Ruby Rails App anymore. And indirectly admitting Ruby is slow considering they manage to cut 99.9% of CPU with their rewrite in Rust.
Agents might pick up Topcoat (inspired by Rails) as the framework for those Rust apps.
I hadn't connected the dots until you mentioned it, but yeah this keynote indirectly says it's the end of Ruby and Rails. Ruby was designed to be coded by humans, and DHH says it's the end of coding by hand.
it is sorta sad that framework development will dry up with fewer incentives.
Unfortunately yes because Rails has always been a framework of extraction. Now they are not even coding anymore there is nothing to extract. No one is a programmer but everyone is a maker.
I actually believe new frameworks and languages will pop up that are explicitly made to supercharge agentic engineering workflows. We're still super duper extra early! November last year was the START of all this. We're still in September! Not even one year has passed!
Where will we be in 5 years?
Examples:
https://dioxuslabs.com/
https://lean-lang.org/
It doesn't make much sense to use a human language like Ruby and leave so much on the table when you can use a language like Rust or C to squeeze a LOT more out of correctness/types/performance.
This is my first attempt at a AI framework and I'm pretty happy with it
https://pricklypear.rocks/
Those performance numbers mean nothing considering they went from rendering every single view of a highly interactive app solely on their servers to moving all rendering to the clients. It’s possible the backend logic of the app could have run on 10 hosts running Ruby as well.
I agree it seems like the end of Ruby on Rails. I personally hope a fork will come along as a spiritual successor, because I still love building web apps this way.
I don't understand what is supposed to come next. So its not Ruby on Rails anymore. What is it? Are agents going to magically convert all the RoR ecosystem to Rust or Whatever?
Translation does play to their strengths.
But yes, I think RoR's selling feature was developer ergonomics, which suddenly seems less of a benefit if developers aren't the ones writing the code. Readability and conciseness still has benefit, but the trade-off of worse performance (and less static checking) is suddenly more questionable.
Have a look at fly.io facing similar issues, another platform whose value prop was dev ergonomics: https://fly.io/blog/kurt-scott-money-sprites/
Shit, I'm also hosting with them. Somehow I missed that post. I've been watching Kurt's AI-pillness advancing over time, but I didn't expect it to metastasize so quickly.
What a strange time. Kurt himself writes that they've had the best quarter ever, and yet he feels confident enough to steer the ship in a completely new direction.
If you don’t build the product that’ll kill your cash cow, your competitors will.
There is an issue with this idea - we write software, we read it, we make sure it does what it should do, that it’s implement in a sensible and efficient way, and, most importantly, we make sure the tests do what they should do.
If you no longer write the code, it’s harder to understand it. If you don’t write the tests, you need to trust the LLM did both jobs correctly (multiple adversarial LLMs can help), but, ultimately, it’s code you can no longer claim you understand. And you can’t really be sure it does what you want until you understand it.
Write a solid piece of software by hand. Spend 20 plus years working all the bugs out and perfecting it. Build a giant community around it. Then use llms to rewrite it in another language, as the last step. Once that becomes unmaintainable, and there really is no community you can start over again by writing another working piece of software in a new language, perfecting it, building out a large community and then at the final step translate again with an llm, repeat.
Concerns with his politics aside, I do think there's a truth to what he's talking about here, and that he is just spelling out the reality that developers are, or shortly will be, facing. For many this will be deeply uncomfortable to hear.
It is notable that his perspective in this talk is very much from a developer-user side rather than someone who is responsible for the framework itself. That surprises me, and I suspect it is not a good omen for Rails.
For all of this embrace of agentic development, there is nothing here on how they are adapting the framework for this new agentic development reality. Agents do currently work well with Rails, but there's nothing here pushing things forward as best as I can see.
I know for my own projects I've largely moved to Elixir/Phoenix, for similar reasons to his use of Rust... I didn't want to have to learn it, but now I don't have to and I get to benefit from its strengths.
I literally just patched an AI-generated API endpoint on a new service at work that shipped without any auth whatsoever, because AI was re-implementing the auth token check method individually in each child controller instead of implementing once in a before_action hook. That's Rails 101 stuff and the app is small. It was so obvious that I saw it right away just reading the code, I didn't even set an agent loose to do an initial inspection. It was a real "yeah I still got it" moment for me.
I'm on board with the idea that agents are going to write most of the code, but not checking it is just insane to me, based on some of the things I've seen committed in commercial codebases recently.
One of the strengths of Rails was that it helped developers who maybe didn't always know the "best way" to build things to build in a standards compliant way – not that you couldn't do things like return a 200 for Not Found if you really wanted to etc.
I'm always pleased when working with a dev who has Rails experience even if they've since moved stack, as often they have picked up and learned the value of these good behaviours. Perhaps it's as much a community thing as a framework thing, or combination of both.
Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.
Interesting that all the patterns Rails adopted for humans to write better code can't easily be funneled into the LLM doing the job now. Seems like it should be.
Is it types? Are types the answer? Is it rust?
I think the issue with Rails, as a long time developer in that ecosystem, is that much of the default assumptions are a) not common (not so far off-piste that a human can't get used to them, but outside the center of the bell curve), and b) not explicit. So it's very common to do things like install a plugin that has across-the-repo effects but that is only documented in e.g. the config directory and the bundle. Unlike, say, NPM, when you install a new package where you explicitly have to e.g. import it everywhere you want to use it.
As time has gone on Rails has gotten better about this, but it still means that "your rails" and "my rails" are different enough that AI could easily get confused.
As you say, the other aspect is the intense dynamism which works against AI, which again prefers to have everything explicit and reasonable about from the text.
So I ended up going back to Javascript after a brief 12 year digression into Ruby. I still love Ruby but it's just not the right language for the current environment and team structures - typescript is "worse is better" in the right ways that it's a much better choice for both frontend/backend being the same and better type systems.
Types are great. No nulls are great. Exhaustive switches are great. Derive macros and Serde are great. Detailed errors are great.
However Rust has one serious problem, BUILDS. It’s slow and it takes up a ton of space and memory. You will be working around this on any sizeable codebase. Using cargo check to ration your compiles, a dedicated build box, etc. Now imagine you're using it for a web application with compiled maud templates... you're potentially waiting minutes to see your changes.
If we accept that over half of the people building with rust are using agents (I'm sure this is much higher in reality), then you should also accept that there is a ton of time and resources spent on building / compiling. Optimizing this should probably be a top priority. They need someone who will be fanatical about shaving time and memory use from the build process.
Sounds like I should check in on rust in a year or so.
Yeah. I'm going through an exercise right now with a large codebase where I'm split some of it up into crates so that iterating on specific parts incurs less build overhead. Literally changing my architecture... which annoyed me a bit, but it does make sense.
Maybe there will be one day, but what are the odds that it will meaningfully move the needle for existing platforms such that manual code review is unnecessary? "Blindly trust the output" is not a feasible security posture today.
I still review PRs, but rarely suggest changes. The most meaningful reviews come from our review bots. I mostly review broad architectural decisions as a way to keep abreast of changes in the codebase. There's a cohort of engineers I work with who I would be perfectly okay with letting the clankers review, approve, and merge their PRs. But there's a larger cohort of engineers who need what I would call a directional code review.
What model though?
Software engineering is so back.
When designing systems, you want the important details to be right. Especially with authentication and authorization.
From an architecture level, you can know which classes are important to review and which ones are not.
Yeah that is how I see it.
In Software Engineering, we learned about requirements, testings, system design, UMLs, etc, and those seems to be more relevant than ever.
Agile is dead. It presumed writing the code was the slowest part of the cycle. Now it makes more sense to only start writing code when the requirements are known as the code is quick and low cost to change if/when the requirements change later.
Why do you think an AI audit (say from Fable/Astra at xhigh) wouldn't have caught this?
I had a fairly opposite reaction: Knowing what you can't be and how much less important your past work is going to be is good. If there are good reasons for more people doing less in Rails, then the creator is probably the person you want to be most level headed about that.
(They can, of course, still be wrong)
By "concerns" did you mean to say "I don't agree with some of his political opinions".
Yeah, because being a fascist and racist is not concerning at all.
cringe
It seems the new definition of fascism is any political opinion that isn't hard left.
I find it interesting to see the different dimming levels of comments in this thread. This person calling DHH a fascist and racist is undimmed while the previous much more mild (but implied right leaning) comment is almost disappeared.
.·°՞( ̑ ᗜ ̑ )՞°·.
i'm missing out on backstory gossip evidently: what's this fascist and racist accusation ?
https://world.hey.com/dhh/wolves-sheep-and-gypsies-ba44af6a
https://world.hey.com/dhh/as-i-remember-london-e7d38e64
I think a lot of people haven't actually watched his talk and don't understand what he is saying. If you watch the talk, he is not anti-rails. He is just very pro- agentic coding.
What he was saying in his talk was that his customers (people using Hey for email and calendar) never really wanted hybrid web-native apps, they want native apps (like most people prefer on mobile). His business could never afford to have a dev team that built and supported six different native apps, so they always built using hybrid web-native stuff using Turbo Native.
Now that his development team has access to agentic coding, they can build and maintain six mobile native apps. For his app, the back end part then becomes small and simple and they can reimplement it in rust to reduce server cost.
His point wasn't that rust is better than ruby, or anything like that. His point was that agentic coding allows smaller teams to do bigger things. For most people building on rails, their customers don't need native mobile apps (I know mine don't) and for them Rails is a fantastic choice for agentic coding.
Rails is so into agentic coding that they publish benchmarks of how effective different models are for building with rails:
https://rubyonrails.org/ai
TLDR: DHH isn't anti-rails, he is pro-agentic coding. Rails is great with agentic coding. AI doesn't mean layoffs, it means your teams can do much more than they could do before.
He explicitly said he still loves ruby as a language and thinks Rails is well suited for a future with AI coding.
It's interesting how this stuff gets spun on social media by people who don't watch the content.
It doesn't matter if Rails is well suited for AI or not. Now, there's less incentive and reasons to use it.
When I started as rails dev in 2013, it was really the top solution for producing MVP fast. Now, I don’t think that’s the case and most of the incentives are gone if we are no longer writing code by hand
It looks like he spent about 4 minutes out of the 1:03 making that point.
I can't but help think that he would have spent longer on it if that's what he really thought.
I don't think he believes in Rails any more.
It's clear that he was more excited about thing that are not ruby or rails and now considers rust better suited to the output of AI.
To be honest, I could see rust taking over from typescript/javascript as an output language for the web too. If no one needs to read source code any more why not use rust for everything?
To each their own, but I think using Rails in the era of agents is probably a mistake. It has 2 big problems IMO.
(a) A ton of footguns that an agent can and will miss on occasion, and as we manually review less and less code, we will also miss it, and
(b) security on the web has become increasingly important due to hostile AI agents, and while rails has great secure conventions (see (a)), it's still easier to screw up something and not catch it until after it's deployed because there are simply less guardrails in place (dynamic types, no compile, slow tests, generally bad performance profile).
What languages are best suited for development with agentic coding?
Rust is used a lot. Elixir/Phoenix comes up often. You’re looking for something statically typed with string guarantees and as FP as possible to make unit testing easier.
Rust for sure. Builds become a problem eventually though. Elixir is much more interesting now that they added types (I think they're doing more with this still?). I quite like Gleam from a human (non-agent) perspective.
I've been using Rust more and more for specific tasks in my Elixir saas app, the two play really well together.
In my experience, Go. It was designed to be idiot-proof. It's very verbose, not very expressive, compiles fast for quick feedback loops, strict autoformatter, plenty of examples in models' training data.
the only substantive difference I've noticed is between languages with a proof system and those without, where with a proof system is orders of magnitude better for agentic work.
OCaml.
Not sure if you’re speaking from experience or just being theoretical here. We’re using Rails and it’s been great. Maintenance and upgrades have been a breeze.
All this static vs dynamic stuff doesn’t really matter anymore. AI doesn’t care. You just need to close the feedback loop with tests, linting, a compiler, or whatever else gives it a clear signal.
Simple as that.
If it doesn't matter I will just pick the cheapest to run (the static ones).
Do the teams fully understand the code that they are committing? Are the teams reviewing each others code or are agents? When agents do all the coding, and perhaps the reviewing, and the patching what is left of the team? People lose connection to their work, and the social bonds between workers begins to erode.(1) DHH's speech seems like a weird eulogy for the entire Rails community, although many of us saw this coming several years ago.
Also, I hate native apps. FWIW most devs I know actively try to avoid them.
(1) https://www.uclawjournal.org/how-ai-destroys-institutions/
Most devs I know who hate native apps are either web devs trying to embed web tech into everything they touch, or they just hate Apple.
Most users don’t care. What they do care about is performance, and native is usually the easiest way to get there.
For your AI workflow questions, it depends. With or without AI, those decisions depend on the organisation’s direction, the team’s capabilities, and their preferences. Did your org have a single answer for the best programming language, framework, or workflow even before AI? There was never a single right answer to any of that.
I hate native apps. There are use cases better suited to native apps but often it's just not what I want.
You have little to no control over privacy, tracking or advertising compared to the web. That's left to the original developer and there's nothing you can do about it.
You can't do things like disable autoplaying videos. Often you can't even copy text without taking a screen shot. On a phone it's also much easier to zoom random parts of the screen in a browser compared to a native app.
There are legitimate reasons to prefer the web to native apps.
It’s his business decision to save on native app development costs to increase his (generous?) profit margins.
One of the things I admire most about Basecamp is that they are a bootstrapped, profitable business. There's no shame in running a business this way. The world would be more resilient if more business owners grew sustainably instead of soaking up endless invester funding and losing money year after year before enshittifying in a desperate attempt to repay their overlords.
I have a hard time believing that, considering his hobby of racing cars and commissioning one-off hypercars. Unless it's that his business could never afford that dev team after DHH takes his salary.
That sounds like layoffs lol.
it sounds like leverage
as a solo: you can build and ship more in your own time
as a startup: you can iterate and scale more with more velocity and less growing pains
as an enterprise: people with ideas but not a technical background can put their tokens where their mouth is and build their own interfaces, personal apps, ask their own questions, ship their own features without having to navigate layer 8 and play games for resources
At least within my circle, that’s not really the case. Instead, what I’m seeing is more of a hiring freeze, with the budget being used to empower existing employees through AI. Which I think is a more reasonable take.
Why does it sound like layoffs? If you keep the team size the same and use the productivity increase to deliver more business value, how is that layoffs?
If I figure out a way to make my workers produce 10 times more widgets each, it doesn't automatically follow that there is a market for the extra 9 widgets. Otherwise I would have hired 9 extra workers before that invention to fulfill the market demand.
Making the widget cheaper doesn't necessarily create demand either. I will not buy 10 times more toothbrushes or writing pens if their prices suddenly decreased to 1 cent.
The demand for software or features will not increase at the speed of our ability to produce them.
That's an opinion, not a summary though. The way how DHH behaved is really awkward in the last years. See the "let's shoot down wolves" blog entry here:
https://world.hey.com/dhh/wolves-sheep-and-gypsies-ba44af6a
That DHH is into AI agents everywhere is easy to see, but if you go to rails-con, would you not expect this to be about rails as such, and people? Now it's about rust - and AI. Controlled by big corporations. Yikes - some people must be upset about having gone there to listen to DHH preaching about an agentic future.
Edit: I also watched parts of the recent youtube video about rails. I could not focus on the content because DHH's style was so strange. I've seen that style before - nothingburger talks. Look at phrases he used such as "I have retired from being a professional programmer/software engineer". This is all aimed to hype up "agentic coding is the future". Rails is dead - that video is all the proof one needs. DHH shifted gears to AI, and it is quite similar to when he first promoted rails. But now it is about AI, not rails.
It seems to me, so far, everyone moved one level up.
- A layperson can now build one a solo developer can do
- A solo dev can now build what an agency of web development can do
- An agency of web development can now build native apps similar to what large corporation can do
- Large corporation can now tackle even more ambitious projects
Which makes sense given what got automated. This is with the current tech, people still exploring the full potential, but if that turns out to be the case then I'd argue the software market will grow substantially and we are just having an adjustment period.
And the results are 1999 websites like hey.com?
What is wrong with the website?
Have you seen the older apps built by devs? or all the other bootstrap themes?
There is nothing wrong with designing like in the year 1999. But claiming improvements when all great websites like Amazon in 2004, the original GitHub, Google etc. were before AI is a bit weak.
He is just promoting Shopify's vibe coding for merchants. I bet on Shopify pivoting to vibe coded Rust soon because of "security".
He's not anti-rails. He just won't be using it.
But he himself promotes such a future too. This is a conflict of interest.
You can say "ride the wave", but this is more - this is helping the wave become huge. And cashing in too. Sorry, but I no longer buy any of what these guys do. To me they seem like BigBro ad-clowns.
According to whom? And not everyone wants to become dependent on corporate-agents sucking them dry financially. We all know the increase-in-cost will come with regards to tokens, after the get-hook addiction phase is over.
Or you know just use one of the many great open models. The LLM wave can be taken just fine without "corporate-agents suck them dry".
Nothing that he said is just him espousing the truth. It is the world as he and all the other AI-pilled people wish it to be. It is a world they want to convince everyone is inevitable. There are still a lot of people outside of tech bubbles that don't like the direction AI is going and don't want to embrace what these companies are doing or how the government is handling it.
And honestly, do people really think everyone is just going to become an "energized creator"?
i have nothing else to say to you other than good luck
AI is not as big of a productivity boost as compilers were but it is not zero. Back then, SQL was created and marketed as something “managers could use”, another parallel to the current cycle. This whole hype cycle is something we’ve seen before and IMO, we should know better how to handle it this time around. It’s a bit disappointing to hear the same arguments every time.
This has nothing to do with programming or productivity. I am addressing the fact that people like DHH and his fans are in the habit of framing the future as written and that you can either embrace it or get crushed. Embracing it is giving OpenAI, Anthropic, et. al your approval to keep on going. I'm not denying that AI can do the job a lot faster.
Keeping the comparison to compilers, people in the 60s refusing the transition weren’t crushed, their skills were devalued. The open models work well enough at coding to keep up without buying OpenAI or Anthropic products.
One thing the AI era has changed for me is how easily I spot Gell-Mann amnesia, of which this is an unfortunately strong example.
His politics, even putting aside their nature, are framed with deliberate misuse of facts and data; why would he be someone to listen to in any depth on any other topic?
Yes. I am broadening the definition of "media" and "publication", maybe, though it is posts on his own publishing platform and performances at his own breakaway conference.
But if someone misrepresents deliberately on a topic of polarising importance, why would you spend any time listening to them on any other topic?
I would (still) listen to him if I did not know he wrote stupid wrong things on other topics in bad faith.
Apparently somewhere between a third to a half of American scientists believe in some kind of god. Not to denegrate those who believe, but that's some kind of compartmentalization going on. Politics isn't any different. I dunno, I guess I don't have much issue listening to people with whom I disagree. Some people just get stuck on things. I do to, and maybe I'm the one that's wrong.
One thing the AI era has changed for me is how easily I spot Gell-Mann amnesia, of which this is an unfortunately strong example.
The one for me is spotting the Baader-Meinhof effect, of which this is an unfortunately strong example.
Touché. I mean it has almost the same meter. I get that you're disagreeing with me, but have my compensatory upvote.
Gell-Mann amnesia assumes a journalist is not an expert on _anything_. In this case, DHH is (according to some) an expert on software but it's much less clear he's an expert on politics. So I'm not sure Gell-Mann amnesia applies here, it's maybe more like Nobel disease, where you're an expert on one thing and assume it "transfers" to other fields.
I have a background in sociology and urban planning. It's very clear that DHH is not an expert on politics. His blog posts demonstrate a very elementary understanding of the topics he covers. He doesn't even understand statistics.
Ha. I was trying to be charitable there :)
Thank you for mentioning the effect by name. I read first about it 20 years ago, memorized it under a totally different name, and was never able to find it again.
I am slightly abusing/overstretching the concept, to be fair; other commenters are not wrong to remark as such. But still.
Any specific examples? I am/was out of the loop on this and had to Google "DHH politics" to know what people are talking about.
DHH is "off the Rails" is not false now?
This link says ‘This video is private’ to me, here’s a working one https://youtu.be/vDjW_dRyKXY
Thanks! We've changed the url to that from https://www.youtube.com/watch?v=V9SxpJpHuus.
Adieu, Ruby on Rails.
it's funeral of Ruby on Rails
It’s now Rust on Rails.
it became culturally irrelevant around rails 5
tldr:
dhh says 37signal's apps for Hey (their email platform moving to native)
backend for their email platform is now Rust - written by agents
says Rust produces small binaries - cutting number of servers needed from 110 to 10. hell they could serve peak traffic on a Raspberry Pi
says now that agents write all the code - use faster / native languages.
rails or ruby hardly get a mention besides that they might be well placed to capture web apps written by agents.
also worth noting that hotwire is dead according to DHH in this talk. The rendering html server side is old way now
Where did he say that? I listened to it yesterday and AFAIK he only said "I don't know where the line between native vs web will end up in the future" (now that we can generate native apps easier)
Keep in mind DHH is working on an email app, it makes sense he sees native as the default option for that over pushing everything through the web when the barrier to entry lowered dramatically.
Hotwire is not explicitly a cross-platform concept. It's primarily a way to build web apps in the browser which is not going away any time soon. The only difference is in 2026 you're just more likely to vibecode a native mobile app than build a web/React Native version. Likewise you may build a native Desktop version instead of an Electron wrapper.
The issue with native apps is that you have to convince people to install them. If I had one app for each tab I open in my browser my phone would be a mess and out of free space. Then you slow down the delivery of features and bug fixes because you have to go through the app stores. You can't deploy something every day or more often.
So even if we can generate an app easily now, is that a wise choice for every business?
Rendering HTML on the server was kind of how IBM mainframes talked to their 3270 terminals, only that HTML is a lot nicer than 3270 streams and HTTP is human readable.
Server side rendering makes sense for mostly static content, but for web applications, a front end framework and a back-end API are a much better match.
Uhh, sounds like you haven't been writing modern React lately, which is server side lol
I sat front row for David's talk yesterday morning. Having talked with him the day before, I’ll admit… I wasn’t particularly surprised (nor unprepared).
A bit of a field report from #RailsWorld: the vibe here is far from doom and gloom. Quite the contrary. Wherever our industry is headed, most of us are still employed as menders… tending to systems that customers rely on and businesses are quite happy to keep paying for.
Most of us aren’t waking up to a blank canvas and designing the architecture of the future. We’re inheriting decisions made years ago, updating old patterns, working around constraints, and keeping this shit running reliably.
I think these newer tools give us an opportunity to wonder a little more about the systems we’ve inherited. To unpack why things work the way they do. To tinker with assumptions we haven’t had the time, confidence, or permission to revisit… and share what we learn so the next person, or agent, has an easier time.
That deployment model we picked eight years ago? Worth another look. Some of our web apps probably wish they were native apps. And there are plenty of architectural decisions we’ve been living with mostly because… well, we’ve been busy living with them.
There’s plenty of understandable anxiety about what these tools mean for our work. I’m increasingly curious about what they give us permission to revisit.
Once my keynote is published, I’ll share more about a little programming-language-adjacent framework I’ve been working on for approaching exactly this kind of curiosity.
In the meantime… keep showing up. Keep wondering.
Long live Ruby. Long live Rails.
p(bloom)
How long will that last? It's evident that they are trying to squeeze the engineers to the max.
Ask the COBOL guys
To be fair, this is true of most of AFK world. Things start seeing a lot less doomy and gloomy when you're actually outside talking with other humans. Seems to mostly be online and various darker corners where they're dooming and glooming.
the algorithm is programmed to deliver it. Better engagement metrics with misery and anger than joy and hopefulness. (yes I know that you will reply 'but I prefer the joy and hope', but that's not the case across the wider population)
I get why DHH would be really happy about getting rid of engineers. It's less clear how this isn't a little bit gloomy for the engineers.
Is the idea that they'll switch to doing "product owner" roles overseeing agents? I don't see that employing the same number of people or paying as well as engineering used to.
To be honest I expect that that role to suit different people to those that used to be engineers.
If this feels gloomy to some people, it's because it is.
Why are you saying he got rid of engineers? Did you watch the talk?
Yes, I watched it. I'm not saying he got rid of engineers so much as just not hiring new ones.
If he's hiring new people they won't be engineers or the people that used to do engineering.
They'll be people that are better suited to writing English than code.
I don't think that hiring the engineers was ever an option. He said that he couldnt maintain six native apps before agentic coding. The business never even considered expanding headcount by 6X to do it, it was a complete nonstarter.
There is no fixed pie of work that AI is taking from us. In this circumstance, increased productivity caused the company to just make more stuff, not lay off people (or avoid planned hires).
It is a real world example of https://en.wikipedia.org/wiki/Jevons_paradox
37signals typically doesn't do hire a lot of software engineers but just last week they hired Rob Zolkos who is very clearly a software engineer.
https://x.com/jasonfried/status/2100668586851537195
How can Rails live long if no one creates new things with it? Our web applications aren't like the Pyramids at Giza. DHH literally said that even without a blank canvas (Hey's backend) they were still able to re-write the backend in Rust and are not looking back.
That sure sounds like any savvy business should pivot away from Rails and Ruby in general as fast as they can, assuming they have tokens to burn. Personally, I built my career on Python, but any new thing I build is almost always in Go or Rust. Why mess with an interpreter if you don't have to?
He clarified today, saying he would build any new app today in Rails. Should that app become so popular that it would benefit from Rust, he would rewrite it in Rust.
Source?
Its easy to be optimistic when you're sitting on millions (dhh). You literally don't need to care about how any of this affects your job security.
Right, or paying for AI models in general.
There is a world of difference of having tens of millions of dollars and paying hundreds of dollars a month for AI subscriptions vs someone making 100k / year doing the same.
For the DHH's of the world that's not even something to think about, but for most people who are working (even in tech), now we're talking 2-8%+ of your income depending how much you use AI. Just to have the "luxury" of being able to experiment with it. I use air quotes on luxury because I personally find a lot of AI results to be quite bad, but then again, I'm not spending hundreds of dollars a month on the premium models.
I’ve made a similar point to my colleagues recently about cross-platform vs native apps. If we’re using AI anyway, do the arguments we made years ago still hold today?
I know some people might disagree, mainly because AI isn’t a new architecture or a new programming language in the traditional sense. But I still think it’s worth revisiting the assumptions and having the discussion.
Depends a lot on the token budget I think, different situations for established businesses or strapped founders vs side hustles or hobbyists. So in a way you outgrow Rails or frameworks like it once you can afford a software factory on autopilot 24/7.
Publishing mobile apps in Apple store or Google Play is a shit show.
You have to adhere to bizarre requirements, you can be taken down on a whim without possibility to appeal.
You have to pay for a developer account at least to Apple each year $100, Google one time fee $25.
Nothing like that for a web app.
I mean, that’s like half an hour of tokens, right? (Half joking laugh/cry etc)
I think more often the comparison is web techs (like React native) VS native apps.
From your profile: CEO/Founder of Planet Argon...
Looking it up: Planet Argon is a Ruby on Rails development agency.
I think most people on HN know robby russel. Have you ever used ohmyzsh?
Robby is well known in the Ruby community.
Serious question: Is there a framework that is better suited for agents? There must be something out there that makes agents fly through development with minimal token expense.
Elixir. Phoenix or Hologram. I prefer the latter.
Why is Elixir better suited for agents?
It's vibes all the way down.
I think there's actually something to it: https://x.com/josevalim/status/2019422467446698493
I that case so is Clojure.
An agent that was looking at the log output from a program in a typical language, and also looking at the code for that program, would have a lot of unanswered questions related to "how do I iterate on this?" Maybe there's a kubernetes cluster involved somewhere. Maybe it there's a cloud storage bucket. Maybe there's dashboards and metrics and telemetry hosted by servers that the agent doesn't know the name of.
Elixir runs on the BEAM which lets you do hot code reloading process at a time. And these are much more lightweight than your typical OS process. So you can do things on the BEAM which would be just crazy to do on other achitectures. Like if you have a server which needs to support a million users, it would be insanity to run a million separate OS processes for the job. But BEAM processes are so lightweight that you can do that, which gives each one isolation from misbehavior of the others.
And since these support hot code reloading, without restarting the BEAM's OS process, you can patch the code for your user's sliver of the server and do a sort of "what-if" experiment. Other architectures would require you to implement separate test environments or complicated feature flag systems, but the beam lets you just reach out and change it for just the process you care about--you're not baking the experiment into an OSI image or anything so dangerous as that... blast radius is kept small.
And the steps for carrying out this experiment, it's all doable at the elixir shell. You connect to the BEAM and make changes. That's a tremendous reduction in context that an agent needs to load--context which would otherwise instruct the agent about how to reason about the deploy process and how to wall off your experiment from others so as to not cause problems with it is just answered implicitly by how the BEAM works.
Elixir compiles to BEAM bytecode, so you get all of this because the BEAM is cool. As for Elixir as a language... I don't think there's anything agent-specific about it. Gleam might be a better choice since it's statically typed and also compiles to BEAM bytecode except that it's not as popular as Elixir, which is probably more important.
You can also do all of this in the language that started it all: Erlang (Java : JVM :: Erlang : BEAM) but it's not exactly fashionable at present (similar to java vs like... kotlin or clojure or something).
Disclaimer: I'm more of a fan than a seasoned pro. I'd love to actually be working with this stuff daily, but my team wouldn't have it because they prefer familiar things and pain.
I maintain Elixir and Rails applications. In my opinion, almost all LLMs handle Elixir better. I suspect, though do not know, being an immutable functional language and composing applications in a functional style makes it easier for the models to "reason" about the code and state. I learned very quickly that this is my preferred language for that very reason.
Additionally, the features available in the BEAM and OTP mean the agents have built-in tools for many things that would require reaching for 3rd-party libraries or even additional services. This means less variability in design as the models will happily use all the language features human developers would have to learn about and understand over time to use effectively. Not that this isn't important, but I believe models do a better job steering you to obvious and optimal solutions with Elixir.
The new type system is only going to make it better.
why is that?
Yep I find Elixir very enjoyable with agents at the moment, I've been developing a lot in it. It helps that I already liked the language and the platform, and now I just have the ability to build out my ideas faster.
I think they're good at it for a variety of reasons, but it likely helps having a smaller and newer community than many languages, meaning less out of date guff clogging up the LLM sources.
AI-psychotic and proud!
Results and output are undeniable, unless you are delusional or in denial.
Worry not, for I am using Claude right now. I would never question the doctrine of AI usefulness and productivity. Please scrap that J'accuse draft, sir, for I would never commit blasphemy against AI, I promise.
I'm not worried, feel free to use punch cards if you want sir..
It's still early days, I'm hesitant to claim the death of software engineering. It's good now because LLMs were all trained on actual human output. One possible future is a slop death spiral.
I sure as hell am never again releasing human-authored open-source in a way that can be scraped. My Github is now relegated to the lowest quality slop from the cheapest models.
So far a Rust rewrite's success rate directly, probably super linearly, correlates with the presence of a good, well designed test suite. This is why Bun's rewrite and others are successful. I anticipate that this will be true for the 37Signals rewrites.
I want to learn a couple of things once they are done:
1. Once the test suite assistance is over, how do features get built in their backends and continue to maintain the same quality. LLM test writing is a bit trickier as it often favors what Randy Coulman called tautological tests back in the day. It takes a lot of work to get them not to do this, so I am guessing folks at 37Signals will read at least this part. I can't imagine zero Rust read at all.
2. Over the years they had a few innovations in their domain design, ones that Rails made easier to do, for instance their delegated type pattern. Will Rust replicate this, and how would one know without reading it, or perhaps it does not matter? Furthermore, how do newer patterns emerge? and how does our arsenal of better abstractions keep growing?
I don't have the answers but I am glad there is a chance we can learn said answers.
That's cool, but like with most things, I think the manager types will misunderstand:
- A lot of this is looking at an existing app and/or code for reference.
- The people doing/guiding this are skilled.
- Skilled people have thought out what to make.
Otherwise they hear "20 minutes" and think AI can spit out a logical or good product from no reference or planning.
Talk is sponsored by Shopify, which also sponsored the Lex Fridman 5 hour promotion.
All DHH's AI opinions are sponcon.
But he has great flagging support and his perception management agency will suppress this one, too.
I really enjoyed DHH's keynote speech using his own family lineage story via the art history intertwined with technology evolution portrait paintings -> photography pictures as analogy of what's happening right now in the technology landscapes.
He may be racist but what a great orator! (Who else does that apply to?) Can't really disagree with him about the AI stuff either. I mean maybe it's a bit premature but if it isn't true now it will be in 5-10 years.
I guess the death of Ruby is a silver lining to AI at least.
So the keynote mentions that in a perspective you are going to be a "maker of things" rather than a coder. But, nobody is asking, in a perspective, why would anybody use the stuff you "make" rather than using AI directly? All of the notion of apps disappears, in a perspective.
Because it does take some skills, judgement, taste, knowledge, time and effort to build things. He said it is not very different from directing a team of contractors, and also said that a 10x dev in now 1000x with a tool like this. He also gave the parallel of photography to address this point, that people were forced to be more creative and adapt.
But I assume you didn't use to build anything substantial.
As of now, but we are talking in a perspective.
People are not well organised.
Business people I work with tend to have all kind of ideas in different places, I cannot count all the Trello boards they have abandoned. Users are usually lazy and don't want to fill in data properly, well yeah chatbox with llm is cool interface, but you still have to enforce structure for data so it is useful.
With AI problem is still there "garbage in, garbage out", models are not going to imagine correct data to fill in blanks, in the end if you need someones birthday, someone has to type it in.
Web app I am working on is organised only because we get engineers and quality assurance and we get paid for maintaining application. Data is structured and we can deliver insights because the application enforces structure.
There are far more requirements than AI can deliver on its own.
I have a "cooking notebook" of recipes, cooking techniques and notes, that over the past ~15 years or so I've migrated from Evernote to Notion and most recently to Bear. I've built this all up over time, and don't really want to just ask ChatGPT instead.
I have a pretty solid idea what the 'perfect' custom app for this would look like for me at this point. I've toyed with the idea of vibe coding it, but I simply don't have the time to get it built, test it out, and refine it to the point where it'd meet the vision of what I want.
Bear isn't exactly what I want but it's close enough right now to warrant using it and paying for it. And it seems to have a decent team behind that's going to spend time continuing to build and improve it so I don't have to.
I think the perf jump from Ruby to Rust is much greater than .NET Core to Rust. Not much will change in .NET land for the foreseeable future. I see this migration happening from Ruby and others so it is not surprising from that aspect.
Also - what he is talking about was true for well over a year. It is just that a lot of day-to-day gaps between prompt and output were closed in the meantime. In a sense, Ruby on Rails/37 Signals is a late adopter.
Haven't watched the video, but I've been spending a few hours the past week re-acquainting myself with Ruby before diving back into rails introductions.
Ruby is an interesting language to work with. I don't know it like Python, but it's a language that finds problems developers would run into and built solutions in to make it easier.
As for Rails, as a total novice: It is a lot of Convention over Configuration, and it's almost a second language on top of Ruby. Everything works together implicitly so you have to recognize what's happening when you look at the code. I don't know if any Ruby/Rails oriented IDEs exist that guide the developer with hints and shortcuts to how the pieces of a Rails app fit together, but it sure would be handy.
I can see how typed, high-performance languages with explicit references to all the integrations would be easier for AI to handle. But as long as humans sometimes have to look at the code, I would think Rails still has a place.
weird talk; is not reading any code _at all_ is the new standard now? I do happily ai-slop side projects here and there but seems like just going full steam ahead _at work_ is ok? sorry, I meant - is the future now? xd
How a developer oriented conference can give one minute of screen time to a by now fully open, mask off, racist / fascist is beyond me. Does the Rails world don't know, or don't care?
Edit: it's his conference because the actual Rails conf banned him. Sad victory I guess.
He owns RailsWorld.
It's his conference he made because he was banned from railsconf.
aha, that explains the podium. Thanks for enlightening me. Kudos to Railsconf.
Okay, I'll bite. What did he do that's racist and fascist. And please provide receipts.
For reference, here are the definitions:
racist: a person who believes that a particular race is superior to others, or who discriminates against other races
fascism: any right-wing, authoritarian, nationalist ideology characterized by centralized, totalitarian governance, strong regimentation of the economy and society, and repression of criticism or opposition
A lot has been said about DHH, but, I think the moment where you can see that the guy has _clearly_ lost it is this quote:
The guy now(?) thinks like a lossy abstraction that speaks in tropes.
He has become the LLM - I would say, if I didn't know that even a 9B one can tell me with absolutely certainty how much space there is on a fucking floppy.
There is no reason to get into all the politics stuff when this is where the guy is at. Basic fact retrieval.
(Pedantically, one could now argue that it was not clear which floppy format the guy was referring to. And yes, that would be true, but by thinking that thought, you have thought about the sentence more than its author has.)
Overanalysing someone's spoken sentences isn't the badge of honour it might appear to be.
I don't get it. Are you saying floppy disks were usually bigger than half a fucking megabyte or smaller?
I'm missing something (as usual) because I don't see what's wrong with his statement.
He is a provocateur, many things to ponder. Rust fans are jumping up and down that the backend is going to be in Rust. That's not what he saying though, his rewrite snapshot had a bunch of languages with Shell being 26%, Python 13% and Rust 7%, in the previous version Ruby was 55%. His comment on Rust was "I love Rust! Rust is amazing ...if you never, ever, EVER have to look at it yourself." It's going to be interesting to see where this lands in one year when a bunch of projects have been rewritten by Agents in Rust and our Rust Hero shows up and has to maintain that code. Seems like a Zen kaon to me - if you don't read, write or have to understand Rust but the Agent does, is your program safe or performant. Your intuition of what safety is or performance no longer comes from looking at the source code but something else and in the next turn your entire Rust code base could get optimized to some IR or assembler that you no longer can even understand!
Next year they will rewrite rails in rust with AI