[greaseball]

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.

[bmarkovic]

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.

[sanderjd]

> 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).

[bmarkovic]

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.