I love Rails, but after working for a few places with huge Rails codebases and then several other places with .NET and other frameworks with actual typing, I just can't go back to Rails for anything that isn't a personal project.
Working with a large codebase with an untyped codebase is just a nightmare, even with powerful IDEs like RubyMine that are able to cover some of the paint points. I wonder how good Sorbet is these days, though, especially the RoR experience
Concur on most interesting! I really hope it works out, but am cautious.
It is surprising to me seeing the rust web backend scene; many libraries, server frameworks, and users, but they are all Flask-analogs, without the benefit of the reasonably-robust ecosystem Flask has. My suspicion is that people are using them for micro-services and not websites/webapps, but I haven't been able to get a straight answer on this about how people are using these tools. I.e. even though rust is my favorite overall language and see no reason it couldn't be used for web work, I still use Django.
Axos, Axum, Rocket, Diesel etc, are all IMO not in the same league as Django. My understanding is that addressing this is Loco's Raison d'etre.
Another aspect of the Rust web ecosystem: It's almost fully gone Async.
I'll say this, coding agents make the lack of a "batteries included" framework like rails or Django somewhat less daunting.
But "convention over code" and having a default structure / shape for projects is extremely helpful and you feel it when it's missing.
For my last small project I looked at Loco but ended up passing on it because I felt like adoption wasn't great yet. I really hope it takes off, though.
It's really hard to get away from ssjs frameworks for front-end, so for my startup it's Axum + Seaorm for "the api" and a Svelte SSR "front end" / view layer.
I think rust programers are more likely to want flask/rack than Django/rails.
I'm at a point now where I'm not even a little interested in new frameworks. I want tried and tested. Preferably something that has been around for 15 years.
I worked with Rails a lot. In my experience, every rails dev who is fanatical about how much they love Rails, also has little to no experience with strong types. Of the ones who later try types, they no longer love Rails. Personally I quit Rails entirely because of lack of types. No, RBS and Sorbet are not even close to good enough.
Also, every enterprise rails app I've seen (seven, to date) has been really poorly written/architected in a way that other backends just weren't. Even the fairly new ones felt like legacy code already.
I still really like rails. It’s really fun until your codebase reaches a certain size. At that point you better have a large suite of test which becomes a problem of it self because the tests will take forever to complete.
I tried sorbet a couple of times and totally get why it’s useful but imo it’s not just lacking (e.g. compared with what can be done with TS or even a simple type system like golang) but it also removes all the fun parts of ruby / rails.
Right, the test culture is very silly to me. Thousands of tests and long CI times, basically just doing a poor invention of a compiler. Dynamic types are so much extra work.
It's not just the untyped problems, the runtime definitions of functions, properties, etc make it nearly impossible to debug unless you have the state of your production data locally. (Or you ssh into your prod server and open up a REPL, load the state and introspect everything there). Good luck debugging locally in a nice IDE. It's a horrific nightmare. I use to love Ruby until I had to debug it live.
Yeah, dynamic typing is one thing, but the magical dynamic imports into the processes globally scoped namespace add another level to debugging difficulty.
At least in Python (as a comparison example), imports are only available in the module doing the importing - it's more explicit. You'd have to really work to get the same "everything all at once" as Rails has.
If you make a change to the return types of a function for example you have to manually find all of the different references to that function and fix the code to handle the change. Since there are no compile time errors it's hard to know that you got everything and haven't just caused a bug.
Yes, and the downsides cascade. Because making any change is inherently risky you're kind of forced not to make changes, and instead pile on. So technical debt just grows, and the code becomes harder and harder to reason about. I have this same problem in PHP although it's mostly solved in PHP 8. But touching legacy code is incredibly involved.
Especially with duck-typing, you might also assume that a function that previously returned true-false will work if it now returns a String or nil. Semantically they’re similar, but String conveys more information (did something, here’s details vs did(n’t) do something).
But if someone is actually relying on literal true/false instead of truthiness, you now have a bug.
I say this as a Ruby evangelist and apologist, who deeply loves the language and who’s used it professionally and still uses it for virtually all of my personal projects.
Alan Kay's argument against static typing was it was too limited and didn't capture the domain logic of the sort of types you actually use at a higher level. So you leave it up to the objects to figure out how to handle messages. Given Ruby is a kind of spiritual ancestor of Smalltalk.
the problem is that nobody listened to Alan Kay and writes dynamic code the way they'd write static code but without the types.
I always liked Rich Hickey's point, that you should program on the inside the way you program on the outside. Over the wire you don't rely on types and make sure the entire internet is in type check harmony, it's on you to verify what you get, and that was what Alan Kay thought objects should do.
That's why I always find these complaints a bit puzzling. Yes in a dynamic language like Ruby, Python, Clojure, Smalltalk you can't impose global meaning, but you're not supposed to. If you have to edit countless of existing code just because some sender changed that's an indication you've ignored the principle of letting the recipient interpret the message. It shouldn't matter what someone else puts in a map, only what you take out of it, same way you don't care if the contents of the post truck change as long as your package is in it.
That's a terrible solution because then you need a bunch of extra parsing and validation code in every recipient object. This becomes impractical once the code base grows to a certain size and ultimately defeats any possible benefit that might have initially been gained with dynamic typing.
>then you need a bunch of extra parsing and validation code in every recipient object.
that's not a big deal, when we exchange generic information across networks we parse information all the time, in most use cases that's not an expensive operation. The gain is that this results in proper encapsulation, because the flipside of imposing meaning globally is that your entire codebase is one entangled ball, and as you scale a complex system, that tends to cost you more and more.
In the case of the OP where a program "breaks" and has to be recompiled every time some signature propagates through the entire system that is significant cost. Again if you think of a large scale computer network as an analog to a program, what costs more, parsing an input or rebooting and editing the entire system every time we add a field somewhere to a data structure, most consumers of that data don't care about?
this is how we got micro-services, which are nothing else but ways to introduce late binding and dynamism into static environments.
> when we exchange generic information across networks we parse information all the time
The goal is to do this parsing exactly once, at the system boundary, and thereafter keep the already-parsed data in a box that has "This has already been parsed and we know it's correct" written on the outside, so that nothing internal needs to worry about that again. And the absolute best kind of box is a type, because it's pretty easy to enforce that the parser function is the only piece of code in the entire system that can create a value of that type, and as soon as you do this, that entire class of problems goes away.
This idea is of using types whose instances can only be created by parser functions is known as Parse, Don't Validate, and while it's possible and useful to apply the general idea in a dynamically typed language, you only get the "We know at compile time that this problem cannot exist" guarantee if you use types.
> The goal is to do this parsing exactly once, at the system boundary
You are only parsing once at the system boundary, but under the dynamic model every receiver is its own system boundary. Like the earlier comment pointed out, micro services emerged to provide a way to hack Kay's actor model onto languages that don't offer the dynamicism natively. Yes, you are only parsing once in each service, but ultimately you are still parsing many times when you look at the entire program as a whole. "Parse, don't validate" doesn't really change anything.
> but under the dynamic model every receiver is its own system boundary
I'm not claiming that it can't be done that way, I'm claiming that it's better not to do it that way.
You could achieve security by hiring a separate guard to stand outside each room in your office building, but it's cheaper and just as secure to hire a single guard to stand outside the entrance to the building.
>micro services emerged to provide a way to hack Kay's actor model onto languages that don't offer the dynamicism natively
I think microservices emerged for a different reason: to make more efficient use of hardware at scale. (A monolith that does everything is in every way easier to work with.) One downside of microservices is the much-increased system boundary size they imply -- this hole in the type system forces a lot more parsing and makes it harder to reason about the effects of local changes.
> I think microservices emerged for a different reason: to make more efficient use of hardware at scale.
Same thing, no? That is exactly was what Kay was talking about. That was his vision: Infinite nodes all interconnected, sending messages to each other. That is why Smalltalk was designed the way it was. While the mainstream Smalltalk implementations got stuck in a single image model, Kay and others did try working on projects to carry the vision forward. Erlang had some success with the same essential concept.
> I'm claiming that it's better not to do it that way.
Is it fundamentally better, or is it only better because the alternative was never fully realized? For something of modern relevance, take LLMs. In your model, you have to have the hardware to run the LLM on your local machine, which for a frontier model is quite the ask. Or you can write all kinds of crazy, convoluted code to pass the work off to another machine. In Kay's world, being able to access an LLM on another machine is a feature built right into the language. Code running on another machine is the same as code running on your own machine.
I'm reminded of what you said about "Parse, don't validate" types. Like you alluded to, you can write all kinds of tests to essentially validate the same properties as the type system, but when the language gives you a type system you get all that for free, which you saw as a benefit. But now it seems you are suggesting it is actually better for the compiler to do very little and that it is best to write your own code to deal with all the things you need.
> I think microservices emerged for a different reason: to make more efficient use of hardware at scale.
Scaling different areas of an application is one thing. Being able to use different technology choices for different areas is another, even at low scale. And being able to have teams own individual areas of an application via a reasonably hard boundary is a third.
Anything can return anything and you only realize it at runtime is a massive headache. When you can't keep the entire code base in your head it becomes a liability.
I never used Ruby, but Python code bases love mixing in strings that are actually enums and overloading functions that accept all kinds of types. You just had to hope that the documentation was correct to avoid a crash.
Java 1.7 to Python feels very freeing from all the boilerplate. Kotlin, or any other modern language with a well designed standard library, to Python just feels like a bunch of extra mental work and test to write to just avoid brackets.
It makes coming up to speed on an existing codebase a slog because you have to trace through everything back to its source. Oh, and because there are magic methods and properties galore, your normal introspection tools in e.g. RubyMine get frequently stymied.
https://ihp.digitallyinduced.com/ is a rails-inspired framework for Haskell that tries to get the best of both worlds. Highly recommend trying it if you have a weekend
I’ve worked in two places now with Ruby Sorbet servers. Ruby always drives me nuts how things are just in-scope and we don’t know why or where they came from.
I certainly wouldn’t want to go back to working in dynamic languages without typing on top. That takes too much brain power, I’m too old for that now.
I would say Sorbet seems more “basic” than something like Typescript. It handles function calls matching signatures, potential nulls, making sure properties actually exist, that kind of thing. Whereas TS can get quite abstract, and at times you’re fighting to convince it that a value actually is the type you say it is.
TS is very powerful and expressive, to the point that it’s possible to do computation within type code. I’m not convinced I always need that power, or that it’s always more help than hindrance.
You appear to be shadow banned. Letting you know since I didn't see anything egregious on a quick scan. Maybe contact HN and plead your case.
I vouched for your reply below, and to answer in the meantime:
Yes, it's runtime, but that only matters if your code can't be initialized without unacceptable side effects.
In which case you don't have a functioning test suite either, and have much larger problems.
Otherwise, just load the code you struggle to figure out into irb, or pry, or a simple test script, and print out source-location.
If that is impossible (aside from the fact that codebase is broken beyond all reason), the marginally harder solution is to use ruby-lsp[1] and look up the definitions.
This is only hard if you insist on refusing to use the available - and built in, in the case of source_location - tooling.
> I certainly wouldn’t want to go back to working in dynamic languages without typing on top. That takes too much brain power, I’m too old for that now.
> and at times you’re fighting to convince it that a value actually is the type you say it is.
Might just be allocating that brain power to the same task but calling it a different thing.
Doesn't matter because LLMs also benefit greatly from typed code bases in that they can run the type checker and fix the problems themselves on a loop.
I haven’t seen much discussion about this point other than “llm handle languages x y and z because there’s a lot of training data”. Watching Terence Tau using llm for writing proofs in Lean was a real eye opener in this regard.
Thanks for such public confirming there is a lot of more us.
I’m just tired hearing how great ideas will save our overblown pseudo-microservice architecture and I’m also running into some projects during evening that just solve problems without use STOA, unnecessary solutions and architectures.
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.
I've just started using RoR for a live greenfield project since New Year.
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.
TS doesn't "bin off" duck typing, it's a fundamentally structural type system. It's statically analyzed ducks, all the way down - when nominal behavior is preferred, people have to bend over backwards. Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript. In any case, it's the programming language that successfully brought high-level type system concepts like type algebra, conditional types, etc. to their widest audiences, and it deserves a ton of credit for that. The idea that JS and Ruby and Python and PHP developers would be having fairly deep conversations about how best to model data in a type system was laughable not that long ago.
> Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript.
All right, fine: TypeScript uses structural typing which is if you like a specialisation of duck typing but, whatever, compared with JS's unadorned duck typing it still leads to embellishment of the resulting code in ways that I don't enjoy.
I've been using TypeScript across different projects at different companies since 2013 and I've absolutely given it an honest go... but I just don't like it. I even allowed its use at a mid-size company where I was CTO because it fit well with React and a sensible person picks their battles, but I still didn't like it.
I'm now in the very privileged position where I don't have to use it, and I don't even have to allow it a foot in the door.
Now I'm sure that won't last forever, and I'll have to work with TypeScript again. I'll do it - because I'm a professional - but I'm still entitled to an opinion, and that opinion remains that I don't like the language. After 13 years of use I feel pretty confident my opinion has settled and is unlikely to change. I find it deeply unenjoyable to work with. BUT the plus side is that in the era of LLMs perhaps I no longer need to worry so much about have to deal with it directly when it eventually does impinge upon my professional life again.
I found it not just to lead to embellishment, but (1) the problems it did flag mostly would be caught by minimal testing; whereas (2) it regularly missed deeper problems. For an example of the latter: using TanStack (React Query) api caching, you have different data shapes for infinite scroll vs non infinite scroll. There were circumstances were an app confused them. Typescript had nothing to say. Nominal typing easily handles these cases and, ime, caught more actual problems.
> the problems it did flag mostly would be caught by minimal testing
Yeah, I agree, and the thing is, you're going to write automated tests whether you're developing in JavaScript or TypeScript so the extra cruft of TypeScript seems even less worthwhile.
The argument I've heard people put forward is that JS is fine for small projects or a couple of developers but doesn't scale to large projects or teams. I don't know how large large is, but I've worked on a project with around 30 devs where the front-end was all JavaScript and everyone was touching it and, sure, that project had some problems, but the root cause of those problems wasn't using JavaScript.
> the problems it did flag mostly would be caught by minimal testing
Testing is more expensive up front and in maintenance than type annotations. A test suite comprehensive enough to replace type annotations would have an ass load of assertions that just asserted variable type; if you were involved in early pre-TS Node, you remember those test suites and how they basically made code immutable.
> (2) it regularly missed deeper problems
This is a skill issue. If your types do not match runtime behavior and you choose to blame the programming language rather than your usage of it, that's on you. There are a lot of unsafe edges to TS, but a diligent and disciplined engineer can keep them isolated and wrapped in safe blocks. Turn off `any`, turn on all the maximal strictness checks, and see if your code still passes, because if what you said about infinite scroll is true, it won't.
And one of its many problems is that it tries quite hard to pass itself off as not having those unsafe edges which, ironically, makes it easier to get tripped up by them.
But we need contracts that go way further what static typing provides. If they add dependant types + ability to enforce the types at runtime so that you can use it on various inputs, then maybe it will be truly useful.
You are absolutely not alone, brother (or sister). In the past few years when a lot of the millennial generation started getting their first jobs, the shiny object syndrome took over and most everything being made now is a distributed monolith pile of spaghetti code trash.
There are endless tools available, and quick internet dopamine feedback loops, but almost no wisdom.
Give it a few more years and more inflation, and the remaining 35% of millennials will get out there to find their first jobs, and then the impact will be even worse.
We've been running Rails apps in production continuously since 2007. If you treat software as anything other than completely disposable, it's been a no-brainer for the entire 19+ years I've been paying attention (not despite its age, but because of it).
The premise that you get meaningful efficiencies from JavaScript on the back-end just because you have to use it on the front-end has been pretty thoroughly debunked at this point. Instead you mostly get a larger blast radius when the front-end ecosystem has its monthly identity crisis. OP's "stacks-du-jour" and programming language "flavour of the month" framing is exactly right. A shocking amount of web software architecture is just following fashion trends dressed up as technical decision-making.
Most of the churn in tech stack isn't driven by engineering requirements, it's driven by résumé optimization and Hacker News anxiety. Rails has quietly been powering serious businesses the whole time. Does anyone think NPM's 3.1 million packages enable more functionality than RubyGems' 190,000 packages?
We've also been running Rails in production for 15+ years (since 2011) in two companies and it has been serving us greatly. Hiring is tough, but I definitely believe the stack makes up for it due to the productivity gains.
In late 2025 we decided to migrate one of them to Inertia. Public facing pages is already done, and we're 80% through migrating the logged in area (it's a huge app). We choose Vue.js.
It's amazing how powerful this stack is and how little you have to change in the backend.
I'm surprised hiring is tough. The job market is such trash rn and I feel there are a lot of Rubyists, or ex-Rubists interested in returning to it, around. Maybe not? (Edit: spelling)
Well ya, I'm just saying I'm surprised considering the current job market. I moved on from Rails about 5 years ago now, but have 9 years experience under my belt and still keep up a bit with new things and play with them once in a while. And yet I've applied for several Rails positions in the past few years and always get an outright rejection.
I'm availabe! On rails for over 21 years since version zero. It's strange, but true, that we Rails-devs are hard to find. I apply for Rails-related roles and am competing with over 1,000 other resumes. I'm not sure how I fail to even get a screening call 99% of the time. Perhaps overqualified? Perhaps poor filtering? It is a very strange job market.
I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems.
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.
I'm working on a large (at least 300k+ loc) Django code base right now and we have 32 direct dependencies. Mostly stuff like lxml, pillow and pandas. It's very easy to use all the nice Django libs out there but you don't have to.
I was talking about total deps, not direct. By installing something like Celery, you get 8-10 extra dependencies that, in turn, can also have extra deps. And yeah, extra deps can conflict with each other as well.
That is obviously true but doesn't mean as much as you seem to think. Washing laundry is also not much work but it adds up to a lot over the years, especially if you skip a few weeks of laundry every once in a while. That is not an excuse to not do it.
The answer is the same in both cases: acquire some discipline and treat maintenance with the respect it deserves.
It is easy, and people tend to do what is easy. It takes more effort to minimise dependencies. Your boss or your client will not even notice.
Obviously there are some dependencies that you cannot easily avoid (like the things you mention). On the other hand there is a lot off stuff used that is not that hard to avoid - things like wrappers for REST APIs are often not really necessary.
Sometimes I think the issue here is churn. Security fixes aside, what is it that updated dependencies really give? Can't some of these projects just... stop?
The issue with that is, that the longer you wait to upgrade dependencies, the more pronounced the problems upgrading it will become generally speaking, because more incompatibilities accumulate. If those 5-6 year old projects were updated every now and then, then the pain to get them updated would be far less. As you point out, security is an aspect too, so you can leave the project inactive, but then you might hit that problem.
Dependency hell. Usually how it goes is you have to develop a new feature, you find a library or a newer version of the framework that solves the problem but it depends on a version of another library that is incompatible with the one in your project. You update the conflicting dependency and get 3 new conflicts, and when you fix those conflicts you get 5 new conflicts, and repeat.
I agree, but let's say you are looking for a library to solve your problem - you see one repo updated 2 weeks ago and the other one updated 5 years ago - which one do you choose?
Do I need a library to sort an array? The 5 years ago option is going to be the more likely choice. A library updated 2 weeks ago is highly suspicious.
Do I need a library to provide timezone information? The 2 weeks ago option, unquestionably. The 5 years ago option will now be woefully out of date.
The real issue with Rails apps is keeping up with the framework and language versions. There are really two categories of dependencies.
One-off libraries that don't have a runtime dependency on Rails are typically very low-maintenance. You can mostly leave them alone (even a security vulnerability is unlikely to be exploitable for how you're using one of these, as often user input isn't even getting through to them). For instance a gem you install to communicate with the stripe API is not typically going to break when you upgrade Rails. Or adding httparty to make some API requests to other services.
Then there are libraries that are really framework extensions, like devise for authentication or rspec for testing. These are tightly coupled to Rails, sometimes to its private internals, and you get all sorts of nasty compatibility issues when the framework changes. You have to upgrade Rails itself because you really do need to care about security support at that level, even for a relatively small company, so you can end up in a situation where leaving these other dependencies to fester makes upgrading Rails very hard.
(I run a startup that's a software-enabled service to upgrade old Rails apps).
I think you could only get around this by forcing your whole dependency chain to only add non-breaking security fixes (or backport them for all versions in existence). Otherwise small changes will propagate upwards and snowball into major updates.
"Security fixes aside" is too dismissive. Transitive dependencies with real CVEs can feel like the tail wagging the dog, but ignore them at your peril.
I have not had this experience as badly with Laravel. Their libraries seem much more stable to me. We've gone up 5 major versions of Laravel over the last year and a half and it was pretty simple for each major version.
I have plenty of RoR in production with millions of users, yearly we upgrade the projects and it's fine, not as catastrophic as it sounds, even easier with Opus now
My experience has been the opposite, especially since Rails has included more batteries over the years. You need fewer non-Rails-default dependencies than ever, and the upgrade process has gotten easier every major version.
Rails is way more stable and mature these days. Keeping up to date is definitely easier. Probably 10x easier than a Node/JS project which will have far more churn.
I also think it's the opposite, since the dependencies are almost guaranteed to be compatible with each other. And I think Ruby libraries in particular are usually quite stable and maintained for a long time.
My medium-sized Django projects had close to 100 dependencies, and when you want to update to a new Django version, the majority of them must be updated too.
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.
It really depends how they were built. I have large Django apps running for a very long time that require minimal maintenance, but it’s because we were very deliberate about dependencies.
But I learned to do that by working on codebases that were the opposite.
Different experience with Django. I am only using a handful of deps. dj-database-url, dj-static, gunicorn, psycopg are the only "mandatory" or conserved one IMO as a baseline.
It used to take at least a day of work. In a post-2025/11 world, it is under an hour. Maybe even 15 minutes if you've landed on a high quality LLM session.
The upgrade story is underrated. I've maintained Next.js projects where major version upgrades broke fundamental patterns (pages router → app router, completely different data fetching). Rails' deprecation-then-removal cycle is slower but way less disruptive. When you're shipping product, stability of the interface you build against matters more than having the latest paradigm.
This is the thing people who haven't run a Rails app for years don't appreciate. I went through the Next.js pages router to app router migration on a production app. That wasn't a version bump, it was a rewrite across a different mental model.
Rails upgrades are painful but the path is documented, the deprecation cycle gives you a full minor version to fix warnings before they become errors, and the team usually knows where the sharp edges are.
The Ruby version management story is actually solid too. rbenv/asdf pin files make it hard to accidentally run the wrong Ruby version, which removes a whole class of environment drift issues you don't even realize you have until you've fixed them.
Switching from Next's pages router to app router (RSCs by default) is a major shift in architecture, practically replatforming. Not to be taken lightly (and an opportune time to consider less-opinionated modern alternatives, like TanStack Start).
The "one-person framework" thing is a big draw. I'm amazed at how productive I was in it, and it's not just at the code level. Even though I've been doing sysadmin/devops/architect work for over 25 years now, it's just so damn nice now not to have to think about e.g. standing up a HA PostgreSQL cluster or Redis and deployment is largely a solved problem.
There are two types of devs: those that ship and those that fill out surveys (and not because their stacks are so much more efficient that they have time to fill out the surveys)
I was part of building the streaming frontend for one of Sweden's largest broadcasters in Rails about 10 years ago. Handled 1M+ concurrent users on Heroku with horizontal scaling. Fun fact: someone on the team literally stayed up monitoring traffic during big live events. It worked. Rails was a great fit for that especially at the time.
I moved on, not because Rails failed me, but because the things I started building next (Streaming infra, APIs behind proxies, lots of concurrent HTTP work, infrastructure tooling, AI/ML) just fit better in other languages. I pick tools by the problem, not loyalty.
What I notice in this thread is a lot of "Rails vs X" framing when the real answer is boring: use Rails (if you like the vision and Ruby) when the complexity is in the data model and business logic. Use something else when it's in concurrency or infrastructure. The one-person-framework pitch is real, but it's for a specific shape of problem.
Also: God i miss writing Ruby, its a fantastically and beautiful language.
Also: Blast from the past: Ruby is a great DSL for Rails.
Good advice that I keep trying to adopt myself, but I have to confess a large personal bias for languages that I like, even if it keeps me from certain classes of problem (I like Ruby, though).
What did you move onto for those next things you started building?
I know that feeling. Just because a tool is good doesn't mean you enjoy using it.
I moved deeper into streaming infra with Python, C/C++, Go, and funnily enough Elixir. Then a complete path change into fintech and later AI/ML, which meant a lot of JavaScript/TypeScript and reluctant Python. I appreciate the Python ecosystem but find the language itself ugly to read and write. Always a last resort for me.
Today it's mostly TypeScript, Go, and Lua.
Ha, I can relate WRT Python. I've been doing more Elixir these days for both a really pleasant web experience and because it has some unique primitives baked into the ecosystem that most JVM projects I work on spend a lot of time approximating through grotesque frameworks.
Ha, same. I wrote a VOD transcoding orchestrator in Elixir that triggered libav transcodes and custom packaging code in Python. Loved the syntax, and in particular the pattern matching in function headers. It was so clean for recursive branching that I ended up favoring recursion over conditionals and loops everywhere. Whether that was overuse or just good taste is subjective.
We did hit a real scaling problem with the BEAM though. Distributed Erlang uses a full mesh, every node connects to every other node. When we got close to 50 nodes the inter-node communication overhead was eating a significant chunk of our CPU. Adding more nodes started giving diminishing returns because the mesh traffic grew faster than the compute we gained. Interesting constraint that I haven't hit in any other runtime since.
I've never used Rails, but I agree upon "the state of the modern landscape". Instead of looking backwards, I tried to look forward, and what I found was Elixir and the Phoenix framework.
You're about the 5th person now in as many days who has recommended Elixir when I mentioned I was building a project in Ruby. I'll definitely have to check it out for my next project (whatever that may be!)
Can you expand on why you found it so appealing or "holy crap, this is awesome" things I should look at first ?
Not the guy, but I used rails at my old job for one and a half year, and used it in some personal projects. I looked into Elixir(and Phoenix) during this time, and Phoenix felt like it was designed for more modern websites, where RoR is built for older and tries to adapt to handle modern ones. It just feels that when you want to do something more responsive in Elixir, it's designed for it, but in Rails, it feels like you're doing something unorthodox or something that is added as an afterthought. Obviously this isn't quite accurate, but it is the vibe I got.
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.
Counterpoint on the "going all-in": we have a 7 year old Elixir/Phoenix project that currently sits at ~100K LOC and I couldn't be happier.
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.
Not OP, but I made the move from Ruby/Rails to Elixir years ago, so I'll try to answer from my perspective.
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.
Something I never quite understood: differentiate between BEAM process and operating system process. The OS has launched one (in theory) BEAM Erlang VM runtime process with N threads; are we saying “process” here to try to emulate the OS process model internally within the BEAM OS process, when really we’re talking about threads? Or a mix of threads and other processes? I’m imagining the latter even cross network, but am I at least on the right track here?
A BEAM process is not an OS thread. The way I understand it, a BEAM process is just a very small memory space with its own heap/stack, and a message system for communication between BEAM processes.
The BEAM itself runs multiple OS threads (it can use all cores of the CPU if so desired), and the BEAM scheduler gives chunks of processing time to each BEAM process.
This gives you parallel processing out of the box, and because of the networking capabilities of the BEAM, also allows you to scale out over multiple machines in a way that's transparent to BEAM processes.
When I first started out with Elixir, it was more the overall architecture that first sold it to me. It is remarkably robust, my impression is that you can more or less yank RAM modules out of the server while it is running, and the last thing which will crash is Elixir. And it is absolutely top in class when it comes to parallel processing and scaleability. Not only how it does it internally, but also how it abstracts this in a way that just makes sense when you are working with it.
When it comes to web development specifically, what really got me hooked, was LiveView from the Phoenix framework. It keeps a persistant WebSocket connection to the client which it uses to push DOM updates directly. Instead of the usual request/response cycle on the client side, the server holds the state and just pushes the diff to the browser. It just made so much sense.
I am/was a huge Ruby fanboy, and I used Rails a lot and loved it (though had some criticisms around too much "magic"). I made the jump to Elixir/Phoenix around 8 years ago, and have loved it. Phoenix to me basically "fixed" all the things I didn't like about Rails (basically opacity and hard-to-find-where-it's-happening stuff due to someone metaprogramming aggressively). I will admit that I've been a functional programming fan for a very long time too. I always write my ruby code in a functional style unless there's a good reason not to (which is increasingly rare).
I still love and use ruby a ton for scripting, and still reach for Sinatra for super simple server needs, but Phoenix is my go-to stack these days.
I've also found the Elixir community to be amazing in the same ways the Ruby community is/was. It's not all roses, for example there's not as many libraries out there. Distribution is also not awesome so for example I currently use ruby or rust when writing CLIs. But for anything distributed (especially web) Phoenix is amazing.
This is a self plug, but I did a conference talk introducing Ruby veterans to Elixir/Phoenix some years ago. It's probably aged a bit, but should still be pretty accurate. https://www.youtube.com/watch?v=uPWMBDTPMkQ
The original conference talk is here (https://www.youtube.com/watch?v=sSoz7q37KGE), though the made-for-youtube version above is better because it's slightly updated, and I didn't run out of time :-)
I had a project I already tried out in Symfony and then full typescript, both a normal REST setup and ORPC. They all felt like - at scale - they became messy and I was unsure where goes what.
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 usually go full Symfony with my projects until I need to spread it out. But even for interactivity, I first go for htmx and Alpine.js instead of full React or so, where I then need to setup API on backend and frontend.
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".
I totally agree. At my first job, they instantly jumped towards Symfony and AngularJS. Sounds good, but they could've totally gone for something more lightweight. They DID NOT NEED the complexity AngularJS (and Angular2) brought them. When I left I tried my best to update to at least an LTS version, but I did not succeed and they did not care. I believe they're now migrated to Angular2 but are already stuck in hell
Rails for straight up CRUD is top, autogenerated things etc
however if your app doesn't fit the standard crud pattern you end just fiddling with a lot of things that you shouldn't and in that case I recommend Django which provides enough flexibility while providing a good base. There's less magic in Django
Serious question, as someone who started his professional developer career as a RoR developer in 2012: Isn't vibe-coding top for straight up CRUD?
I'm not trying to be glib. The thing that seemed magic to me at that time was all the scaffolding that Rails provided with a few simple commands, making it possible to quickly build something that let the user authenticate and enter and display data. Sure, Ruby itself and the culture around it back then was also great and will always have a place in my heart. But the whole convention-over-configuration and scaffolding thing, that was what I liked so much about it, and I never found that in any other language/framework combo in a way that felt as smooth.
But now, I use AI for scaffolding, and for my side-projects often never have to touch code.
So why would I choose something for a CRUD application that might give me headaches down the road, when there's a possibility that the app might morph into something less conventional, when I could use *any* language/framework that's not as rigid and have the scaffold be built by AI?
I get it if you enjoy actually writing code. But I don't quite get the benefits if the goal is to have something working quickly and be able to potentially build it out to something that is not served that well by RoR.
If you're building a pure SaaS app then Rails is perfect. If you need SaaS + more complex backend services like coordinating tons of webhooks I'd choose Elixir. Documentation sites and light server apps I'd use Node.
Go and Rust fill in lots of gaps for more serious performance stuff.
FWIW modern Rails is fairly magic-free also. They learned. With ActiveJob now part of the framework you get event queues/async processing and whatnot as part of the batteries.
I'm a fanboi, so I am biased, but Rails is still pretty great in 2026 for general business purposes.
To all the folks in here that bemoan the lack of static types, I'd like to mention there are some great solutions in this space, eg. https://sorbet.org/
Having the productivity of Ruby + the static typing and LSP integrations is a wonderful combination. Sure, it might be less aesthetic than some might like, but at least in my experience, it works very well in practice and supports most of the needs I have from a type system for writing and understanding conventional software.
I'm rooting for further developments in this space because I love language and systems that can leverage it's strengths and layering on a type system makes it a very formidable technology for building real world products.
I have not used Rails in a few years, but I can also say that the Sorbet typing support for the framework is definitely there too -- to great credit to the folks at Shopify allowing users of the framework to benefit from this tooling.
I would happily work on a Rails system today too. It's an amazing testament to the community how the design has been able to continue to develop to meet the needs of the many developers building with it up to this point. I hope more people feel the same joy I do discovering the kinds of things they can make with the language and frameworks like Rails.
With the amazing advancements with the AI tools we have now the only real limits are with how big our imaginations and ambitions can get.
I spent 2024 and 2025 trying all the big fullstack monolithic frameworks (Laravel, Rails, .NET, Django). There are differences of course but they all suck so much for doing frontend.
In part because for a modern frontend dx you will need hot reload, bundling, etc. But even if you make an SPA and only use eg .NET for an API, using something like OpenAPI to share the schema is a subpar solution. There's really nothing as good as sharing TS types across your whole app(s).
"I have a tendency to go down rabbit holes when faced with problems - give me a minor inconvenience and I’ll happily spend weeks building something far more elaborate than the situation warrants."
You don't know how happy I was to read this... I thought I had a serious problem with getting distracted with my "projects" but it seems this is much more normal than I thought ;-)
One thing that is not stressed enough, is Rails enforces good code patterns early on. If you follow the docs, you will know where model code should be, helpers should be, controllers should be. After all, it is an MVC framework.
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.
The difference between JS frameworks and RoR/Laravel is the ecosystem cohesion. RoR and Laravel ecosystems employ the RoR or Laravel way of doing things and everything works together very smoothly.
JS solutions are loosely coupled, lots of good reasons to do so, but comes at a major complexity cost.
Eh, there's NestJs and AdonisJs if you want opinionated MVC with lots of built-ins like CSRF and ORMs.
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.
Adonis is over 10 years old... that's like 3 generations in software years, and 20 generations in web/Javascript.
The reason it's lacking features is because it's not very popular and hasn't gotten much outside contribution... I seem to also recall something about the founder being too hostile to outside ideas/suggestions also, but I could be misremembering
Javascript frameworks just do SSR + Express-style api routes. They don't handle SQL injection prevention because they don't deal with databases at all. CSRF prevention is less important in todays world tho.
it's like you're saying SQL injection happens if you're running sql on the client so if it's on the server you're fine.
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.
SQL injection is prevented by using database APIs properly, not sanitizing. Put all the malicious SQL you want in a query string, if it's passed as a bound parameter to a prepared query, it's only ever going to be a plain string.
You might sanitize for different reasons like business logic, but if it's your first line of defense against sql injection, you're already on the losing side.
I don't get your point, I'm not saying sanitising user input isn't important, I'm saying these JS frameworks are only concerned with server rendering and routing. They don't provide any tooling for databases like Rails or Laravel do.
JS frameworks are very much in the "full-blown app" category.
As an example, the "react" is just a view layer is a purest pov, to me (or whatever the given framework in question is). Nextjs, Vercel, supabase, lovable, and so on down the line all empower millions of people to ship full-blown apps. We might get carried away with which specific layer is in question, but it doesn't matter if they're always used together to ship millions of (in)secure apps.
Going off topic, but the article made me look into "2025 Stack Overflow Developer Survey" and as usual there is the big difference between what the "Professional Developers" with and without AI claim to be using, and the usual HN discussions "X is taking over the world, no one uses Y anymore".
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.
Nothing wrong with Rails in 2026. We still use it for both internal and customer projects. I haven't yet encountered anything that made me feel like switching. I'm also not interested in changing frameworks just to have the New Hotness die in 2-5 years (our oldest currently maintained Rails project is over 10 years old, and some stuff I started working on when Rails 2 was new is still being maintained, just not by us)
I love rails and the recent improvements are great.
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
Javascript handling in Rails was easy in the early versions, then became messy with the asset pipeline and webpacker, and is becoming simple again with the latest versions
If have a different opinion on this, as I think it's 100x better to learn sql and just write it directly instead of using the dozens of leaky abstraction of some framework.
I mean, I've seen enough "django specialists" to end up with queries doing a dozen of join bombs and producing 10 million rows from dataset of maybe 1000 items. So pretty safe to add "ORM" to your last statement.
> 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.
Yes, I've seen that, too. The rails way of doing things can feel like a terrible limitation to some developers, while others enthusiastically embrace it
I always enjoyed Rails, it isn't perfect but is way better then others. I have node and nextjs projects :) when they blow it, it is a major mystery what is blowing up.
Have so many good memories working with Ruby.
If anyone has old codebase need to be updated and upgraded, refreshed. I am happy to do that.
ideally a JS frontend app won't show logic not intended for the user type in question.
in practice, really often I see a huge app covering all roles and cases, a trove of info for the red team. and even worse, the reality of software development with LLMs in 2026 is plenty of code is being shipped without security audit.
I know it's not an inherent fault of the JS frameworks. bit I share what I see on the streets, most of custom JS apps I see are way more vulnerable to hacking than a old-style MVC app.
yes it is possible to make mistakes in both styles, but in JS apps I probably see 400% more easily discovered vulnerabilities than in a common MVC (even with stimulus) app
> 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?
Author of the article here (hi! Anxiously watching my Grafana stack right now...)
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...
> 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
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.
There was a post last week about the best programming language for LLMs, and in the comments people loved Go, with the claim being it's very opinionated and there's really only one way of doing things. I'd say the same is mostly true for Rails apps as well.
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 having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types.
Very true for me as well. I've never worked with Ruby but feel the same way about Django.
Btw, if you're looking for a "Rails but with TypeScript," my colleagues and I are working on almost just that: https://wasp.sh/.
The main difference, besides the ecosystem, is that we're more in the "configuration over convention" camp. Wasp has a simple DSL for specifying said configuration, but it's about to be replaced with a TypeScript file.
Wasp is still in beta and nowhere near Rails-level polish. But, depending on your early adopter tendencies, you might find it interesting regardless. If you do try it out, please reach out and share your thoughts.
TS is very AI native to the point i'd agree it's near magical in terms of contract.
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.
> TS is very AI-native, to the point I'd agree it's near magical in terms of contracts.
I agree.
Not only that, I feel like TypeScript is currently the only popular high-level language with a type system capable of communicating all meaningful information. It seems to have hit an LLM sweet spot.
Looking at other candidates:
- Rust is popular and has a powerful type system, but it forces you to program at a level that's lower than necessary for most projects, hindering usability.
- Go is much more usable and very popular, but its type system can't communicate much.
- Haskell has an excellent type system, but it's nowhere near popular enough, and its usability suffers due to esoteric constraints (laziness, purity).
- etc.
I don't know the recent developments in Python's and Ruby's type systems. They may be able to compete these days, but they were nowhere near TS's level in terms of contract a few years ago when I last tried them out.
And I admittedly have no idea what's going on with C# and Java, but I'd love to hear about it.
Ruby has types with RBS and Steep now. It's a lot like using .d.ts sidecar files alongside JavaScript, via jsconfig.json configuring tsc. I like it a lot!
>The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective".
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.
doesn’t forcing your agent to think in ruby put it at huge disadvantage though? since the language isn’t that popular it can’t have learned it as well as say python or Java?
Python does have a bigger pool of examples, but agents usually get tripped up by missing context about specific frameworks more than by language syntax. The real obstacle for LLMs is understanding Rails' implicit conventions and magic, not the Ruby language itself.
>If we are all supposed to be talking to agents now, what's the difference[...]?
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.
Don't worry, it's just the hype phase and it will pass. (By 'pass' I mean agent-coding will be so ubiquitous that it's a given and not worth mentioning.)
I haven't found anyone pushing back on it at all, which has been making me a bit nervous! There was a HN post about it, though it didn't get any traction. [0] Seemingly nothing in any of the usual rails community areas either. It's going to make recommending rails confusing because that pitch really does make it unclear what rails is even aiming to do.
And yeah you're right, like what is the difference at that point? If the pitch is "AI agents write this", then the obvious response is "well why would I not use what has more training data then?".
both statements are true though. rails excels in the AI world because it's extremely cared for and intentional with language. and there's a ton of built up knowledge.
fwiw that headline is cringey for sure. but DHH has proven himself a great marketer. it very likely is riding the wave.
The upgrade path in Rails 8 is smoother than it's ever been, especially with the built-in solid adapters removing the Redis/Sidekiq dependency for smaller apps.
we run next.js on the frontend and the page router to app router migration was really painful. rails having stable conventions sounds very good when you go through something like that. I keep thinking about this trade off - move fast with the latest thing or just pick boring tech that works for 5 years.
yes exactly. we had to rewrite most of our data fetching logic. there was no real way to do it gradually, one day we just had to commit and do the whole thing. took way longer than expected.
try ActiveAdmin, it reduces work a lot. also, ruby is so succinct and rails is so opinionated, Opus is super effective building code and keeping the codebase well structured by default
Ruby and RoR is cool and all, but as these web apps got more and more complex, the need for static types became too important. What gave PHP it's edge was types and is the reason I'm still using it after nearly 20 years. PHP seems to implement those important things just in time. OOP, better OOP, types, speed boost, and next probably concurrency.
Is is the need for static types or the need for better testing that is not focused on coverage of line of code?
Because if the domain logic is getting more complex then more types will not catch the bugs unless you are willing for codify business rules within types so then you have to test the types.
i returned to rails in 2025 after 12 years pause and my experience has been frustration and annoyance
rails lost it's convention over configuration ways, the generated app is dozens of files, lack of explanations and guidance on how to setup various things like environments, kamal being the worst offender and the changes between recent major releases aren't making it any easier to read the (often ai slop) articles and docs
> Rails seems to have pretty much fallen out of favour, coming in at #20 underneath the bulk of top-10 JavaScript and ASP.NET frameworks
It's not just Rails. Ruby is dying. And has been for quite some years now.
The strangest things are people writing blog entries claiming the opposite. Like "ruby ages like fine wine". No, that is incorrect - it is dying. I have been using Ruby since about 2004 or 2005. I still use it just about daily. I started before Rails and couldn't care any less about Rails; sadly the ecosystem is infiltrated by corporations such as shopify and others. You can see how they took over RubyCentral effectively (and if they insinuate otherwise - nope, I am not an idiot. I see the pattern. I notice what is happening. You call a black cat a green frog and I call bullshit. It's a black cat. See RubyCentral running amok already before they mass-purged developers, but that's another story - let's go back to ruby, and rails.)
> And Ruby itself is nowhere near the top 10 languages, sitting just underneath Lua and freaking Assembly language in terms of popularity!
Yup. Ruby is dying. It is following perl.
Now, defining "dying" is hard because you still have an active community, even outside of the train wrek that is rails (anyone still caring what random crap DHH writes on his blog? I've noticed fewer people care about the garbage he publishes, other than making fun when shopify damages the ecosystem - oh wait, he sits on the board of shopify. Did I already point out how much damage shopify causes here?).
> But I’m a stubborn bastard, and if I find a technology I like, I’ll stick with it particularly for projects where I don’t have to care about what anyone else is using or what the latest trend is.
On this part I agree. Ruby as a language is very well designed. It is a great language. I don't think anyone really objects to this, so the criticism has to be split - some criticism is valid, some is not. As a language ruby is well designed.
Nonetheless it is dying too. That is also a factual statement. Anyone claiming the opposite is wrong. At the least this is the case right now, and has been in the last some years, to varying extent.
> realised Ruby was “a better Perl than Perl”.
Also true. Ruby is the better perl. But I actually call Ruby syntactic sugar over C, because this is actually what Ruby is, if you think it through. My use cases are mostly helper-scripts, tons of that, over whatever I do in general. Literally everything computer-related. That includes use cases for the world wide web. All my needs here are covered by Ruby - but not by rails. I don't need rails.
Sadly, ruby also has a second problem: documentation. The documentation is crap in general. Look at rack. Opal. WebAssembly for Ruby. That documentation is a joke. An insult. Even sinatra, though better documented than these, has a bad documentation for the most part. There are some exceptions; for instance, hexapdf is well documented, and Jeremy's projects are also well-documented. So I am not saying everything is poorly documented. But for a language that once claimed it wants to compete against python ... sorry, documentation-wise this is still an epic failure point. In some ways ruby actually deserves to follow the path to extinction like perl did, merely because it failed to adjust, adapt and really improve. Yes, there is some internal improvement, but in many ways ruby failed to solve the problems people critisized it for, for many years. And now catching up is SUPER hard. I don't think it can happen anymore. I thought it was possible 10 years ago, but the last 5 years made it clear that ruby is towards extinction. It still does not change me using it, since ruby covers my use cases, but anyone thinking there will be an influx of new young folk driving ruby forward, is just worshipping an illusion here.
> There’s just this minimal translation required between what I’m thinking and what I type.
That's true. Ruby is kind of transitioning your thoughts into code.
> Sure, I can knock things together in Python, Go, or whatever the flavour of the month is, but I always feel on some level like I’m fighting the language rather than working with it.
Kind of, though python works fairly well too.
> And of course there was the welcoming, quirky “outsider” community feel with characters like Why the Lucky Stiff and their legendary Poignant Guide To Ruby.
Well - _why ragequit when someone doxxed him. But even aside from this, I found
the poignant guide super-confusing. It was art, but I prefer less confusion
myself. Still, _why is gone from the ruby ecosystem. Supposedly he is still doing
computer-related stuff in reallife but he is no longer really affiliated with
ruby as such. Did I already point out that ruby is dying?
> it’s just so nice being able to write things like
unless date <= 3.days.from_now
I don't doubt that rails is useful, but code like that sucks. Rails
also came up with HashWithIndifferentAccess. This simply shows a lack
of UNDERSTANDING. They pushed the DSL madness way too far. Yes, I get
it, "I don't want to care if we have a string or a symbol" - easier
access. But it is the wrong THOUGHT process here. And just the name
itself ... HashWithIndifferentAccess versus Hash. Sorry rails guys -
you were not good designers in a general sense of the word. The DSL
may work; the DSL may be useful, but language or API designers? Nope,
sorry. It's awful.
if upload_size > 2.megabytes
I don't like this either, but I have less reservation here than compared
to using numbers for time/date. It's cool that ruby is flexible to allow
this, but I still think it is the wrong THOUGHT process.
> got Claude to generate the rest with some mockups of common screens and components.
And AI is doing the rest. The path to exctinction.
Does Claude make "scripting" languages obsolete? I mean that knowledge becomes less useful if AI autogenerates everything.
> This can be something simple like caching for a specific time period:
<% cache "time_based", expires_in: 5.minutes do %>
<!-- content goes here -->
<% end %>
I absolutely hate ERB. It is strange that it is such an integral part of rails.
I abandoned PHP for many reasons but one was the spaghetti problem.
Rail has the same spaghetti problem, though ruby is prettier than
PHP. Still, that spaghetti design is just awful.
> This is why services like Heroku and Pivotal Cloud Foundry thrived back then
Heroku is also in the process of dying. There were some recent discussions
about it on reddit as to why.
> While the Stack Overflow survey isn’t necessarily an accurate barometer of developer opinion, the positions of Ruby and Rails do show it’s fallen from grace in recent times.
It's not just SO though. TIOBE, despite being crap, also shows a similar trend. And if you research things, you notice many people moved on from ruby, for many reasons - often work-related.
> Anecdotally, I find a lot of documentation or guides that haven’t been updated for several years and the same goes for a lot of gems, plugins and other projects.
Yup. A dying ecosystem. I stopped using rubygems.org myself after Marty pushed the ecosystem into shopify's corporate pet project. 100.000 downloads and then your project is hijacked? Or the new shiny corporate rules? Nah. Go to corporate land and leave us alone, Marty. RubyCentral most definitely does NOT represent "the community". The original guys who wrote rubygems - now these were community folks, not some corporate ponicorns. Sadly when money is tight, bad things happen, and the ruby ecosystem showed this beautifully. Kind of bad too because it means money wins over community; but this is a chicken-egg problem, because how to grow a community if the trend goes downwards, for whatever the reason(s)?
> And I find that most gems follow a similar downward trend of activity.
Yup - but this is also old, even before RubyCentral transitioned into CorporationCentral. Ruby folks left ruby, years ago already. The people I knew from, say, 2005 to 2012 or so, also from IRC - some still use ruby, but most moved on to other things (also for financial reasons usually).
> Rails on the other hand actually seems to be picking up steam and has been remarkably consistent since the big “boom” of Rails 3.0 in 2010
Nope. Rails is also dying. It does not have the same 1:1 problem as ruby has, but
the decline is 100% there too.
> Rails is a rare example of an OSS project that’s grown into its release cadence rather than burning out.
Not really. Ignore the promo. Look at the facts. Rails has been hurting too (which makes DHH laughing about when RubyCentral mass-purges developers both evil and silly, because that hurts the whole ruby ecosystem too - what was shopify thinking here?).
> Whether it can still find an audience amongst new developers is an open question
Yeah that is the question. Unfortunately the answer is there: new developers won't use ruby for the most part. AI also competes here now.
2026 is not like 2006, sorry folks.
> I probably could eventually build things almost as fast in another language or framework, but I doubt I’d be smiling as much while I did so.
Well, I used perl, php, python (still use python too). Ruby is more efficient for my brain though. And I disagree that I could be as fast as in another language. I simply have fewer barriers when writing ruby for the most part. Less restrictions. I don't think anyone thinks ruby itself is a bad language at all. We need to keep the discussions separate.
Pretty good comment from Mark Dastmalchi-Round by the way. Well-written, tons of details, opinions - even if I may disagree with some points, the overall quality of his blog entry is very good. We should give him very good marks for the blog - even more so as it is not on medium.com. I hate medium.com (and the link above, is to medium.com ... why did I link it ...)
is this really relevant anymore now that AI has gotten to the level it has? what used to take weeks to setup now take days (react, multiple backend services and infra)
Very relevant, because it typically takes a lot less code to express a feature in Rails/Hotwire than it does in a SPA with a dedicated back end. No need to maintain API contracts or ensure your UI code is properly async/awaited, etc., etc. Whether its a human or AI writing the code, SPA's add considerable complexity that just isn't necessary for most web apps.
Lower LOC to express a feature means better context management which pays dividends for things like code review.
This "feels like" first sentence / "curious if" ending question patterns seems to be coming from some LLM? I have seen the same across several online communities suddenly and frequently as of a few weeks ago. Notably the use of "I've seen" and "feels like" suggest the model is either prompted to act as a person or is one of the older models not strongly trained not to.
Nah read my own comment history. I tend to phrase things this way a lot too because it positions it as opinion/curiosity rather than arrogant / confident statement?
Remember only one programming language delivers developer joy - Ruby.
No other programming language brings developer joy because……. errrr because ……. Well because we are just super certain and confident, that’s why! Oh and DHH said so.
I’m honestly baffled by the praises of Rails in the comments.
I started my dev career with php and then nodejs, but recently got a job with rails, and honestly, it’s the worst among the 3.
There is no static typing whatsoever, it’s littered with magically generated methods, on a moderate size project the controllers or models directories grow to dozen of files. In general it feels like you need a lot of mental context in order to work with Rails, and I believe this is the reason people who run it for 10+ years in production love it. They simply carry all the magic in their heads, rather than let the framework guide you.
I, however, get much more DX and production stability by building with a boring (router + server side rendering) NodeJS stack with typescript and schema validation. My services are more stable and do not crash on “undefined method foo for nil”.
I guess people will defend whatever they know best, even if it has quirks.
On a positive note, I like ruby as a language. It has cool features like pattern matching, named arguments, or dropping verbose statements like “return” at the end of the function.
I love Rails, but after working for a few places with huge Rails codebases and then several other places with .NET and other frameworks with actual typing, I just can't go back to Rails for anything that isn't a personal project.
Working with a large codebase with an untyped codebase is just a nightmare, even with powerful IDEs like RubyMine that are able to cover some of the paint points. I wonder how good Sorbet is these days, though, especially the RoR experience
Rust/Loco is unironically the most interesting framework right now.
Loco follows up the Rails formula pretty closely, and makes easier to learn Rust by taking care of a load of boilerplate code.
Concur on most interesting! I really hope it works out, but am cautious.
It is surprising to me seeing the rust web backend scene; many libraries, server frameworks, and users, but they are all Flask-analogs, without the benefit of the reasonably-robust ecosystem Flask has. My suspicion is that people are using them for micro-services and not websites/webapps, but I haven't been able to get a straight answer on this about how people are using these tools. I.e. even though rust is my favorite overall language and see no reason it couldn't be used for web work, I still use Django.
Axos, Axum, Rocket, Diesel etc, are all IMO not in the same league as Django. My understanding is that addressing this is Loco's Raison d'etre.
Another aspect of the Rust web ecosystem: It's almost fully gone Async.
It's quite a gap really.
I'll say this, coding agents make the lack of a "batteries included" framework like rails or Django somewhat less daunting.
But "convention over code" and having a default structure / shape for projects is extremely helpful and you feel it when it's missing.
For my last small project I looked at Loco but ended up passing on it because I felt like adoption wasn't great yet. I really hope it takes off, though.
It's really hard to get away from ssjs frameworks for front-end, so for my startup it's Axum + Seaorm for "the api" and a Svelte SSR "front end" / view layer.
I think rust programers are more likely to want flask/rack than Django/rails.
I'm at a point now where I'm not even a little interested in new frameworks. I want tried and tested. Preferably something that has been around for 15 years.
I worked with Rails a lot. In my experience, every rails dev who is fanatical about how much they love Rails, also has little to no experience with strong types. Of the ones who later try types, they no longer love Rails. Personally I quit Rails entirely because of lack of types. No, RBS and Sorbet are not even close to good enough.
Also, every enterprise rails app I've seen (seven, to date) has been really poorly written/architected in a way that other backends just weren't. Even the fairly new ones felt like legacy code already.
I still really like rails. It’s really fun until your codebase reaches a certain size. At that point you better have a large suite of test which becomes a problem of it self because the tests will take forever to complete.
I tried sorbet a couple of times and totally get why it’s useful but imo it’s not just lacking (e.g. compared with what can be done with TS or even a simple type system like golang) but it also removes all the fun parts of ruby / rails.
Right, the test culture is very silly to me. Thousands of tests and long CI times, basically just doing a poor invention of a compiler. Dynamic types are so much extra work.
Ruby is a strongly typed language. I think you are confusing strong typing with static typing.
And by contrast, C is static but weakly typed.
It's not just the untyped problems, the runtime definitions of functions, properties, etc make it nearly impossible to debug unless you have the state of your production data locally. (Or you ssh into your prod server and open up a REPL, load the state and introspect everything there). Good luck debugging locally in a nice IDE. It's a horrific nightmare. I use to love Ruby until I had to debug it live.
Yeah, dynamic typing is one thing, but the magical dynamic imports into the processes globally scoped namespace add another level to debugging difficulty.
At least in Python (as a comparison example), imports are only available in the module doing the importing - it's more explicit. You'd have to really work to get the same "everything all at once" as Rails has.
What is it about large untyped codebases that make it a nightmare?
If you make a change to the return types of a function for example you have to manually find all of the different references to that function and fix the code to handle the change. Since there are no compile time errors it's hard to know that you got everything and haven't just caused a bug.
Yes, and the downsides cascade. Because making any change is inherently risky you're kind of forced not to make changes, and instead pile on. So technical debt just grows, and the code becomes harder and harder to reason about. I have this same problem in PHP although it's mostly solved in PHP 8. But touching legacy code is incredibly involved.
Especially with duck-typing, you might also assume that a function that previously returned true-false will work if it now returns a String or nil. Semantically they’re similar, but String conveys more information (did something, here’s details vs did(n’t) do something).
But if someone is actually relying on literal true/false instead of truthiness, you now have a bug.
I say this as a Ruby evangelist and apologist, who deeply loves the language and who’s used it professionally and still uses it for virtually all of my personal projects.
The best perspective I've seen is that statically typed enforcement is basically a unit test done at compile time.
Alan Kay's argument against static typing was it was too limited and didn't capture the domain logic of the sort of types you actually use at a higher level. So you leave it up to the objects to figure out how to handle messages. Given Ruby is a kind of spiritual ancestor of Smalltalk.
the problem is that nobody listened to Alan Kay and writes dynamic code the way they'd write static code but without the types.
I always liked Rich Hickey's point, that you should program on the inside the way you program on the outside. Over the wire you don't rely on types and make sure the entire internet is in type check harmony, it's on you to verify what you get, and that was what Alan Kay thought objects should do.
That's why I always find these complaints a bit puzzling. Yes in a dynamic language like Ruby, Python, Clojure, Smalltalk you can't impose global meaning, but you're not supposed to. If you have to edit countless of existing code just because some sender changed that's an indication you've ignored the principle of letting the recipient interpret the message. It shouldn't matter what someone else puts in a map, only what you take out of it, same way you don't care if the contents of the post truck change as long as your package is in it.
That's a terrible solution because then you need a bunch of extra parsing and validation code in every recipient object. This becomes impractical once the code base grows to a certain size and ultimately defeats any possible benefit that might have initially been gained with dynamic typing.
>then you need a bunch of extra parsing and validation code in every recipient object.
that's not a big deal, when we exchange generic information across networks we parse information all the time, in most use cases that's not an expensive operation. The gain is that this results in proper encapsulation, because the flipside of imposing meaning globally is that your entire codebase is one entangled ball, and as you scale a complex system, that tends to cost you more and more.
In the case of the OP where a program "breaks" and has to be recompiled every time some signature propagates through the entire system that is significant cost. Again if you think of a large scale computer network as an analog to a program, what costs more, parsing an input or rebooting and editing the entire system every time we add a field somewhere to a data structure, most consumers of that data don't care about?
this is how we got micro-services, which are nothing else but ways to introduce late binding and dynamism into static environments.
> when we exchange generic information across networks we parse information all the time
The goal is to do this parsing exactly once, at the system boundary, and thereafter keep the already-parsed data in a box that has "This has already been parsed and we know it's correct" written on the outside, so that nothing internal needs to worry about that again. And the absolute best kind of box is a type, because it's pretty easy to enforce that the parser function is the only piece of code in the entire system that can create a value of that type, and as soon as you do this, that entire class of problems goes away.
This idea is of using types whose instances can only be created by parser functions is known as Parse, Don't Validate, and while it's possible and useful to apply the general idea in a dynamically typed language, you only get the "We know at compile time that this problem cannot exist" guarantee if you use types.
> The goal is to do this parsing exactly once, at the system boundary
You are only parsing once at the system boundary, but under the dynamic model every receiver is its own system boundary. Like the earlier comment pointed out, micro services emerged to provide a way to hack Kay's actor model onto languages that don't offer the dynamicism natively. Yes, you are only parsing once in each service, but ultimately you are still parsing many times when you look at the entire program as a whole. "Parse, don't validate" doesn't really change anything.
> but under the dynamic model every receiver is its own system boundary
I'm not claiming that it can't be done that way, I'm claiming that it's better not to do it that way.
You could achieve security by hiring a separate guard to stand outside each room in your office building, but it's cheaper and just as secure to hire a single guard to stand outside the entrance to the building.
>micro services emerged to provide a way to hack Kay's actor model onto languages that don't offer the dynamicism natively
I think microservices emerged for a different reason: to make more efficient use of hardware at scale. (A monolith that does everything is in every way easier to work with.) One downside of microservices is the much-increased system boundary size they imply -- this hole in the type system forces a lot more parsing and makes it harder to reason about the effects of local changes.
> I think microservices emerged for a different reason: to make more efficient use of hardware at scale.
Same thing, no? That is exactly was what Kay was talking about. That was his vision: Infinite nodes all interconnected, sending messages to each other. That is why Smalltalk was designed the way it was. While the mainstream Smalltalk implementations got stuck in a single image model, Kay and others did try working on projects to carry the vision forward. Erlang had some success with the same essential concept.
> I'm claiming that it's better not to do it that way.
Is it fundamentally better, or is it only better because the alternative was never fully realized? For something of modern relevance, take LLMs. In your model, you have to have the hardware to run the LLM on your local machine, which for a frontier model is quite the ask. Or you can write all kinds of crazy, convoluted code to pass the work off to another machine. In Kay's world, being able to access an LLM on another machine is a feature built right into the language. Code running on another machine is the same as code running on your own machine.
I'm reminded of what you said about "Parse, don't validate" types. Like you alluded to, you can write all kinds of tests to essentially validate the same properties as the type system, but when the language gives you a type system you get all that for free, which you saw as a benefit. But now it seems you are suggesting it is actually better for the compiler to do very little and that it is best to write your own code to deal with all the things you need.
> I think microservices emerged for a different reason: to make more efficient use of hardware at scale.
Scaling different areas of an application is one thing. Being able to use different technology choices for different areas is another, even at low scale. And being able to have teams own individual areas of an application via a reasonably hard boundary is a third.
Is that a common issue? I guess I'm having a hard time imagining a scenario that would (a) come up often and (b) be a pain to fix.
Anything can return anything and you only realize it at runtime is a massive headache. When you can't keep the entire code base in your head it becomes a liability.
I never used Ruby, but Python code bases love mixing in strings that are actually enums and overloading functions that accept all kinds of types. You just had to hope that the documentation was correct to avoid a crash.
Java 1.7 to Python feels very freeing from all the boilerplate. Kotlin, or any other modern language with a well designed standard library, to Python just feels like a bunch of extra mental work and test to write to just avoid brackets.
When CI/CD becomes your compiler you are in a tough spot
It makes coming up to speed on an existing codebase a slog because you have to trace through everything back to its source. Oh, and because there are magic methods and properties galore, your normal introspection tools in e.g. RubyMine get frequently stymied.
Same. Also became a .net developer after almost 20 years of Ruby/Rails.
Nowadays C# is anyways much more expressive than before. Meanwhile Ruby is still very slow.
Not to mention how poorly maintained are most Rails projects. People have been "vibe coding" forever.
A well-organized and maintained Rails app is great though. I'd definitely consider working with it again, but it really depends on what company it is.
[flagged]
Is this still a valid take after the study that came out,showing how Ruby performs way better with agentic coding?
https://ihp.digitallyinduced.com/ is a rails-inspired framework for Haskell that tries to get the best of both worlds. Highly recommend trying it if you have a weekend
Also the language/framework is mattering less by the day with agentic coding.
Why would anyone ever choose ruby, python, etc when you don’t need to write it?
These languages are undoubtedly dead as of now. Python may live on in ML for a bit but probably not much longer
Ruby has "undoubtedly" been dead for at least a decade now, or so I've heard. Glad to hear Python is undoubtedly joining the party.
Least informed comment Ive read here
"Agentic coding has been viable for the last decade"
I’ve worked in two places now with Ruby Sorbet servers. Ruby always drives me nuts how things are just in-scope and we don’t know why or where they came from.
I certainly wouldn’t want to go back to working in dynamic languages without typing on top. That takes too much brain power, I’m too old for that now.
I would say Sorbet seems more “basic” than something like Typescript. It handles function calls matching signatures, potential nulls, making sure properties actually exist, that kind of thing. Whereas TS can get quite abstract, and at times you’re fighting to convince it that a value actually is the type you say it is.
TS is very powerful and expressive, to the point that it’s possible to do computation within type code. I’m not convinced I always need that power, or that it’s always more help than hindrance.
> Ruby always drives me nuts how things are just in-scope and we don’t know why or where they came from.
irb(main):005:0> Foo.new.method(:bar).source_location => ["tmp/test.rb", 5]
[dead]
You appear to be shadow banned. Letting you know since I didn't see anything egregious on a quick scan. Maybe contact HN and plead your case.
I vouched for your reply below, and to answer in the meantime:
Yes, it's runtime, but that only matters if your code can't be initialized without unacceptable side effects.
In which case you don't have a functioning test suite either, and have much larger problems.
Otherwise, just load the code you struggle to figure out into irb, or pry, or a simple test script, and print out source-location.
If that is impossible (aside from the fact that codebase is broken beyond all reason), the marginally harder solution is to use ruby-lsp[1] and look up the definitions.
This is only hard if you insist on refusing to use the available - and built in, in the case of source_location - tooling.
1: https://shopify.github.io/ruby-lsp/
> I certainly wouldn’t want to go back to working in dynamic languages without typing on top. That takes too much brain power, I’m too old for that now.
> and at times you’re fighting to convince it that a value actually is the type you say it is.
Might just be allocating that brain power to the same task but calling it a different thing.
[dead]
Are you hand coding?
Are we that far gone that "hand coding" is a term now? I hope there's an /s missing
I hope "hand coding" is an antonym for "convention coding" or something.
I’m guessing hand coding means, not vibe coding.
Did you use AI? .. Nah I hand coded it.
Well, yes. I was trying to comment in spirit of parent comment.
Real programmers use butterflies. https://xkcd.com/378/
Doesn't matter because LLMs also benefit greatly from typed code bases in that they can run the type checker and fix the problems themselves on a loop.
I haven’t seen much discussion about this point other than “llm handle languages x y and z because there’s a lot of training data”. Watching Terence Tau using llm for writing proofs in Lean was a real eye opener in this regard.
Both Claude and Codex handle Ruby just fine.
Thanks for such public confirming there is a lot of more us. I’m just tired hearing how great ideas will save our overblown pseudo-microservice architecture and I’m also running into some projects during evening that just solve problems without use STOA, unnecessary solutions and architectures.
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.
I've just started using RoR for a live greenfield project since New Year.
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.
I have my complaints about the JS/TS ecosystem, but I'm surprised to see a comment that it's verbose and "boilerplatey."
Could you elaborate on that?
If you're solving problems rails is best at, it's borderline magical.
The troubles arise when you get to huge codebases or complicated frontend patterns that aren't ideal for SSR / hotwire.
Also, it's impossible to separate Rails from DHH, whose xenophobic politics are unfortunately front and center.
TS doesn't "bin off" duck typing, it's a fundamentally structural type system. It's statically analyzed ducks, all the way down - when nominal behavior is preferred, people have to bend over backwards. Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript. In any case, it's the programming language that successfully brought high-level type system concepts like type algebra, conditional types, etc. to their widest audiences, and it deserves a ton of credit for that. The idea that JS and Ruby and Python and PHP developers would be having fairly deep conversations about how best to model data in a type system was laughable not that long ago.
> Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript.
All right, fine: TypeScript uses structural typing which is if you like a specialisation of duck typing but, whatever, compared with JS's unadorned duck typing it still leads to embellishment of the resulting code in ways that I don't enjoy.
I've been using TypeScript across different projects at different companies since 2013 and I've absolutely given it an honest go... but I just don't like it. I even allowed its use at a mid-size company where I was CTO because it fit well with React and a sensible person picks their battles, but I still didn't like it.
I'm now in the very privileged position where I don't have to use it, and I don't even have to allow it a foot in the door.
Now I'm sure that won't last forever, and I'll have to work with TypeScript again. I'll do it - because I'm a professional - but I'm still entitled to an opinion, and that opinion remains that I don't like the language. After 13 years of use I feel pretty confident my opinion has settled and is unlikely to change. I find it deeply unenjoyable to work with. BUT the plus side is that in the era of LLMs perhaps I no longer need to worry so much about have to deal with it directly when it eventually does impinge upon my professional life again.
I found it not just to lead to embellishment, but (1) the problems it did flag mostly would be caught by minimal testing; whereas (2) it regularly missed deeper problems. For an example of the latter: using TanStack (React Query) api caching, you have different data shapes for infinite scroll vs non infinite scroll. There were circumstances were an app confused them. Typescript had nothing to say. Nominal typing easily handles these cases and, ime, caught more actual problems.
> the problems it did flag mostly would be caught by minimal testing
Yeah, I agree, and the thing is, you're going to write automated tests whether you're developing in JavaScript or TypeScript so the extra cruft of TypeScript seems even less worthwhile.
The argument I've heard people put forward is that JS is fine for small projects or a couple of developers but doesn't scale to large projects or teams. I don't know how large large is, but I've worked on a project with around 30 devs where the front-end was all JavaScript and everyone was touching it and, sure, that project had some problems, but the root cause of those problems wasn't using JavaScript.
> the problems it did flag mostly would be caught by minimal testing
Testing is more expensive up front and in maintenance than type annotations. A test suite comprehensive enough to replace type annotations would have an ass load of assertions that just asserted variable type; if you were involved in early pre-TS Node, you remember those test suites and how they basically made code immutable.
> (2) it regularly missed deeper problems
This is a skill issue. If your types do not match runtime behavior and you choose to blame the programming language rather than your usage of it, that's on you. There are a lot of unsafe edges to TS, but a diligent and disciplined engineer can keep them isolated and wrapped in safe blocks. Turn off `any`, turn on all the maximal strictness checks, and see if your code still passes, because if what you said about infinite scroll is true, it won't.
> here are a lot of unsafe edges to TS
And one of its many problems is that it tries quite hard to pass itself off as not having those unsafe edges which, ironically, makes it easier to get tripped up by them.
But we need contracts that go way further what static typing provides. If they add dependant types + ability to enforce the types at runtime so that you can use it on various inputs, then maybe it will be truly useful.
You are absolutely not alone, brother (or sister). In the past few years when a lot of the millennial generation started getting their first jobs, the shiny object syndrome took over and most everything being made now is a distributed monolith pile of spaghetti code trash.
There are endless tools available, and quick internet dopamine feedback loops, but almost no wisdom.
Give it a few more years and more inflation, and the remaining 35% of millennials will get out there to find their first jobs, and then the impact will be even worse.
What is STOA standing for here, please?
Likely a typo of State Of The Art.
FTA:
> There’s just this minimal translation required between what I’m thinking and what I type
That's really the essence of Ruby for me.
We've been running Rails apps in production continuously since 2007. If you treat software as anything other than completely disposable, it's been a no-brainer for the entire 19+ years I've been paying attention (not despite its age, but because of it).
The premise that you get meaningful efficiencies from JavaScript on the back-end just because you have to use it on the front-end has been pretty thoroughly debunked at this point. Instead you mostly get a larger blast radius when the front-end ecosystem has its monthly identity crisis. OP's "stacks-du-jour" and programming language "flavour of the month" framing is exactly right. A shocking amount of web software architecture is just following fashion trends dressed up as technical decision-making.
Most of the churn in tech stack isn't driven by engineering requirements, it's driven by résumé optimization and Hacker News anxiety. Rails has quietly been powering serious businesses the whole time. Does anyone think NPM's 3.1 million packages enable more functionality than RubyGems' 190,000 packages?
We've also been running Rails in production for 15+ years (since 2011) in two companies and it has been serving us greatly. Hiring is tough, but I definitely believe the stack makes up for it due to the productivity gains.
In late 2025 we decided to migrate one of them to Inertia. Public facing pages is already done, and we're 80% through migrating the logged in area (it's a huge app). We choose Vue.js.
It's amazing how powerful this stack is and how little you have to change in the backend.
I'm surprised hiring is tough. The job market is such trash rn and I feel there are a lot of Rubyists, or ex-Rubists interested in returning to it, around. Maybe not? (Edit: spelling)
> Maybe not?
Because there are fewer and fewer ruby/rails people available.
It is the simplest explanation - and the one that makes the most sense, too.
Well ya, I'm just saying I'm surprised considering the current job market. I moved on from Rails about 5 years ago now, but have 9 years experience under my belt and still keep up a bit with new things and play with them once in a while. And yet I've applied for several Rails positions in the past few years and always get an outright rejection.
I'm availabe! On rails for over 21 years since version zero. It's strange, but true, that we Rails-devs are hard to find. I apply for Rails-related roles and am competing with over 1,000 other resumes. I'm not sure how I fail to even get a screening call 99% of the time. Perhaps overqualified? Perhaps poor filtering? It is a very strange job market.
> Does anyone think NPM's 3.1 million packages enable more functionality than RubyGems' 190,000 packages?
It means that there are many more people using NPM.
That means more users. More users is almost always better, for any language.
Also many of those gems on rubygems are dead since decades, literally. Probably also for NPM. We can not just compare the numbers without analysis.
I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems.
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.
I'm working on a large (at least 300k+ loc) Django code base right now and we have 32 direct dependencies. Mostly stuff like lxml, pillow and pandas. It's very easy to use all the nice Django libs out there but you don't have to.
I was talking about total deps, not direct. By installing something like Celery, you get 8-10 extra dependencies that, in turn, can also have extra deps. And yeah, extra deps can conflict with each other as well.
I find the thought daunting but the reality surprisingly easy.
You just keep up as you go, as long as you keep things close to the framework it's fine.
> You just keep up as you go
He said "Updating a project that was started 5-6 years ago takes a lot of time."
Yes but GP said "In reality it's not that much".
Not much work every few months turns into a lot over years, especially if you skip a few of those "every few months" events.
I'm confused. It's too much work to upgrade dependencies, but not too much time to write from scratch and maintain, in perpetuity, original code?
Yes. I've probably spent more time maintaining a trivial Rails app originally written in 2007 than I spent writing it in the first place.
But if you would have rewritten the entire app every time you needed to update the dependencies, that would have taken even more time.
That is obviously true but doesn't mean as much as you seem to think. Washing laundry is also not much work but it adds up to a lot over the years, especially if you skip a few weeks of laundry every once in a while. That is not an excuse to not do it.
The answer is the same in both cases: acquire some discipline and treat maintenance with the respect it deserves.
It is easy, and people tend to do what is easy. It takes more effort to minimise dependencies. Your boss or your client will not even notice.
Obviously there are some dependencies that you cannot easily avoid (like the things you mention). On the other hand there is a lot off stuff used that is not that hard to avoid - things like wrappers for REST APIs are often not really necessary.
Sometimes I think the issue here is churn. Security fixes aside, what is it that updated dependencies really give? Can't some of these projects just... stop?
The issue with that is, that the longer you wait to upgrade dependencies, the more pronounced the problems upgrading it will become generally speaking, because more incompatibilities accumulate. If those 5-6 year old projects were updated every now and then, then the pain to get them updated would be far less. As you point out, security is an aspect too, so you can leave the project inactive, but then you might hit that problem.
Dependency hell. Usually how it goes is you have to develop a new feature, you find a library or a newer version of the framework that solves the problem but it depends on a version of another library that is incompatible with the one in your project. You update the conflicting dependency and get 3 new conflicts, and when you fix those conflicts you get 5 new conflicts, and repeat.
So churn causes more churn.
Also breaking APIs should be regarded very poorly. It isn’t. But it should be.
I agree, but let's say you are looking for a library to solve your problem - you see one repo updated 2 weeks ago and the other one updated 5 years ago - which one do you choose?
That depends. What problem do I have, exactly?
Do I need a library to sort an array? The 5 years ago option is going to be the more likely choice. A library updated 2 weeks ago is highly suspicious.
Do I need a library to provide timezone information? The 2 weeks ago option, unquestionably. The 5 years ago option will now be woefully out of date.
Perhaps some kind of ‘this code is still alive’ flag is key. Even just updating the project. Watching issues. Anything showing ‘active but done’.
The real issue with Rails apps is keeping up with the framework and language versions. There are really two categories of dependencies.
One-off libraries that don't have a runtime dependency on Rails are typically very low-maintenance. You can mostly leave them alone (even a security vulnerability is unlikely to be exploitable for how you're using one of these, as often user input isn't even getting through to them). For instance a gem you install to communicate with the stripe API is not typically going to break when you upgrade Rails. Or adding httparty to make some API requests to other services.
Then there are libraries that are really framework extensions, like devise for authentication or rspec for testing. These are tightly coupled to Rails, sometimes to its private internals, and you get all sorts of nasty compatibility issues when the framework changes. You have to upgrade Rails itself because you really do need to care about security support at that level, even for a relatively small company, so you can end up in a situation where leaving these other dependencies to fester makes upgrading Rails very hard.
(I run a startup that's a software-enabled service to upgrade old Rails apps).
I think you could only get around this by forcing your whole dependency chain to only add non-breaking security fixes (or backport them for all versions in existence). Otherwise small changes will propagate upwards and snowball into major updates.
Indeed that’s what a lot of Elixir and Erlang packages do, if it’s done then it’s done.
"Security fixes aside" is too dismissive. Transitive dependencies with real CVEs can feel like the tail wagging the dog, but ignore them at your peril.
I have not had this experience as badly with Laravel. Their libraries seem much more stable to me. We've gone up 5 major versions of Laravel over the last year and a half and it was pretty simple for each major version.
Laravel is extremely stable and consistent.
I have plenty of RoR in production with millions of users, yearly we upgrade the projects and it's fine, not as catastrophic as it sounds, even easier with Opus now
Does batteries included somehow result in upgrading years old projects being a larger lift? I would think the opposite.
My experience has been the opposite, especially since Rails has included more batteries over the years. You need fewer non-Rails-default dependencies than ever, and the upgrade process has gotten easier every major version.
Rails is way more stable and mature these days. Keeping up to date is definitely easier. Probably 10x easier than a Node/JS project which will have far more churn.
I also think it's the opposite, since the dependencies are almost guaranteed to be compatible with each other. And I think Ruby libraries in particular are usually quite stable and maintained for a long time.
My medium-sized Django projects had close to 100 dependencies, and when you want to update to a new Django version, the majority of them must be updated too.
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.
It really depends how they were built. I have large Django apps running for a very long time that require minimal maintenance, but it’s because we were very deliberate about dependencies.
But I learned to do that by working on codebases that were the opposite.
Different experience with Django. I am only using a handful of deps. dj-database-url, dj-static, gunicorn, psycopg are the only "mandatory" or conserved one IMO as a baseline.
Use UV for dep management. Make sure you have tests.
In the past month I migrated a 20 year old Python project (2.6, using the pylons library) to modern Python in 2 days. Runs 40-80 times faster too.
It used to take at least a day of work. In a post-2025/11 world, it is under an hour. Maybe even 15 minutes if you've landed on a high quality LLM session.
Complete opposite of my experience
In my experience, the magic makes the easy parts easier and the hard parts harder
The upgrade story is underrated. I've maintained Next.js projects where major version upgrades broke fundamental patterns (pages router → app router, completely different data fetching). Rails' deprecation-then-removal cycle is slower but way less disruptive. When you're shipping product, stability of the interface you build against matters more than having the latest paradigm.
This is the thing people who haven't run a Rails app for years don't appreciate. I went through the Next.js pages router to app router migration on a production app. That wasn't a version bump, it was a rewrite across a different mental model.
Rails upgrades are painful but the path is documented, the deprecation cycle gives you a full minor version to fix warnings before they become errors, and the team usually knows where the sharp edges are.
The Ruby version management story is actually solid too. rbenv/asdf pin files make it hard to accidentally run the wrong Ruby version, which removes a whole class of environment drift issues you don't even realize you have until you've fixed them.
Switching from Next's pages router to app router (RSCs by default) is a major shift in architecture, practically replatforming. Not to be taken lightly (and an opportune time to consider less-opinionated modern alternatives, like TanStack Start).
I've been a Rails DevOps and nowadays a web one-man-show with it for over 10 years and I'd do it again.
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.
The "one-person framework" thing is a big draw. I'm amazed at how productive I was in it, and it's not just at the code level. Even though I've been doing sysadmin/devops/architect work for over 25 years now, it's just so damn nice now not to have to think about e.g. standing up a HA PostgreSQL cluster or Redis and deployment is largely a solved problem.
> not to have to think about e.g. standing up a HA PostgreSQL cluster or Redis
I don't understand...Rails does not replace a HA PostgreSQL cluster or Redis, they are orthogonal. Why would you not have to think about them?
And most folks getting stuff done with Rails ain't be filling out surveys to boost their stack - or maybe that's just me.
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
There are two types of devs: those that ship and those that fill out surveys (and not because their stacks are so much more efficient that they have time to fill out the surveys)
There are two types of dichotomy: those which are autoreferring and sound, those which are absurd, and those which are really going too far.
Over TWO decades! Rails has been around since 2004, making it just slightly younger than Django.
edit: Django was release in 2005
Rails is definitely older than Django. Django wasn’t released publicly until 2005.
Django had private use before then, but rails was also in private use before it was released.
Rails's public release was July 2004: https://rubytalk.org/t/ann-rails-0-5-0-the-end-of-vaporware/...
Django's was July 2005: https://www.djangoproject.com/weblog/2005/jul/15/chipy/
Adding Simon Willison's announcement: https://simonwillison.net/2005/Jul/17/django/
Thanks for the correction!
> 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 !
Oh, where did you find that?
Only info I could find was that Rails is at rank 10 in the Web Frameworks category for Admired vs. Desired in the 2025 survey: https://survey.stackoverflow.co/2025/technology/#2-web-frame....
Two decades. Rails was released in 2004, IIRC.
rails = ruby = oo/mutable && slow && resource hungry
And for a lot of folks that just doesn’t matter. Paying 50 or 100 USD for a server per month won’t be the thing that breaks you.
Before you get to a scale where Rails become a problem you need to have a product that drives a pretty significant engagement, that’s where most fail.
I was part of building the streaming frontend for one of Sweden's largest broadcasters in Rails about 10 years ago. Handled 1M+ concurrent users on Heroku with horizontal scaling. Fun fact: someone on the team literally stayed up monitoring traffic during big live events. It worked. Rails was a great fit for that especially at the time.
I moved on, not because Rails failed me, but because the things I started building next (Streaming infra, APIs behind proxies, lots of concurrent HTTP work, infrastructure tooling, AI/ML) just fit better in other languages. I pick tools by the problem, not loyalty.
What I notice in this thread is a lot of "Rails vs X" framing when the real answer is boring: use Rails (if you like the vision and Ruby) when the complexity is in the data model and business logic. Use something else when it's in concurrency or infrastructure. The one-person-framework pitch is real, but it's for a specific shape of problem.
Also: God i miss writing Ruby, its a fantastically and beautiful language.
Also: Blast from the past: Ruby is a great DSL for Rails.
> I pick tools by the problem, not loyalty.
Good advice that I keep trying to adopt myself, but I have to confess a large personal bias for languages that I like, even if it keeps me from certain classes of problem (I like Ruby, though).
What did you move onto for those next things you started building?
I know that feeling. Just because a tool is good doesn't mean you enjoy using it. I moved deeper into streaming infra with Python, C/C++, Go, and funnily enough Elixir. Then a complete path change into fintech and later AI/ML, which meant a lot of JavaScript/TypeScript and reluctant Python. I appreciate the Python ecosystem but find the language itself ugly to read and write. Always a last resort for me. Today it's mostly TypeScript, Go, and Lua.
Ha, I can relate WRT Python. I've been doing more Elixir these days for both a really pleasant web experience and because it has some unique primitives baked into the ecosystem that most JVM projects I work on spend a lot of time approximating through grotesque frameworks.
Ha, same. I wrote a VOD transcoding orchestrator in Elixir that triggered libav transcodes and custom packaging code in Python. Loved the syntax, and in particular the pattern matching in function headers. It was so clean for recursive branching that I ended up favoring recursion over conditionals and loops everywhere. Whether that was overuse or just good taste is subjective. We did hit a real scaling problem with the BEAM though. Distributed Erlang uses a full mesh, every node connects to every other node. When we got close to 50 nodes the inter-node communication overhead was eating a significant chunk of our CPU. Adding more nodes started giving diminishing returns because the mesh traffic grew faster than the compute we gained. Interesting constraint that I haven't hit in any other runtime since.
I used to think ruby/rails was the best way to solve most problems, I still do, but I used to too.
I've never used Rails, but I agree upon "the state of the modern landscape". Instead of looking backwards, I tried to look forward, and what I found was Elixir and the Phoenix framework.
You're about the 5th person now in as many days who has recommended Elixir when I mentioned I was building a project in Ruby. I'll definitely have to check it out for my next project (whatever that may be!)
Can you expand on why you found it so appealing or "holy crap, this is awesome" things I should look at first ?
Not the guy, but I used rails at my old job for one and a half year, and used it in some personal projects. I looked into Elixir(and Phoenix) during this time, and Phoenix felt like it was designed for more modern websites, where RoR is built for older and tries to adapt to handle modern ones. It just feels that when you want to do something more responsive in Elixir, it's designed for it, but in Rails, it feels like you're doing something unorthodox or something that is added as an afterthought. Obviously this isn't quite accurate, but it is the vibe I got.
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.
Counterpoint on the "going all-in": we have a 7 year old Elixir/Phoenix project that currently sits at ~100K LOC and I couldn't be happier.
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.
I think the OP's point was the job market. I.e. you probably aren't hiring for that role.
Not OP, but I made the move from Ruby/Rails to Elixir years ago, so I'll try to answer from my perspective.
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.
Something I never quite understood: differentiate between BEAM process and operating system process. The OS has launched one (in theory) BEAM Erlang VM runtime process with N threads; are we saying “process” here to try to emulate the OS process model internally within the BEAM OS process, when really we’re talking about threads? Or a mix of threads and other processes? I’m imagining the latter even cross network, but am I at least on the right track here?
A BEAM process is not an OS thread. The way I understand it, a BEAM process is just a very small memory space with its own heap/stack, and a message system for communication between BEAM processes.
The BEAM itself runs multiple OS threads (it can use all cores of the CPU if so desired), and the BEAM scheduler gives chunks of processing time to each BEAM process.
This gives you parallel processing out of the box, and because of the networking capabilities of the BEAM, also allows you to scale out over multiple machines in a way that's transparent to BEAM processes.
When I first started out with Elixir, it was more the overall architecture that first sold it to me. It is remarkably robust, my impression is that you can more or less yank RAM modules out of the server while it is running, and the last thing which will crash is Elixir. And it is absolutely top in class when it comes to parallel processing and scaleability. Not only how it does it internally, but also how it abstracts this in a way that just makes sense when you are working with it.
When it comes to web development specifically, what really got me hooked, was LiveView from the Phoenix framework. It keeps a persistant WebSocket connection to the client which it uses to push DOM updates directly. Instead of the usual request/response cycle on the client side, the server holds the state and just pushes the diff to the browser. It just made so much sense.
I've put together a number of resources here: https://elixirisallyouneed.dev
Great site. Thanks.
I am/was a huge Ruby fanboy, and I used Rails a lot and loved it (though had some criticisms around too much "magic"). I made the jump to Elixir/Phoenix around 8 years ago, and have loved it. Phoenix to me basically "fixed" all the things I didn't like about Rails (basically opacity and hard-to-find-where-it's-happening stuff due to someone metaprogramming aggressively). I will admit that I've been a functional programming fan for a very long time too. I always write my ruby code in a functional style unless there's a good reason not to (which is increasingly rare).
I still love and use ruby a ton for scripting, and still reach for Sinatra for super simple server needs, but Phoenix is my go-to stack these days.
I've also found the Elixir community to be amazing in the same ways the Ruby community is/was. It's not all roses, for example there's not as many libraries out there. Distribution is also not awesome so for example I currently use ruby or rust when writing CLIs. But for anything distributed (especially web) Phoenix is amazing.
This is a self plug, but I did a conference talk introducing Ruby veterans to Elixir/Phoenix some years ago. It's probably aged a bit, but should still be pretty accurate. https://www.youtube.com/watch?v=uPWMBDTPMkQ
The original conference talk is here (https://www.youtube.com/watch?v=sSoz7q37KGE), though the made-for-youtube version above is better because it's slightly updated, and I didn't run out of time :-)
I had a project I already tried out in Symfony and then full typescript, both a normal REST setup and ORPC. They all felt like - at scale - they became messy and I was unsure where goes what.
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 usually go full Symfony with my projects until I need to spread it out. But even for interactivity, I first go for htmx and Alpine.js instead of full React or so, where I then need to setup API on backend and frontend.
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".
I totally agree. At my first job, they instantly jumped towards Symfony and AngularJS. Sounds good, but they could've totally gone for something more lightweight. They DID NOT NEED the complexity AngularJS (and Angular2) brought them. When I left I tried my best to update to at least an LTS version, but I did not succeed and they did not care. I believe they're now migrated to Angular2 but are already stuck in hell
Ruby on Rails and Laravel all the way. Solid, proven, stable and scalable.
Rails for straight up CRUD is top, autogenerated things etc
however if your app doesn't fit the standard crud pattern you end just fiddling with a lot of things that you shouldn't and in that case I recommend Django which provides enough flexibility while providing a good base. There's less magic in Django
Serious question, as someone who started his professional developer career as a RoR developer in 2012: Isn't vibe-coding top for straight up CRUD?
I'm not trying to be glib. The thing that seemed magic to me at that time was all the scaffolding that Rails provided with a few simple commands, making it possible to quickly build something that let the user authenticate and enter and display data. Sure, Ruby itself and the culture around it back then was also great and will always have a place in my heart. But the whole convention-over-configuration and scaffolding thing, that was what I liked so much about it, and I never found that in any other language/framework combo in a way that felt as smooth.
But now, I use AI for scaffolding, and for my side-projects often never have to touch code.
So why would I choose something for a CRUD application that might give me headaches down the road, when there's a possibility that the app might morph into something less conventional, when I could use *any* language/framework that's not as rigid and have the scaffold be built by AI?
I get it if you enjoy actually writing code. But I don't quite get the benefits if the goal is to have something working quickly and be able to potentially build it out to something that is not served that well by RoR.
If you're building a pure SaaS app then Rails is perfect. If you need SaaS + more complex backend services like coordinating tons of webhooks I'd choose Elixir. Documentation sites and light server apps I'd use Node.
Go and Rust fill in lots of gaps for more serious performance stuff.
FWIW modern Rails is fairly magic-free also. They learned. With ActiveJob now part of the framework you get event queues/async processing and whatnot as part of the batteries.
I'm a fanboi, so I am biased, but Rails is still pretty great in 2026 for general business purposes.
Article nicely written, great overview of Rails current state. Kudos to the author.
To all the folks in here that bemoan the lack of static types, I'd like to mention there are some great solutions in this space, eg. https://sorbet.org/
Having the productivity of Ruby + the static typing and LSP integrations is a wonderful combination. Sure, it might be less aesthetic than some might like, but at least in my experience, it works very well in practice and supports most of the needs I have from a type system for writing and understanding conventional software.
I'm rooting for further developments in this space because I love language and systems that can leverage it's strengths and layering on a type system makes it a very formidable technology for building real world products.
I have not used Rails in a few years, but I can also say that the Sorbet typing support for the framework is definitely there too -- to great credit to the folks at Shopify allowing users of the framework to benefit from this tooling.
I would happily work on a Rails system today too. It's an amazing testament to the community how the design has been able to continue to develop to meet the needs of the many developers building with it up to this point. I hope more people feel the same joy I do discovering the kinds of things they can make with the language and frameworks like Rails.
With the amazing advancements with the AI tools we have now the only real limits are with how big our imaginations and ambitions can get.
[dead]
I spent 2024 and 2025 trying all the big fullstack monolithic frameworks (Laravel, Rails, .NET, Django). There are differences of course but they all suck so much for doing frontend.
In part because for a modern frontend dx you will need hot reload, bundling, etc. But even if you make an SPA and only use eg .NET for an API, using something like OpenAPI to share the schema is a subpar solution. There's really nothing as good as sharing TS types across your whole app(s).
"I have a tendency to go down rabbit holes when faced with problems - give me a minor inconvenience and I’ll happily spend weeks building something far more elaborate than the situation warrants."
You don't know how happy I was to read this... I thought I had a serious problem with getting distracted with my "projects" but it seems this is much more normal than I thought ;-)
One thing that is not stressed enough, is Rails enforces good code patterns early on. If you follow the docs, you will know where model code should be, helpers should be, controllers should be. After all, it is an MVC framework.
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.
The difference between JS frameworks and RoR/Laravel is the ecosystem cohesion. RoR and Laravel ecosystems employ the RoR or Laravel way of doing things and everything works together very smoothly.
JS solutions are loosely coupled, lots of good reasons to do so, but comes at a major complexity cost.
I agree. Opinionated frameworks are better in this regard.
Eh, there's NestJs and AdonisJs if you want opinionated MVC with lots of built-ins like CSRF and ORMs.
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.
Give AdonisJS a try, it's pretty much the JS sibling of Laravel and RoR.
Adonis is nice, but still young and lacking features. And in my experience very verbose compared to rails.
That said, absolutely worth a look.
Adonis is over 10 years old... that's like 3 generations in software years, and 20 generations in web/Javascript.
The reason it's lacking features is because it's not very popular and hasn't gotten much outside contribution... I seem to also recall something about the founder being too hostile to outside ideas/suggestions also, but I could be misremembering
Thanks! Never heard of it, definitely will check it out.
Javascript frameworks just do SSR + Express-style api routes. They don't handle SQL injection prevention because they don't deal with databases at all. CSRF prevention is less important in todays world tho.
it's like you're saying SQL injection happens if you're running sql on the client so if it's on the server you're fine.
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.
SQL injection is prevented by using database APIs properly, not sanitizing. Put all the malicious SQL you want in a query string, if it's passed as a bound parameter to a prepared query, it's only ever going to be a plain string.
You might sanitize for different reasons like business logic, but if it's your first line of defense against sql injection, you're already on the losing side.
I don't get your point, I'm not saying sanitising user input isn't important, I'm saying these JS frameworks are only concerned with server rendering and routing. They don't provide any tooling for databases like Rails or Laravel do.
JS frameworks are very much in the "full-blown app" category.
As an example, the "react" is just a view layer is a purest pov, to me (or whatever the given framework in question is). Nextjs, Vercel, supabase, lovable, and so on down the line all empower millions of people to ship full-blown apps. We might get carried away with which specific layer is in question, but it doesn't matter if they're always used together to ship millions of (in)secure apps.
Great post, this has also been my experience in the past 2 years. Rails is just a lot of fun, and that’s especially important for side projects.
I’m usually a Go person and love it, but building simple crud routes is not the fun part of it.
Going off topic, but the article made me look into "2025 Stack Overflow Developer Survey" and as usual there is the big difference between what the "Professional Developers" with and without AI claim to be using, and the usual HN discussions "X is taking over the world, no one uses Y anymore".
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.
> 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.
Not until they get their gradual typing story straight.
Depends on how much one likes the Smalltalk, SELF or Lisp development experience, regarding types.
Nothing wrong with Rails in 2026. We still use it for both internal and customer projects. I haven't yet encountered anything that made me feel like switching. I'm also not interested in changing frameworks just to have the New Hotness die in 2-5 years (our oldest currently maintained Rails project is over 10 years old, and some stuff I started working on when Rails 2 was new is still being maintained, just not by us)
I love rails and the recent improvements are great.
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
I'd say that if you're first encounter with rails is version 8+ -- it's a lot easier to use than previous versions.
Partly because the handling of JavaScript is much less bespoke and complex.
Javascript handling in Rails was easy in the early versions, then became messy with the asset pipeline and webpacker, and is becoming simple again with the latest versions
I now also believe that at least Active Record is much easier to use than Django's ORM
Doesn't matter when devs just slop out 400 lines of SQL and bypass the ORM.
Frameworks and structure will save you from neither stupidity nor ignorance.
If have a different opinion on this, as I think it's 100x better to learn sql and just write it directly instead of using the dozens of leaky abstraction of some framework.
That has always been the case, why would it be different now? Easy to flag and spot in code review.
Boy, I sure wish I had the opportunity to review codebases before inheriting them for maintenance...
I get your point but this is neither a Rails, nor an AI problem and as old as time.
I mean, I've seen enough "django specialists" to end up with queries doing a dozen of join bombs and producing 10 million rows from dataset of maybe 1000 items. So pretty safe to add "ORM" to your last statement.
> 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.
Yes, I've seen that, too. The rails way of doing things can feel like a terrible limitation to some developers, while others enthusiastically embrace it
it is also very token efficient in nowadays modern AI driven development[^1]. I wish more people would renown ruby/rails
[^1]: https://github.com/mame/ai-coding-lang-bench?tab=readme-ov-f...
I always enjoyed Rails, it isn't perfect but is way better then others. I have node and nextjs projects :) when they blow it, it is a major mystery what is blowing up.
Have so many good memories working with Ruby.
If anyone has old codebase need to be updated and upgraded, refreshed. I am happy to do that.
and security.
ideally a JS frontend app won't show logic not intended for the user type in question.
in practice, really often I see a huge app covering all roles and cases, a trove of info for the red team. and even worse, the reality of software development with LLMs in 2026 is plenty of code is being shipped without security audit.
I know it's not an inherent fault of the JS frameworks. bit I share what I see on the streets, most of custom JS apps I see are way more vulnerable to hacking than a old-style MVC app.
yes it is possible to make mistakes in both styles, but in JS apps I probably see 400% more easily discovered vulnerabilities than in a common MVC (even with stimulus) app
The main line on the Rails website now reads:
> 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?
Author of the article here (hi! Anxiously watching my Grafana stack right now...)
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...
> 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
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.
> This is so painful... I can't help but wonder who they're trying to target with such inane slogans.
Typical DHH insanity.
> This is so painful... I can't help but wonder who they're trying to target with such inane slogans.
The people who think that spicy autocomplete actually has an understanding of the slop it's churning out for them.
Those people don't choose frameworks. It'll be chosen for them by some LLM and given the prevalence of JS, it'll likely be some flavor of React.
> what's the difference if my agent uses fucking Next, Nuxt, Rails or Django?
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.
There was a post last week about the best programming language for LLMs, and in the comments people loved Go, with the claim being it's very opinionated and there's really only one way of doing things. I'd say the same is mostly true for Rails apps as well.
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 having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types.
Very true for me as well. I've never worked with Ruby but feel the same way about Django.
Btw, if you're looking for a "Rails but with TypeScript," my colleagues and I are working on almost just that: https://wasp.sh/.
The main difference, besides the ecosystem, is that we're more in the "configuration over convention" camp. Wasp has a simple DSL for specifying said configuration, but it's about to be replaced with a TypeScript file.
Wasp is still in beta and nowhere near Rails-level polish. But, depending on your early adopter tendencies, you might find it interesting regardless. If you do try it out, please reach out and share your thoughts.
TS is very AI native to the point i'd agree it's near magical in terms of contract.
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.
> TS is very AI-native, to the point I'd agree it's near magical in terms of contracts.
I agree. Not only that, I feel like TypeScript is currently the only popular high-level language with a type system capable of communicating all meaningful information. It seems to have hit an LLM sweet spot.
Looking at other candidates:
- Rust is popular and has a powerful type system, but it forces you to program at a level that's lower than necessary for most projects, hindering usability.
- Go is much more usable and very popular, but its type system can't communicate much.
- Haskell has an excellent type system, but it's nowhere near popular enough, and its usability suffers due to esoteric constraints (laziness, purity).
- etc.
I don't know the recent developments in Python's and Ruby's type systems. They may be able to compete these days, but they were nowhere near TS's level in terms of contract a few years ago when I last tried them out.
And I admittedly have no idea what's going on with C# and Java, but I'd love to hear about it.
Ruby has types with RBS and Steep now. It's a lot like using .d.ts sidecar files alongside JavaScript, via jsconfig.json configuring tsc. I like it a lot!
Personally I love rust for agents because of types. In the ruby world there's sorbet and rbs so would be interesting to try that.
>The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective".
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.
doesn’t forcing your agent to think in ruby put it at huge disadvantage though? since the language isn’t that popular it can’t have learned it as well as say python or Java?
Claude munches through Ruby just fine, all day long.
Python does have a bigger pool of examples, but agents usually get tripped up by missing context about specific frameworks more than by language syntax. The real obstacle for LLMs is understanding Rails' implicit conventions and magic, not the Ruby language itself.
The frontier models all handle Ruby just fine. So does th cheap Chinese models like Mini, Qwen, Deepseek.
>If we are all supposed to be talking to agents now, what's the difference[...]?
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.
I thought you were joking so I went to check it myself and... unfortunately you were not. That is insane.
Don't worry, it's just the hype phase and it will pass. (By 'pass' I mean agent-coding will be so ubiquitous that it's a given and not worth mentioning.)
I haven't found anyone pushing back on it at all, which has been making me a bit nervous! There was a HN post about it, though it didn't get any traction. [0] Seemingly nothing in any of the usual rails community areas either. It's going to make recommending rails confusing because that pitch really does make it unclear what rails is even aiming to do.
And yeah you're right, like what is the difference at that point? If the pitch is "AI agents write this", then the obvious response is "well why would I not use what has more training data then?".
[0] https://news.ycombinator.com/item?id=47272953
Oh boy. I can't even imagine what sort of hell an AI could unleash on a language as dynamic and magical as Ruby...
both statements are true though. rails excels in the AI world because it's extremely cared for and intentional with language. and there's a ton of built up knowledge.
fwiw that headline is cringey for sure. but DHH has proven himself a great marketer. it very likely is riding the wave.
That is just DHH (/37signals) being expert(s) at positioning.
Trying to answer the question of, why is language and framework still relevant in a world where almost everyone uses an agent for coding?
The upgrade path in Rails 8 is smoother than it's ever been, especially with the built-in solid adapters removing the Redis/Sidekiq dependency for smaller apps.
Ohmygod. Reading all that blog posts about RoR in Google Reader and is the old fashioned way now?
we run next.js on the frontend and the page router to app router migration was really painful. rails having stable conventions sounds very good when you go through something like that. I keep thinking about this trade off - move fast with the latest thing or just pick boring tech that works for 5 years.
nextjs pages -> app router is a massive change: new paradigm, practically replatforming.
yes exactly. we had to rewrite most of our data fetching logic. there was no real way to do it gradually, one day we just had to commit and do the whole thing. took way longer than expected.
> sometimes it’s worth doing things just for the sheer hell of it.
try ActiveAdmin, it reduces work a lot. also, ruby is so succinct and rails is so opinionated, Opus is super effective building code and keeping the codebase well structured by default
Ruby and RoR is cool and all, but as these web apps got more and more complex, the need for static types became too important. What gave PHP it's edge was types and is the reason I'm still using it after nearly 20 years. PHP seems to implement those important things just in time. OOP, better OOP, types, speed boost, and next probably concurrency.
Is is the need for static types or the need for better testing that is not focused on coverage of line of code?
Because if the domain logic is getting more complex then more types will not catch the bugs unless you are willing for codify business rules within types so then you have to test the types.
i returned to rails in 2025 after 12 years pause and my experience has been frustration and annoyance
rails lost it's convention over configuration ways, the generated app is dozens of files, lack of explanations and guidance on how to setup various things like environments, kamal being the worst offender and the changes between recent major releases aren't making it any easier to read the (often ai slop) articles and docs
just don't
> Rails seems to have pretty much fallen out of favour, coming in at #20 underneath the bulk of top-10 JavaScript and ASP.NET frameworks
It's not just Rails. Ruby is dying. And has been for quite some years now.
The strangest things are people writing blog entries claiming the opposite. Like "ruby ages like fine wine". No, that is incorrect - it is dying. I have been using Ruby since about 2004 or 2005. I still use it just about daily. I started before Rails and couldn't care any less about Rails; sadly the ecosystem is infiltrated by corporations such as shopify and others. You can see how they took over RubyCentral effectively (and if they insinuate otherwise - nope, I am not an idiot. I see the pattern. I notice what is happening. You call a black cat a green frog and I call bullshit. It's a black cat. See RubyCentral running amok already before they mass-purged developers, but that's another story - let's go back to ruby, and rails.)
> And Ruby itself is nowhere near the top 10 languages, sitting just underneath Lua and freaking Assembly language in terms of popularity!
Yup. Ruby is dying. It is following perl.
Now, defining "dying" is hard because you still have an active community, even outside of the train wrek that is rails (anyone still caring what random crap DHH writes on his blog? I've noticed fewer people care about the garbage he publishes, other than making fun when shopify damages the ecosystem - oh wait, he sits on the board of shopify. Did I already point out how much damage shopify causes here?).
> But I’m a stubborn bastard, and if I find a technology I like, I’ll stick with it particularly for projects where I don’t have to care about what anyone else is using or what the latest trend is.
On this part I agree. Ruby as a language is very well designed. It is a great language. I don't think anyone really objects to this, so the criticism has to be split - some criticism is valid, some is not. As a language ruby is well designed.
Nonetheless it is dying too. That is also a factual statement. Anyone claiming the opposite is wrong. At the least this is the case right now, and has been in the last some years, to varying extent.
> realised Ruby was “a better Perl than Perl”.
Also true. Ruby is the better perl. But I actually call Ruby syntactic sugar over C, because this is actually what Ruby is, if you think it through. My use cases are mostly helper-scripts, tons of that, over whatever I do in general. Literally everything computer-related. That includes use cases for the world wide web. All my needs here are covered by Ruby - but not by rails. I don't need rails.
Sadly, ruby also has a second problem: documentation. The documentation is crap in general. Look at rack. Opal. WebAssembly for Ruby. That documentation is a joke. An insult. Even sinatra, though better documented than these, has a bad documentation for the most part. There are some exceptions; for instance, hexapdf is well documented, and Jeremy's projects are also well-documented. So I am not saying everything is poorly documented. But for a language that once claimed it wants to compete against python ... sorry, documentation-wise this is still an epic failure point. In some ways ruby actually deserves to follow the path to extinction like perl did, merely because it failed to adjust, adapt and really improve. Yes, there is some internal improvement, but in many ways ruby failed to solve the problems people critisized it for, for many years. And now catching up is SUPER hard. I don't think it can happen anymore. I thought it was possible 10 years ago, but the last 5 years made it clear that ruby is towards extinction. It still does not change me using it, since ruby covers my use cases, but anyone thinking there will be an influx of new young folk driving ruby forward, is just worshipping an illusion here.
> There’s just this minimal translation required between what I’m thinking and what I type.
That's true. Ruby is kind of transitioning your thoughts into code.
> Sure, I can knock things together in Python, Go, or whatever the flavour of the month is, but I always feel on some level like I’m fighting the language rather than working with it.
Kind of, though python works fairly well too.
> And of course there was the welcoming, quirky “outsider” community feel with characters like Why the Lucky Stiff and their legendary Poignant Guide To Ruby.
Well - _why ragequit when someone doxxed him. But even aside from this, I found the poignant guide super-confusing. It was art, but I prefer less confusion myself. Still, _why is gone from the ruby ecosystem. Supposedly he is still doing computer-related stuff in reallife but he is no longer really affiliated with ruby as such. Did I already point out that ruby is dying?
> it’s just so nice being able to write things like
I don't doubt that rails is useful, but code like that sucks. Rails also came up with HashWithIndifferentAccess. This simply shows a lack of UNDERSTANDING. They pushed the DSL madness way too far. Yes, I get it, "I don't want to care if we have a string or a symbol" - easier access. But it is the wrong THOUGHT process here. And just the name itself ... HashWithIndifferentAccess versus Hash. Sorry rails guys - you were not good designers in a general sense of the word. The DSL may work; the DSL may be useful, but language or API designers? Nope, sorry. It's awful. I don't like this either, but I have less reservation here than compared to using numbers for time/date. It's cool that ruby is flexible to allow this, but I still think it is the wrong THOUGHT process.> got Claude to generate the rest with some mockups of common screens and components.
And AI is doing the rest. The path to exctinction.
Does Claude make "scripting" languages obsolete? I mean that knowledge becomes less useful if AI autogenerates everything.
> This can be something simple like caching for a specific time period:
I absolutely hate ERB. It is strange that it is such an integral part of rails.I abandoned PHP for many reasons but one was the spaghetti problem. Rail has the same spaghetti problem, though ruby is prettier than PHP. Still, that spaghetti design is just awful.
> This is why services like Heroku and Pivotal Cloud Foundry thrived back then
Heroku is also in the process of dying. There were some recent discussions about it on reddit as to why.
> While the Stack Overflow survey isn’t necessarily an accurate barometer of developer opinion, the positions of Ruby and Rails do show it’s fallen from grace in recent times.
It's not just SO though. TIOBE, despite being crap, also shows a similar trend. And if you research things, you notice many people moved on from ruby, for many reasons - often work-related.
The numbers are all there though. Now people either believe the numbers - or they write fake analysis such as this here: https://medium.com/railsfactory/ruby-is-not-dying-its-aging-...
> Anecdotally, I find a lot of documentation or guides that haven’t been updated for several years and the same goes for a lot of gems, plugins and other projects.
Yup. A dying ecosystem. I stopped using rubygems.org myself after Marty pushed the ecosystem into shopify's corporate pet project. 100.000 downloads and then your project is hijacked? Or the new shiny corporate rules? Nah. Go to corporate land and leave us alone, Marty. RubyCentral most definitely does NOT represent "the community". The original guys who wrote rubygems - now these were community folks, not some corporate ponicorns. Sadly when money is tight, bad things happen, and the ruby ecosystem showed this beautifully. Kind of bad too because it means money wins over community; but this is a chicken-egg problem, because how to grow a community if the trend goes downwards, for whatever the reason(s)?
> And I find that most gems follow a similar downward trend of activity.
Yup - but this is also old, even before RubyCentral transitioned into CorporationCentral. Ruby folks left ruby, years ago already. The people I knew from, say, 2005 to 2012 or so, also from IRC - some still use ruby, but most moved on to other things (also for financial reasons usually).
> Rails on the other hand actually seems to be picking up steam and has been remarkably consistent since the big “boom” of Rails 3.0 in 2010
Nope. Rails is also dying. It does not have the same 1:1 problem as ruby has, but the decline is 100% there too.
> Rails is a rare example of an OSS project that’s grown into its release cadence rather than burning out.
Not really. Ignore the promo. Look at the facts. Rails has been hurting too (which makes DHH laughing about when RubyCentral mass-purges developers both evil and silly, because that hurts the whole ruby ecosystem too - what was shopify thinking here?).
> Whether it can still find an audience amongst new developers is an open question
Yeah that is the question. Unfortunately the answer is there: new developers won't use ruby for the most part. AI also competes here now.
2026 is not like 2006, sorry folks.
> I probably could eventually build things almost as fast in another language or framework, but I doubt I’d be smiling as much while I did so.
Well, I used perl, php, python (still use python too). Ruby is more efficient for my brain though. And I disagree that I could be as fast as in another language. I simply have fewer barriers when writing ruby for the most part. Less restrictions. I don't think anyone thinks ruby itself is a bad language at all. We need to keep the discussions separate.
Pretty good comment from Mark Dastmalchi-Round by the way. Well-written, tons of details, opinions - even if I may disagree with some points, the overall quality of his blog entry is very good. We should give him very good marks for the blog - even more so as it is not on medium.com. I hate medium.com (and the link above, is to medium.com ... why did I link it ...)
[flagged]
LLM comment
Edit: don’t agree? Look at the page!
[dead]
is this really relevant anymore now that AI has gotten to the level it has? what used to take weeks to setup now take days (react, multiple backend services and infra)
Very relevant, because it typically takes a lot less code to express a feature in Rails/Hotwire than it does in a SPA with a dedicated back end. No need to maintain API contracts or ensure your UI code is properly async/awaited, etc., etc. Whether its a human or AI writing the code, SPA's add considerable complexity that just isn't necessary for most web apps.
Lower LOC to express a feature means better context management which pays dividends for things like code review.
This "feels like" first sentence / "curious if" ending question patterns seems to be coming from some LLM? I have seen the same across several online communities suddenly and frequently as of a few weeks ago. Notably the use of "I've seen" and "feels like" suggest the model is either prompted to act as a person or is one of the older models not strongly trained not to.
Nah read my own comment history. I tend to phrase things this way a lot too because it positions it as opinion/curiosity rather than arrogant / confident statement?
[dead]
[flagged]
[flagged]
[dead]
Remember only one programming language delivers developer joy - Ruby.
No other programming language brings developer joy because……. errrr because ……. Well because we are just super certain and confident, that’s why! Oh and DHH said so.
I’m honestly baffled by the praises of Rails in the comments.
I started my dev career with php and then nodejs, but recently got a job with rails, and honestly, it’s the worst among the 3.
There is no static typing whatsoever, it’s littered with magically generated methods, on a moderate size project the controllers or models directories grow to dozen of files. In general it feels like you need a lot of mental context in order to work with Rails, and I believe this is the reason people who run it for 10+ years in production love it. They simply carry all the magic in their heads, rather than let the framework guide you.
I, however, get much more DX and production stability by building with a boring (router + server side rendering) NodeJS stack with typescript and schema validation. My services are more stable and do not crash on “undefined method foo for nil”.
I guess people will defend whatever they know best, even if it has quirks.
On a positive note, I like ruby as a language. It has cool features like pattern matching, named arguments, or dropping verbose statements like “return” at the end of the function.
If you like Ruby but don't like Rails, take a look at Crystal, possibly with the Amber framework.
I unfortunately don't want to work on an untyped codebase anymore.
It's been 20 years, and Ruby/Rails still can't get their typing working.