Exactly. As with everything, there is a tradeoff, and the general answer is always "it depends". Or if you have to choose between one or the other, the answer should be "yes".

Static typing provides universal guarantees, which sounds great at first, until you realize that it really does mean "universal". Sometimes that extreme rigidity makes changes very difficult, especially when you're dealing with cross-cutting changes across many teams and organizations.

I work in a very large company with lots of services. The best practice, espoused by most of the senior/principal engineers (particularly ones with extensive SOA experience), is to keep your service interfaces and document models dynamically-typed. It makes them much easier to change. Big systems should be assembled from loosely-coupled components which are internally rigid but externally flexible and dynamic.

Service interfaces should be well-typed. Almost by definition, the cost to update a service interface will be a fraction of the time associated with updating its consumers and testing their integration. Dynamic types can lower a part of the cost (although not by much, in comparison to modern languages and frameworks), but add more expense in many other ways.

When operating at any sort of scale, a system that's "easy to change" stops sounding virtuous. Communicating and integrating service changes effectively is usually more expensive than making the changes themselves, for a large organization. Providing service descriptions which can be converted into static types (e.g. swagger) is very cheap, and can prevent a host of expensive human errors.

In truth, poorly specified services or documents can end up impossible to change, since the risk and impact of doing so is difficult to size (or the exercise of doing so costs more than the change is worth).

A system that's easy to change is very important at scale, unless you want to write a new API or service every time a new business requirement arises.

In many situations, a true statically-typed service interface can be nearly impossible to change, or even add fields to. Adding new schema versions (particularly for write APIs) or dynamic/polymorphic schemas that change based on the input are extraordinarily useful and very easy with dynamically-typed interfaces, but can be very difficult with strict statically-typed interfaces, particularly the kind that e.g. Java nudges developers towards.

There are some hybrid frameworks that mix dynamic and static typing, which solve some of these problems (e.g. protobuf, Avro, Ion). They make reasonable compromises.

> I don't think the OP would claim TypeScript is a bad idea

Confirmed.

TBH there are very few languages that I'd claim were a bad idea. The point I'm making is not "Statically typed languages are a bad idea" it's "If you think statically typed languages are going to make software correctness magically better then you're going to be disappointed".

You did actually claim that statically typed languages were worse than dynamically typed ones for correctness:

> My general experience of the correctness software written in fancy statically typed languages is not overwhelmingly positive compared to that of software written in dynamic languages. If anything it trends slightly negative.

I might not say that the use of any language is a bad idea, but I'm definitely going to say that basing a language choice on a general and uncertain impression derived from my extremely limited, biased and anecdotal sampling as an end user is a terrible idea :-p

ETA: The point of that anecdotal impression was not "This is definitely true" but "Given that this is my general experience it would be surprising if the actual trade offs experienced in practice were such that static typing was regularly a clear winner", which I feel much happier supporting on an impression than "You should do this".

Well, I would say that some types like "eight-bit character in ISO-8859-1 encoding" is a monumentally stupid idea in this day and age (and yes, I live in 8859-2 area, but that isn't the point … http://www.joelonsoftware.com/articles/Unicode.html).

I would have written PETSCII, EBCDIC or shift-JIS instead, but feared few users would understand it.

Not everybody writes new stuff; some software has to interface with stuff written decades ago.

Also, even for software 100% written today it often is impossible to stay in a world where all strings use compatible encodings.

Examples where you need conversions: when connecting systems that support different Unicode versions or when generating http headers, windows file names, or QR codes. I guess many 'older' systems will not handle ZIP or tar files that use UTF-8 for file names in the archive, either.

With a type of String @@ ISO-8859-2 everyone knows what a function expects. And if you depend somewhere on a String being ISO-8859-2 but everyone hands you in Strings of many encodings, you have hard to debug errors (b/c all main stream languages do not show you where your vars have been created or changed in the flow).

I have a smaller Scala code base to maintain (around 50k lines) and it is a breeze b/c many types are annotated, e.g. Money @@ Netto or String @@ InvoiceNumber. Beside Option this has been the greatest productivity gain vs. Java.