Comment by throwanem
5 days ago
If you mean about Rails specifically, it's that the total lack of discipline in both language and framework makes it impossible to build a product maintainable by more than one person, so every "successful" project has one or a few covert empire builders running it, usually with more political than technical success. That's not a kind of project that pays enough to be worth the trouble, even before we talk about opportunity cost, and the framework itself is a dead end that peaked in 2011 and has had about as many "renaissances" since then as there've been years of the Linux desktop. If I want to go live under that kind of rock, I'll do it with Salesforce, where the pay is better and no one thinks they're cool for poking at a keyboard all day.
Strongly disagree. I've seen bad code or maintenance in all the languages. Sure, some ecosystems seem to attract worse practices, but the absolute best software engineering principles I ever learned in my multi-decade career were at a Rails shop. Everything was extremely well maintained, tested, CI/CD were great even before that was a thing. Not to start flame wars about refactoring or what it means to maintain code more, but that place was absolutely full of people who cared and kept those projects at the highest of caliber grade. You can find good, bad, and ugly in every ecosystem but I personally don't think Rails was ever even remotely bad. You can have an amazingly well-maintained setup and still be super productive. It's really about the people and the company spending the time, money, and energy to care. (Edit: typo)
Which shop? When? Who with?
It matters, far more in this ecosystem than others. If today there seems to be a history of pervasive testing culture in the Rails ecosystem, I can only assume there must exist some quiet mutual agreement to keep some history swept under what must be quite a large rug. Oh, I remember the same enormous amount of lip service about testing that you do! And I also remember what it was like to try to integrate a dependency into a Rails project in 2012, because that was a fair bit of what swore me off the platform. Rails was famously the home of dogshit engineering practice in its day, every bit as much as PHP, excepting only among the coterie of too-good-for-finance Boston hipsters who invented the thing, and benefited from all the same traditional software engineering training and practice they built a culture (and, coincidentally, a reputedly quite lucrative consulting practice) around decrying. Just saying "I saw good Rails back in the day" thus really isn't dispositive.
They were young, so was I, we all make some bad decisions at that age, it's fine, I don't care. But none of us is young any more, and as an aging hipster once said, there's nothing more contemptible than an aging hipster.
One of the largest codebases I've ever worked on, generating billions in revenue every year to this day, is in Rails. Over a thousand hands have touched it, and none of the original people are still around to hold an empire.
I'm with you on the general lack of discipline enforced by Rails; this codebase isn't fun to maintain, precisely for that reason. All the same, I don't think your critique is fair or even that accurate.
But that's from my POV working at bigger companies. Maybe it looks different as a freelancer for smaller shops.
By the sound of it, your POV working at one big company. The codebases I've worked on that did similar ARR numbers with similar depths of commit history were in Javascript and TypeScript, so "your argument is invalid," right? Why not? It's just what you said and my credentials are better. What's the most in revenue one second of your life was ever worth? For me that's about $35k. But no, you go ahead, try to big league me with numbers some more.
If you think my critique is unjust or inaccurate, then attack it, not my standing to speak on the subject. Especially not when I'm the more forthcoming of the two of us when it comes to professional history, anyway; mine is findable from my HN profile, while you prefer true pseudonymy. To argue from authority as you've tried is quite risible with none of that even in evidence, don't you think?
I don't mean to say one of us has better bona-fides, only that there is an existence proof to the contrary of your post. You claim that rails' lack of discipline promotes unmaintainable code shepherded by empire-builders; I claim that this is not always so. I gave the numbers I did to emphasize that rails (and rails shops) can succeed even at that scale.
Not sure what I said that came off as an attack on you or your standing. Not my intent.
2 replies →
First, props for your candor. It’s refreshing.
I do wonder if Rails is so bad compared to other frameworks that it deserves such a distinct treatment.
Over the decades I’ve worked with at least half a dozen popular frameworks that fit this description, is the same for you or is Rails truly unique in this regard?
Rails is uniquely compromised by its history and by its language of implementation. Ruby is good for many things. Writing maintainable software in the absence of conventions enforced by shotgun is none of them. And Ruby's American fanbase gets off way too much on holding the shotgun.
Worse than Python (without Typing)?
4 replies →
After a lot of consideration of this question (I have also all-but written off Rails work, after doing a lot of it) I think it's a combination of two things, one technical, one business-social:
1) Rails and Ruby will gladly let you make an absolute garbage fire out of your codebase, while it still technically works, and discovering how exactly the garbage fire is structured so you can start trying to put it out is unusually difficult in Rails. You don't have to make it a garbage fire, but they won't do a single thing to discourage it, and once it's bad, it's hard for an outsider to show up and figure out how to fix it, because of how the framework and language are designed.
2) Rails is often chosen by very price-sensitive companies trying to move fast, as cheaply as possible. This means high turnover, lots of enthusiastic juniors, outsourcing (often passing through multiple outsourced teams...) and often mediocre or poor management oversight.
The result is that a high proportion of Rails codebases in the wild are both remarkably terrible and impractically difficult to restore to some non-terrible state (i.e. they're the kind of cases where the right call really is to just start over—one of the things that makes them hard to work with is that a bad rails codebase is especially hard to rewrite-in-place, it's just a ground-up replacement job usually, but you won't actually be allowed to do that because see again: price sensitive, so you'll just live with an awful pace of development and poor application performance while management gets increasingly frustrated by the outcomes of their own choices)
This must be a god level troll post.
I was asked for an opinion and I gave one. Don't make too much of it. Rails devotees can't stand hearing a bad word about their baby, they always make a fuss.
I've seen poorly-built code on rails circa 2014, and I've seen Rails done pretty well circa-2025. I'd say rails is pretty neutral. Saying it's PHP bad seems a bit much, but hey.
The worst code I've ever seen by a country mile though was a huge Python 2 code base written on an old version of Tornado circa 2012, a library that basically hacked the Python language to get code to run asynchronously, but you had to contort yourself into knots to get it. You couldn't just call other async functions/methods, you had to `yield func()` when calling them. To return from a function, you couldn't use `return` you had to throw an exception of type Tornado.Return. Absolutely insane way to write code.
Then all the business logic written on top of this bizarre framework was terrible. Half of the code broke the rules I just mentioned but still half-worked sometimes, but would perform terribly or have mysterious problems.
One of my greatest accomplishments was getting it all to Python3 then onto more sane async-style code.
2 replies →
I reckon the negative reactions are at least partly down to your wording, e.g.
> there is no good work
> total lack of discipline
> impossible to build
This level of absolutism is problematic for a couple of reasons. Firstly it's ambiguous: a "total" lack of discipline would entail never releasing anything. This is clearly inaccurate, and the reader is left guessing what level of discipline is implied. Secondly, without more detail, most will assume exaggeration, given that RoR sees significant commercial use. You haven't provided compelling reasons to trust your judgement over anyone else's, so users are well-justified in raising counter-examples from their experience.
You also come off as dismissive of opinions and lived experiences that differ from your own; suggesting that anyone who disagrees is a "devotee", and that concrete counter-examples are meaningless one-offs. Having been on the sharp end of this dismissiveness myself, it mostly acts to drag the discussion down. Like, fair enough, maybe you're incredibly experienced, you want to make the world a better place by passing on your wisdom, and you're tired of dealing with half-baked takes. But belittling your fellow users is not helping. And again, from my own experience, you can be quick to say that a take is half-baked even when it aligns with scholarly opinion.
2 replies →
Hard disagree. I work on one of the largest Rails codebases out there. Millions of lines of code running in a monolith. I have learned more in this shop about scaling, observability, mature system designs, zero downtime upgrades, deploys, etc…
I been in this field for almost 30 years and have worked with whatever tech the job required. Still I learned more at a Rails shop with more than 200 engineers all working in the same monolith shipping to production multiple times every day.
I'm well aware there is a large Rails shop with famously strong engineering practices, which I believe deserve much credit that accrues for some reason instead to the framework.
Yes, yes, yes, everyone knows about Shopify and no that’s not the multi billion dollar monolith shop I’m referring to, but we definitely have taken some inspiration from their excellent practices. We also brought in a lot of best in breed from Microsoft and Amazon.
Bottom line is it’s about the talent and the discipline. At the end of the day it’s not bad languages that are the problem it’s bad engineers.
3 replies →
Can confirm, I'd charge a laaaarge premium to ever work on an existing Rails codebase again.
Did it several times over a period of 15 years and they were always a wreck and unreasonably painful to work with. Every single time.
I'd start a green field one, no problem, provided I get veto on gem choices ("Let's use some twee fucking template language that's a ton worse-performing than the default and doesn't let you programmatically control nesting levels / end tags because it's terribly designed" yeah how about we don't do that because it's going to make my life a living hell) without charging a premium. But no more onboarding to rails codebases without enough money to make it worth my hating every second of work for the (assuredly short) duration.
... and I like Ruby!