Back to Devoured - June 12, 2026
DEVOURED
Static types and shovels

Static types and shovels

DevOps researchbackend Richard Barrell
The resurgence of static typing is driven by the evolution of type systems that actually assist developers rather than merely acting as bureaucratic paperweights.
What: Richard Barrell argues that static typing declined in the 2000s because early implementations, like those in C++98 or early Java, functioned as 'paper shovels'—verbose systems that provided little developer benefit. Modern systems like TypeScript, Rust, and Haskell have replaced these with nullability tracking, sum types, and type inference, turning static typing into a productivity tool.
Why it matters: This perspective suggests that developer preference for language features is often a rational response to the quality of tooling rather than industry trends.
Deep dive
  • Distinguishes between 'product types' (early Java/C++) and 'sum/union types' (Haskell/Rust/TS).
  • Emphasizes the role of nullability checks in eliminating common runtime errors.
  • Identifies type inference as a key factor in reducing verbosity.
  • Notes that static types provide metadata for IDEs to power better autocomplete and refactoring tools.
Decoder
  • Sum Type (Tagged Union): A data structure that can hold one of several different types of values at a time, often used to model state machines where only specific fields are valid at any given time.
  • Product Type: A standard record or struct that contains multiple fields simultaneously.
  • Type Inference: The ability of a compiler to automatically deduce the data type of an expression without explicit type annotations from the developer.
Original article

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.

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.
Explore all 50 articles in today's digest

Fresh dev news, AI-digested daily. Never miss a trend at devoured.fyi