Reading the Revival of Static Typing Through the "Shovel" Metaphor

A blog post offers a fresh perspective on the debate surrounding programming language type systems. The article titled “Static types and shovels,” featured on Lobsters, uses the analogy of “shovel quality” to analyze the rise and fall of static typing—explaining why dynamic typing was favored from the 2000s to the early 2010s, and why static typing regained support in the late 2010s.

The author’s argument is straightforward: “To dig a hole, would you rather use a shovel or your bare hands? If the shovel is decent, you’d obviously use it. But what if the only shovel you can get is made of paper? It’s better to dig with your hands than to beat the ground with a useless shovel.” This metaphor vividly captures the essential value of static typing and the importance of its implementation quality.

Old-Type Systems as Paper Shovels

What the author calls “paper shovels” are the static type systems of Java and C++98, widely used from the 1990s to the early 2000s. These type systems failed to provide even basic protections. For example, they lacked mechanisms to distinguish between nullable and non-nullable pointers. Additionally, they did not support sum types (also known as tagged unions or discriminated unions), only supporting product types (structs). This made it impossible to practice the key design principle of “making invalid states unrepresentable.”

Moreover, type inference was almost nonexistent, forcing developers to manually write type names everywhere. Code like BufferedReader bufferedReader = new BufferedReader(new FileReader(filename)) is a typical example. The author dismisses this as “a waste of brainpower and effort.” When type systems increase rather than decrease the developer’s burden, it amounts to trying to dig a hole with a paper shovel.

On the other hand, dynamically typed languages offer no computer assistance but also no interference. The author compares this to “digging with bare hands.” Developers who found that the costs of Java and C++98’s static typing (verbosity, strict constraints) did not provide proportionate benefits gravitated toward dynamically typed languages. This aligns with the widespread adoption of Ruby, Python, and JavaScript from the 2000s to the early 2010s.

Three Pillars of Modern Type Systems

From the late 2010s to the 2020s, the situation changed dramatically. Type systems in languages such as TypeScript, Haskell, MyPy, Swift, and Rust began to function as “good shovels.” The author identifies three common features that modern type systems should possess.

First, the ability to distinguish between nullable and non-nullable types. Examples include Haskell’s Maybe t, TypeScript’s T | null, Swift’s T?, and Rust’s Optional<T>. The type system automatically identifies where null checks are needed and detects omissions, drastically reducing the frequency of NullPointerException at runtime.

Second, sum types or union types. These enable the practice of “Make invalid states unrepresentable.” In objects representing state machines, the type system ensures that each field can only exist in specific states. This mechanism allows type-safe design of application state transitions.

Third, powerful type inference. Developers need to explicitly write type names less often, reducing code volume. In modern statically typed languages, the verbose descriptions seen in older Java and C++ are becoming unnecessary.

Practical Implications of Type System Evolution

What this article suggests is that the superiority of static versus dynamic typing is not an intrinsic issue; rather, the sophistication of the type system as a tool influences developers’ choices. The phenomenon of the JavaScript ecosystem embracing static typing with the advent of TypeScript, and Rust’s rapid rise in systems programming, are backed not just by trends but by practical benefits.

This discussion is also important in the context of the rise of AI code assistants. In an era where AI generates code, type information serves as a foundation to ensure the accuracy of generated code and to validate AI output. The more powerful the type system, the wider the range of mechanical checks that can be performed on AI-generated code’s reliability.

Editorial Opinion

Short-term Impact: Over the next six months, migration to TypeScript and Rust is expected to accelerate, particularly in the enterprise domain. In projects to replace legacy systems running on older Java and C++, the completeness of the type system will become a decisive criterion for language selection. The axis of choosing between Go’s simple type system and Rust’s expressive type system will also be a practical consideration.

Long-term Perspective: Over a one- to three-year span, new languages may emerge that pursue a balance between expressiveness and ease of use in type systems. Currently, Rust dominates systems programming and TypeScript dominates web front-end, but there is significant room for a language that integrates the advantages of both. Additionally, a “type-driven AI code verification” approach, where AI-generated code quality is validated by the type system, could become a standard practice.

Question from the Editorial Team: The principle of “making invalid states unrepresentable” is ideal, but in real projects, type system constraints can sometimes hinder design flexibility. How should engineers on the ground judge the trade-off between type safety and development speed? Also, the extent to which AI code generation can leverage type information is a topic that warrants future attention.

References

• Static types and shovels — Published 2026-06-10