Right now, I would rather use Go with a simple framework, or even without one. With Go, it's so easy just to copy the binary over.
You just keep up as you go, as long as you keep things close to the framework it's fine.
He said "Updating a project that was started 5-6 years ago takes a lot of time."
Also breaking APIs should be regarded very poorly. It isn’t. But it should be.
Thankfully, updating to a new Django version is usually simple. It does not require many code changes.
But finding small bugs after an update is hard, unless you have very good test coverage. New versions of middleware/Django plugins often behave slightly differently, and it's hard to keep track of all the changes when you have so many dependencies.
I’m not into RoR, because I was mainly PHP rescuer in the beginning of my career, but they both are just problem solvers. Sit down, write minimal (in case of PHP not so cool looking) code and proceed to next task.
Honestly, breath of fresh air.
It's the closest I've come to that old school "in the box" desktop development experience you used to get from building desktop software with Visual Studio or IntelliJ IDEA or NetBeans or Eclipse or any of the other IDEs of the 90s/00s (I never used Delphi or VB but I imagine in some sense they were even moreso than the ones I've listed, which are the ones I used), only it's web development.
For me web development has always felt like a frustrating ordeal of keeping track of 10,000 moving parts that add noise and cognitive load and distract you from fixing the actual problems you're interested in solving. This means the baseline ancillary workload is always frustratingly high. I.e., there's too much yak-shaving.
Whereas Rails seems to drag that all the way down to a level where it feels more similar to the minimal yak-shaving needed to (at least superficially) build, run, and distribute desktop software. Not that this is without its challenges, because every deployment environment is a little different in the desktop world, but the day to day developer experience is much lower friction that modern web development in general.
Also, no sodding TypeScript to deal with. I hate TypeScript: an ugly, verbose, boilerplatey abomination that takes one of the nicest and most fun features of JavaScript (duck typing) and simply bins it off. Awful.
Not many frameworks have been thriving that long, and there's good reason.
It packs everything, is tidy and productive, with a pleasant language to read and write.
In the latest Stackoverflow survey, it's back at the "top 5 of desired stacks to use for next project" over a decade after its inception !
Give it a try.
So everyone just stop worrying what everyone else thinks or seems to think and just use the right tools for you and get on with it
Can you expand on why you found it so appealing or "holy crap, this is awesome" things I should look at first ?
Elixir is also a very cool language in a lot of ways. I wouldn't go all in on Elixir/Phoenix, but that's because there's not a huge demand for it, at least where I reside. I would 100% consider it for some smaller projects though, if I stood between that and Rails, and I wouldn't mind having to get more comfortable with Elixir.
Edit: I haven't used Rails 8, and haven't followed the ecosystem since a bit before, so not sure how this feels nowadays. I *really* enjoy Rails backend though, but the frontend stuff never quite clicked.
It has been absolutely wonderful building this with Elixir/Phoenix. Obviously any codebase in any language can become a tangled mess, but in 7 years we have never felt the language or framework were in our way.
On the contrary: I think Elixir (and Phoenix) have enabled us to build things in a simple and elegant way that would have taken more code, more infrastructure, and more maintenance in other languages/frameworks.
Elixir is a functional programming language based on the "BEAM", the Erlang VM. We'll get back to the BEAM in a moment, but first: the functional programming aspect. That definitely took getting used to. I remember being _very_ confused in the first few weeks. Not because of the syntax (Elixir is quite Ruby-esque) but because of the "flow" of code.
However, when it clicked, it was immediately clear how easy it becomes to write elegant and maintainable code. There is no global state in Elixir, and using macros for meta-programming are generally not encouraged. That means it becomes very easy to reason about a module/function: some data comes in, a function does something with that data, and some data comes out. If you need to do more things to the data, then you chain multiple functions in a "pipe", just like how you chain multiple bash tools on the command line.
The Phoenix framework applies this concept to the web, and it works very well, because if you think about it: a browser opening a web page is just some data coming in (an HTTP GET request), you do something with that data (render a HTML page, fetch something from your database, ...) and you return the result (in this case as an HTTP response). So the flow of a web request, and your controllers in general, becomes very easy to reason about and understand.
Coming back to the BEAM, the Erlang VM was originally written for large scale (as in, country size) telephony systems by Ericsson. The general idea is that everything in the BEAM is a "process", and the BEAM manages processes and their dependencies/relationships for you. So your database connection pool is actually a bunch of BEAM processes. Multi-threading is built-in and doesn't need any setup or configuration. You don't need Redis for caching, you just have a BEAM process that holds some cache in-memory. A websocket connection between a user and your application gets a separate process. Clustering multiple web servers together is built into the BEAM, so you don't need a complex clustering layer.
The nice thing is that Elixir and Phoenix abstract most of this away from you (although it's very easy to work with that lower layer if you want to), but you still get all the benefits of the BEAM.
[^1]: https://github.com/mame/ai-coding-lang-bench?tab=readme-ov-f...
I gave RoR a try last year, and so far I'm at the same level I was with the other projects but I actually enjoy programming the project after the PoC phase. Maybe because third time's a charm? Maybe because I know what I need to do? Who knows! But RoR fits in that idiom.
Just to note, its a really boring app thats been done before (odeva.app)
I think once you're deep into a project, you of course know the features needed and the constraints and you'll be more efficient the next time around.
I think the challenge is to keep working on your old legacy projects.
Plus Symfony is quite flexible on how you want to organize your code. Modular monolith, monolith, DDD, microservices, "junior developer just setting up controllers and entities".
As for Rails, I guess now that Ruby is serious about having a JIT in the box, a few actually, it is kind of atractive.
Due to my experience with Tcl, and continuous rewriting into C modules, if a JTI isn't in the box, I kind of don't bother unless it is due to external factors.
Not until they get their gradual typing story straight.
I’m usually a Go person and love it, but building simple crud routes is not the fun part of it.
I have the impression, though, that these days it only appeals to those who picked it up before version 3 or 4, when it was smaller, maybe more understandable, and incredibly better than all the competing frameworks (except Django maybe).
If your first contact with rails is version 7+ and you’re only comfortable with JS/TS, then you’re not going to get it and might actually strongly dislike it
This is the primary issue with Rails in my experience. It takes intentional effort to internalize the idioms before it clicks and you unlock the magic that makes it so insanely productive. JS devs will keep trying to force backend business logic into Franken-React Stimulus components and complaining it's not very good.
Frameworks and structure will save you from neither stupidity nor ignorance.
However, modern day JS frameworks don't care about this at all. Most of them love flaunting about their raw performance numbers. Security? Fuck that. Not even basic form CSRF protection. A lot of times, there is not even SQL injection prevention in them.
Compound this with someone who just vibe codes their app on top of these frameworks - that's how you end up getting hacked. Every week there is an incident. That's why good frameworks like Rails are very important. People who actually care about writing secure, good quality software are on the decline, but thank God rails still exists as an option in 2026 despite the fact.
JS solutions are loosely coupled, lots of good reasons to do so, but comes at a major complexity cost.
But you can also pick tight packages that do one thing well. Something like oRPC + Drizzle that lets you pipe data from your database to frontend with full typing and cross-boundary go-to-definition while covering most of what Nest and Adonis do with better focused APIs.
And in terms of security, I'll take Typescript with a strong compiler config anyday. For example, I disable: `any`, non-null asserts (no `!`), floating promises without `void` for explicitness, no unnecessary conditions, and a bunch of other strict rules. I also use Branded Types liberally. All of that makes logical errors that can become app-specific security issues (and are thus less readily detected) much less likely to happen. And as a bonus you get really reliable code too.
that's not how it works. and i'm fairly sure most all apps deal with databases, unless they're explicitly static pages.
edit: sql injection is about hacking the parameters used in a query. they almost always in some way come from external sources, user input. so they have to be sanitized. it sounds straightforward but bounties are paid all the time on hackerone with documented cases of injection. people are very clever.
i've had to patch some verified cases where the hacker used the name field to pass code in and alter links in emails to make it look like they came from our (household name) company.
> Accelerate your agents with convention over configuration. Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write and beautiful for humans to review
And I fucking hate it. If I read this the first time I would think this is some kind of tool to optimize your LLM agents.
I have been using Rails for over a decade now and always liked the focus on writing beautiful and simple code. On making it easy to reason about with colleagues. Now it seems like DHH is throwing all what made Rails special overboard.
If we are all supposed to be talking to agents now, what's the difference if my agent uses fucking Next, Nuxt, Rails or Django?
This is so painful... I can't help but wonder who they're trying to target with such inane slogans.
Rails is amazing, but "token-efficiency" is not on the list of reasons why.
Typical DHH insanity.
The people who think that spicy autocomplete actually has an understanding of the slop it's churning out for them.
I've only just noticed that on the Rails homepage, and while I acknowledge everyone's chasing that sweet sweet AI hype, I gotta say that's... disappointing[1]. The reason I fell in love with Ruby (and by extension, Rails) is because it enabled me as a human to express myself through code. Not to become a glorified janitor for a LLM.
[1]=Well, I had a stronger response initially but I toned it down a bit for here...
The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective".
But yes, I do agree that the main line should say what Ruby on Rails actually is, not why it's good for your agent.
However having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types. For LLMs thats important as well, the more guard rails you can give them the better. What's the state of type checkers today?
However, the fact its still the js ecosystem with react, thing is even though it's super productive in churning out the code, there's too many possible ways to do something. it's unwieldy.
For example Claude is obsessed with making react context providers. it'll make tons of them to power every feature. and your app will happily hold 20 layers of russian doll'd state in memory with no way to link to anything.
you have to tell it, no don't do that. i need you to power this thing through the router, through the url. and that has to be designed cohesively. and that's very different from the context free-for-all.
The agents pick up conventions from the extensive code in their corpus and aggressively follow them. I don't think Rails being explicit about it adds a lot unless someone is prone to prompting towards absurdity.
it's a little cringe, but arguably the benefit of having agents use rails would be tht when you review and audit the agent produced code, you review something that is, as you put it: "beautiful and simple code" and "making it easy to reason about..."
I loved rails back in 2017. I may be an outlier but the line tempts me to try it again despite having adopted the who cares attitude to langs. Would be nice to hear from someone first hand if they felt it helped.
fwiw that headline is cringey for sure. but DHH has proven himself a great marketer. it very likely is riding the wave.
Trying to answer the question of, why is language and framework still relevant in a world where almost everyone uses an agent for coding?