Static types and shovels

I have a simple theory about why static typing became much less popular in the 2000s to early 2010s and started to get more popular again around the mid to late 2010s. It isn't because programming is a fashion led industry, but because the quality of the static type systems that were widely available improved.

Here's an analogy: say you want to dig a hole, would you rather use a shovel or your hands? If the shovel is any good then obviously you'd use the shovel. But what if the only shovel available to you was made of paper? You'd just be flailing uselessly at the ground with it. You'd be better off digging barehanded.

With a dynamic type system, you have to do all of the thinking about the states and contents of the variables and fields in your program yourself, with your own brain. The computer doesn't help you at all, nor does it hinder you. It's analogous to digging with your hands.

On the other hand, if you're given a poor static type system like the ones that were popular in the 90s and early 00s, such as the ones in early Java or C++98, it's analogous to a paper shovel. These static type systems fail to even help you with simple things like distinguishing nullable from non-nullable pointers. They don't have sum types, only product types. Meanwhile they require you to spend a lot of effort manually writing out type names all over the place. BufferedReader bufferedReader = new BufferedReader(new FileReader(filename)); is a small disaster.

On the other hand, if you're given a poor static type system like the ones that were popular in the 90s and early 00s, like early Java or C++98, it's analogous to being handed a shovel made out of paper. These static type systems impose large costs and they fail to even help you with simple things. They don't distinguish nullable from non-nullable pointers. They don't have sum types (also known as tagged unions or discriminated unions), only product types (like structs). Meanwhile they require you to expend a lot of effort manually writing out type names all over the place. It is a waste of brains and effort to write out things like BufferedReader bf = new BufferedReader(new FileReader("input.txt")); when a nice type system would just infer most variable types for you.

If you contrast this to a modern type system like the one in say TypeScript, Haskell, MyPy, Swift or Rust, you'll always get:

Some way of distinguishing nullable from non-nullable types. Haskell has Maybe t. TypeScript has T | null. Swift has T?. Rust has Optional<T>. The type system can easily tell you where all the null checks need to be and if you missed one. In practice you almost never see null pointer errors at runtime.
At least one of sum types or union types, which let you follow the "Make invalid states unrepresentable" practice. This means you can have objects representing state machines, they have multiple fields, and each field exists when and only when the system is in a relevant state.
Some kind of type inference. We don't need to write let x: number = 5; when the compiler can just work out that let x = 5; is definitely a number.

Another thing which made static type systems more useful is that IDE features like method name completion have become more widespread. In the 90s Intellisense was a killer feature in Visual Studio, whereas in the 2020s similar features are available in just about every IDE and editor. So information you put into a static type system yields extra productivity benefits, entirely aside from its usefulness for checking programs for errors.

In conclusion:

A good dynamic type system is better than a bad static type system.
But now we have much better static type systems than we used to.