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.
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'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
More from Ian here - https://www.quora.com/Will-the-Golang-code-become-unmaintain...
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.
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.