Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Classic DHH.Allways talks about what is good for his situation, not what is good for the community in general. I can understand his excitement of slashing his server and labor expenses. He will be richer and have more time, less people will work for him and wow, rails came a long way, didn't it ? The world is your oyster now! Oh and btw, we are changing the name of the conference, it's called Rust conf now.by smnplk
- 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.
by ksec - 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.
by why-el - A lot can (and should) be said about this keynote, but I have a hangup on portraiture as an example of "creative destruction" (how I loathe that expression!). Classical portraiture is still alive and well and artists are still able to make a living from it - possibly even more of them now than during the 1800s.
The advent of the camera did push visual art in new directions, but not quite as presented here. Oil painting and portraiture wasn't as static as it's made out to be, and there's a difference between a commissioned portrait and artists painting people because they enjoy painting people. Giuseppe Arcimboldo, El Greco and Hieronymus Bosch are some of the most well-known experimenters in western art and they were active in the 1500s. Some of the most famous art movements (impressionism, expressionism, arts & crafts) appeared well before photography was democratized.
The biggest difference, though - as much as I love art - is that portraits are a distraction. Then as now, it's mostly a vanity project for the affluent and of little consequence to the lives of the vast majority. Software, on the other hand, is not only a multi-billion dollar industry employing millions of people, it's also a direct matter of life and death, since it's an essential component in things like nuclear power plants, airplanes and medical equipment.
by arexxbifs - 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.by zerr
- Nah I'm good thanks. Call me old school, but I'd rather understand how things work, and try and keep a maintainable codebase. Rather than just get some random rust I've no idea what it is, or why it does it, pushed into prod.
I think this is going to be todays 'cheap outsource' culture. Good enough to keep shareholders happy, an apparent boost in productivity, before tanking the reliability of the company.
Remember when we used to scorn stackoverflow developers, or PRs that were more than a few lines long. An every morning git pull is now bigger than my terminal buffer, its complete chaos. Numbers game to keep the new metrics world gamification going. Its dire.
by lovedaddy - 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.
by robgough - 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)
by robbyrussell