Static types and shovels (2026)

Lobsters Hottest Tools

Summary

The author argues that the resurgence of static typing in the 2010s was due to improved type systems (e.g., TypeScript, Haskell, Rust) that offer nullable type handling, sum types, and type inference, contrasting with poor static typing in earlier languages like Java and C++98.

<p><a href="https://lobste.rs/s/eiknm1/static_types_shovels_2026">Comments</a></p>
Original Article
View Cached Full Text

Cached at: 06/10/26, 07:49 PM

# Static types and shovels Source: [https://carefully.understood.systems/blog-2026-06-10-static-type-shovel.html](https://carefully.understood.systems/blog-2026-06-10-static-type-shovel.html) [Home](https://carefully.understood.systems/)[C\.V\.](https://carefully.understood.systems/cv.html)[Blog posts](https://carefully.understood.systems/blog_list.html)[Contact](mailto:[email protected])[Previous post: Connection pools must propagate connection errors](https://carefully.understood.systems/blog-2026-06-05-connectionpools.html)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"](https://blog.janestreet.com/effective-ml-revisited/)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\. © Copyright 2026 Richard Barrell

Similar Articles

Why Is Every AI Agent Written in TypeScript?

Reddit r/AI_Agents

The article explores why TypeScript has become the dominant language for building AI agents and agent frameworks, questioning why alternatives like Rust or C++ aren't more prevalent.

Thoughts On Integers (2023)

Lobsters Hottest

A blog post discussing the design of integer types in various programming languages, arguing that Rust's approach of forcing explicit sizing and signedness selection is superior to languages with a default `int` type.

Quoting Mitchell Hashimoto

Simon Willison's Blog

Mitchell Hashimoto comments on the increasing fungibility of programming languages, using Bun's rewrite from Zig to Rust as an example, suggesting that languages are no longer a source of lock-in.