What is your thought process here? Is it the notion that you can ship as fast as possible, and that creates a shitty environment given that you're a hamster on a wheel getting measured by output since "you should be able to ship fast?"
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.
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?
I'm not actually averse to a programming environment where the only ground truth is the running image. I love that kind of environment! In my editor, where worst case I dump some state when I restart, and I can just not play such dangerous games when on call or there otherwise exists a risk of winning such stupid prizes. Production has rules. Or it had better.
That said, if you want me to go back to dynamic typing, there's a fee. The grass really is a lot greener over here.
Debugging can be extremely hard when there are multiple complex frameworks/libraries doing magic stuff, plus extensions by the current team.
In practice this is all very convenient when you're writing the code, but not so much when you have a production issue.
The best of the best developers may have the resolve necessary to ignore their emotions and stick to writing 'magic-less' code when they move past the one thing Rails does well, but most projects are going to land in the laps of most developers who aren't that. I am sure we can find counterexamples of where exceptionally skilled teams have been able to wrangle Rails, but the exceptions do not make the rule.
On the other hand, when beginning in a place where writing ugly, boring, but at the same time usable code is the norm, even the average developer tends to stick with it when they need to do things that are "off the Rails". They don't have the original enamourment to get caught up in. There are plenty of developers who can still manage to screw this up too, but, again, exceptions do not make the rule.
Rails is just a tool, of course. The outcome ultimately is down to the operator. But there is a certain psychology at play that introduces difficulty. It is kind of like giving the average daily commuter, who is a perfectly fine driver under normal circumstances, a supercar with features they can fall in love with. In theory it's just a car to drive as they normally do, but they're bound to do something stupid with it when the emotions take over.
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)
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.
> 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.
I don't really see why I should take that sort of thing very seriously. Do you?
I also realize the insult you didn't quite offer, but while there are grounds for anyone with a Ph.D. to offer me offense, breadth of knowledge is really none of them. You are an expert specialist and I respect that as it deserves, which is less than you imagine but more than you fear.
That is your choice, of course. But this is what I mean about not taking you seriously. No remotely reasonable person could possibly believe anyone competent to participate in Hacker News and be able also to honestly claim to be intimidated by someone taking an impatient tone in mere discourse on the relative merits of programming languages, in a context where I am the one whose identity is known.
Such a transparent lie would ill befit a child of five, and whatever axe you have here to grind, the way you go about it is just embarrassing. Your critique, such as it was, has been submitted, received, and evaluated as ill founded. You have no further business with me.
We seem to be having an argument that you started, inasmuch as I was not actually in need of any explanation of the phenomenon I described; it does not bewilder at this late date when those with extensive social and professional investment in the waning Rails scene react badly to discussion of that wane. If the progress of that argument fails to satisfy, perhaps another interlocutor will give you a more enjoyable time.
Until then, you will either address any of the variety of substantive points raised earlier in discussion which you have carefully heretofore ignored, or you'll receive no further response from me. Not that I don't come here precisely for pointless disputation, but even my battered pride eventually scruples at this kind of pop-psychological pettifogging you so favor.
> 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 quote my own initial comment here, unabridged and verbatim, for the sake of adjacency with the following question: Where in this do you find a complaint?
That's a substantive question, not merely a rhetorical one. I would characterize my tone in that quote accurately as dismissive and uncharitably as contemptuous. But for the way you've talked about it now at such length, I can conclude only that I gave a mistaken impression of uncomprehending dismay. I don't understand how that could be so, given I literally do proffer an explanation for the behavior I'm meant not to comprehend; that explanation might be inaccurate and attract criticism accordingly, but to behave as though required to piece things together de novo is unwarranted. It's inconsistent to argue both that I must not understand the effect I create and that I must set out to create it, don't you think? Yet that's pretty much where you seem to end up.
You having concluded otherwise, ie that there is some essential ignorance here on my part requiring your effort to redress, I therefore ask on what basis you so conclude - the better to avoid again wasting my time, and incidentally also someone else's, in such fashion as this. Good grief, if I could've corrected that misapprehension right up front, we could've dispensed with everything after, to no doubt mutual preference.
And if you'll forgive myself quoting myself from earlier in the conversation, one more time:
> Meanwhile detailed and substantive technical critiques provided by other users - critiques of the sort I learned a decade ago not to bother making - go totally ignored as I knew that they would.
Even where it would have offered an advantageous contrast to my supposed hyperbole et al, where do you see sweet reason having told? - when, that is, it comes to the substantive technical critiques of the sort I'm meant to be taken at fault for declining to provide. Those critiques are still being ignored, while you sit here days later still not yet disabused of the idea you are equipped to bandy words with me.
I am not, in short, arguing here with even remotely serious people, and I show them the treatment condign upon their behavior. To do otherwise would serve only to lampoon myself, instead of them. It isn't something I expect to see appreciated by my interlocutors, including you. Its audience, if any, lies elsewhere.
I don't think you're an idiot. I think you're a smug, self-satisfied, deliberately ignorant ratiocinator who rarely understands why he succeeds and never why he fails because he does not really know how to think, although he is very sure that he does. This is the only conversation you and I can have on this website that is interesting to me, at least until you demonstrate some potential otherwise, which by now you seem as unlikely desirous as capable of doing.
If you want to boil all that down to something easier to swallow, then you're welcome. And, yes, I'm well aware that "no u" is as available a response here as previously. Do you think it will avail you more now than then?
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.
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?
Not sure what I said that came off as an attack on you or your standing. Not my intent.
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.
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.
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!
My pet theory is that LLM coding is going to give the upper hand to more verbose languages like Golang or Typescript because more of the execution flow will end up explicitly in the LLM's context. Convention over configuration-type frameworks ruled when one-person code bulldozers shipped MVPs but Continue is upending this paradigm.
It's a game changer for human devs also, and not really one I would expect a serious Rails habitué to necessarily evaluate in a way that's reliable. What did someone call that once, the "Blub Paradox?" Silly name, but that's this industry for you.
I'm glad static typing came back
Rails should have incurred some kind of criminal indictment.
I wish I hadn't mentioned either, because now no one will talk about anything else.
Hell, just finding out what methods can be called from a given code location is something that most Rubyists I’ve met answer either with a runtime debugger or hard-fought and non-transferable memory about a particular piece of code.
Like, I don’t need perfectly accurate programmatically-available answers to those questions in my IDE (though that would be nice). I’m fine reading code and working it out if things are added via reflection/metaprogramming. But if the domain of code to read to determine those things is “who knows/could be anything in the codebase or dependencies”, this is a poor quality tool and/or community.
If you read that and think I’m complaining about one specific instance, codebase, or Ruby community habit, I promise I’m not. It’s not about the 2014 obsession with “DSL”s (that aren’t really DSLs); it’s not about method_missing, open classes, pervasive monkey patching, and so on. It’s about all those things, and more, and the overwhelming enthusiasm (with no small side of smugness) with which the Ruby ecosystem doubles down on them constantly.
Is it the language itself? The community? I don’t know, but I know there are plenty of equivalently capable alternatives to both, and that’s enough for me to avoid the hell out of Ruby and Rubyists for a long time to come.
Is Ruby the worst? No, that honor goes to a multimillion line Perl monolith worked on by far too many not-as-clever-as-they-thought-they-were people over far too long. But all the Ruby I’ve worked on is close enough to that experience to make me question the choice of tool.
I can write perfectly legible and readable Ruby if I want to. But I also could just write Python and it would be easier to maintain.
So, yeah, I look forward to the cycle tacking in the other direction but today ain't it
1: to say nothing of the fact that model servers exist so why the fuck are you writing business logic in a language that DGAF just because your data scientists have a hard-on for pytorch
My perspective on this is that of a working engineer who made a deliberate choice, now nearly 15 years ago, to avoid ending up stuck in the same decreasing-radius career spiral I saw Rails leading me toward - so I went and did some other things, then spent a decade building modern TypeScript instead, mostly on Kubernetes, without losing the ability to knock out a quick one-off script or architect a system top to bottom as I need. It's worked out splendidly for me! I suppose I might have done as well if I decided differently, but I admit I don't see how.