I have mixed feelings about RoR, having seen both sides: the incredible speed of development as a startup bootstraps its MVP, and later as a mature company where the codebase becomes an immense behemoth of tech debt that's almost impossible to refactor. Don't believe the people who handwave and say you can avoid the latter by just "designing it right at the beginning". That's a lie, even the best engineers will build an unmaintainable monolith in RoR given enough time and if the business requirements are complex.
At this point I have a strong aversion to starting any product using a dynamically-typed language (regardless of framework). The initial speed and ease of development is repaid 10x later on in sheer engineering pain (if you're lucky enough to be successful, that is).
Static typing alone won't save you from creating monolithic code that's hard to maintain. My current employer has been slowly decoupling their 20 year old core product written in .NET into microservices (mostly Java, some Node) for years. The legacy .NET codebase has tons of tightly coupled dependencies, logic heavy error prone stored procedures spanning thousands of lines, and laughably slow startup/deployment times.
This. People who believe this pipe dream that static typing will somehow protect you from technical debt either haven't dealt with Java or it's slightly better cousin C# or have only dealt with that one technology and believe whatever kool-aid advertising they were sold on.
The only way to adress (but not eliminate, since it's impossible) technical debt is to refractor mercilessly and constantly. And then there is some merit to static type advertisement - as the tools and techniques to safely refractor are both more feasible and more available for these environments.
> People who believe this pipe dream that static typing will somehow protect you from technical debt either haven't dealt with Java or it's slightly better cousin C# or have only dealt with that one technology and believe whatever kool-aid advertising they were sold on.
Hark! A counterexample has arrived! I spent a bunch of years creating and maintaining big Rails applications. I've spent the last couple years on a bigger application in Java. I didn't drink any kool-aid, I just think Java is a better tool for this. C# and other things may be even better; the key is the ability to write static analysis tooling, which includes, but is not limited to, a compiler's type-checking analysis. It's not that a language with strong static analysis support saves you from creating a mess, it's that it makes it easier and much less risky to clean up that mess over time.
I agree with everything in your second paragraph, and would emphasize the risk aspect of refactoring a big application without good static analysis tools. After the first few spooky-action-at-a-distance prod breakages due to refactoring, it becomes hard to argue for a merciless and constant refactoring culture, and much easier to become the grizzled veteran who is a risk averse gatekeeper discouraging major refactoring in code reviews (this was me).
You don't refactor "a big application". You refactor bits of it (sure it might mean moving things around) and then comes your barrage of tests before you merge that into master.
That and: You don't (or at least shouldn't) write a big application anymore. The only other thing (other than horizontal scaling, that is) that microservice design makes easier is exactly code maintainance / refactoring. The practices around it have matured enough.
On the other topic: I've spent last year or so writing mostly JavaScript, and have moved to VS Code as my primary IDE. I'm pretty happy (was doing Java/Python before that, and PHP/Python before that, and some embedded stuff before that).
The truth is that a good tool (and VS Code is one hell of a tool) makes working in a dynamic language very usable. VSCode static analysis tools make my JS experience better than my previous NetBeans Java experience, all things considered.
And I'm now dabbling with TypeScript to see how that goes. I quite like the idea of "just enough typing" and I think type-hinting rather than static typing is the way forward in this networked future. It's simply that these JSON-ed distributed environment people work in now will make static typing languages frustratingly un-agile for large majority of use-cases.
This is a complaint I hear a lot, and it's very valid. My question is: which frameworks protect against this "behemoth of tech debt" inevitability that comes with using rails?
I've worked with large rails, django, and node apps, and none of them have felt particularly enjoyable to work with from a feature development standpoint once a certain scale is achieved. This doesn't feel like a rails-specific problem to me, but that's just based on my experience.
None. This is not a Rails problem or a Django problem. If you're coming to that conclusion you haven't been building software long enough.
You can architect clean software in any language. What happens is this: you learn a new framework (or sometimes learn a new framework AND the corresponding language it is build in). You don't know what is idiomatic. You haven't made mistakes yet. You're making progress on your idea and getting shit done though, so it doesn't matter. Long story short: you don't know any better. Hindsight is 20/20!
Next time around you try something new and blame your old woes on the framework. This time around you've learned a thing or two about how to properly organize your code. You've been bitten by a third party tool that stopped being maintained. You've grown and learned and become more wise. But... you still blame your past issues on the old framework.
At some point you've been doing this for decades and you start to learn about abstract patterns that are not coupled to frameworks: service-oriented design, domain-driven design, CQRS (command driven systems), event buses and event systems, clean architecture, separation of concerns, SOLID principles, etc... ONCE you are at that point, you will begin to realize that NONE of the frameworks are going to solve these issues and NONE of them are more or less prone to causing tech debt.
Long story short: keep building software and focus on principles not frameworks. Read up on SOLID. It just takes time to get better and to start building things that don't encourage debt.
Another thing to note: tech debt is not bad. People throw that term around all the time and use it as a proxy for "messy code". Nothing in life is free. Everything is a balance. Perfectly architected software vs move fast and prove the business and make a profit? Pick one. You're going to acquire some amount of tech debt along the way. It's like real debt... sometimes you gotta accrue monetary debt to make progress elsewhere.
This is a software problem, not a Rails or even a Ruby problem. I've seen Java/C++/C# systems collapse under their own weight just as often as Ruby/Python/PHP because they don't invest the time in cleaning up the tech debt as they grow.
Parent is definitely right, projects that are "designed right from the beginning" do not exist in reality. Everything has unknowns in the future, and it is better to be flexible and adapt the code base to them as they come rather than trying to plan everything out from day 1. Static typing does help with these adaptations, but it doesn't compensate for a lack of diligence in keeping the code clean as the software grows.
I think the concepts built-into Go make building very large programs much more approachable. That was one of the design goals.
I'm not sure Ruby, Python, Javascript, etc. were really designed for large scale development (although people use them for that). I think this is the primary reason so many people complain about technical debt, hitting the wall/limit, needing to refactor, etc. And looking for another language. Their tools just were not meant to scale that large.
"Go was deliberately designed from the start to support large scale programs implemented by hundreds or thousands of different programmers. Those kinds of programs are written at Google, and Go was designed to be used to write programs at Google." - Ian Lance Taylor
which frameworks protect against this "behemoth of tech debt"
Yeah, that's basically what invalidates the assertion. There's no language or framework that guards against the complexity of a large code base. Period.
Assuming you last long enough to care about tech debt. That development speed of arails is often the difference between surviving as a company or folding before you even get off the ground. However Swift Vapor might be a good alternative.
You can build poorly architected apps and accrue tons of tech debt in any tool. Likewise you can build very clean, fast, extensible and powerful applications in things like PHP.
Don't pin this on ROR. I have seen absolutely atrocious Django codebases, Clojure projects, etc...
Types do not solve this problem either. If you think static types prevent 'tech debt' you're delusional.
Good architecture can be had across the entire spectrum of tools and frameworks.
Designing it right at the beginning is a problem for every software. I have 100+ lines controller actions in rails and I'm not proud of them, but it has grown like this over the last 8 years, it has 100% test coverage that I probably wouldn't have to touch if I decided to refactor the method into a few (yes!) services.
Following your opinion You'd say that there are no well design projects build with RoR, right? I think that's not true while you deal with the tech debt. Also, about the dynamic typing, you could really mess up the things with static typing programming languages like Java...
I will support the most extravagant and unnecessary new aircraft program the MI complex wants to push forward, PROVIDED that the resulting machines stay exclusively on US soil and in US airspace. Versus immediately being sent thousands of miles away to defend Israel, Europe, Japan and/or South Korea.
Wow. Racist much?