[rmk]

I've found that it's a chore to maintain large-scale software written in dynamic and static languages for different reasons. Large projects written in dynamic languages have turned into insane messes because people with varying levels of ability can not develop with confidence unless the unit test coverage is high and everyone is generally consistent and disciplined in their usage of language features. Sooner or later velocity goes down significantly because the value of the code has increased due to business growth and there is a very high level of anxiety about the ability (or lack thereof) to reason about far-reaching code changes, or even medium-sized code changes.

With static languages, on the other hand, writing routine things becomes a chore and people end up needing crutches in the form of advanced IDEs to generate boilerplate code that is a pain to read because of templating and such. Of course, error messages when templating/generics becomes involved are just horrible. Without generics you tend to lose a bit of the benefit of statically typed languages.

At the end of the day it's the size of the codebase, team discipline, and an emphasis on simplicity that matters more.

It is my experience, though, that people start out enamored of dynamically typed languages because of their expressivity and high productivity but then end up gravitating towards statically typed languages for large codebases, because they are more willing to trade convenience and coolness for safety and reliability the more senior they are.

[ncmncm]

If at your organization, "people end up needing crutches in the form of advanced IDEs", and use them "to generate boilerplate code", they are Doing It Wrong.

(There is probably no choice if your "static language" is Java [0]. But Java is always a choice: you can always quit and go where Java isn't, especially nowadays where everything is remote.)

A powerful static language (i.e. not Java, C, or their analogs) in a well designed system involves no boilerplate and can be a joy to use.

[0] https://blog.plover.com/prog/Java.html : "I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product."

[rmk]

For better or worse, most organisations choose Java as the statically typed language, and not everyone has the luxury of saying "I'll not use Java". Even MJD, no slouch when it comes to technical chops, admits that he ended up writing Java.

Java is definitely like this and it also emerged in an era of overengineering because microservices weren't a thing. However, I'm willing to bet that Go will soon go this way with generics. Most average programmers do not care about programming with types, type traits and so on, and are simply not equipped to deal with byzantine compiler errors (gcc/clang error messages and warnings about C++ templates were the ugliest things I have ever seen), and this is where the tradeoff is facilitated with pre-written libraries and code generators that take away the need to deal with these things explicitly. They are not going away, and relying on them is not Doing Things Wrong. It's just doing things and getting on with life, period.

[ncmncm]

I think Mark Dominus writes Haskell nowadays.

"Byzantine compiler errors" is what I guess you have come to expect from (mis-)use of pre-C++20 templates. But the overwhelming majority of type operations in actually high-level languages like C++ and Haskell cannot result in compiler error messages, and simply perform useful busy-work you therefore need not.

[closeparen]

What languages are we talking about here? I mean, we use Go, but I would definitely consider it a C analogue. It is also very tedious, and all the measures we have for managing that tedium are code generators. (Though in Go world, culturally, these are build time rather than IDE based tools).

[ncmncm]

C++, Haskell, OCaml, even Rust.

As we used to say, "you can code FORTRAN in any language", and code in those languages can be as unpleasant as anywhere. But they don't have to be.