Type Inference Was a Mistake

Original Article ↗ Hacker News Discussion ↗

A polemic arguing that “type inference was a mistake” prompts a broader examination of how much type information should be explicit in source code. Commenters counter that inference greatly reduces boilerplate and works well when paired with IDE tooling, but many still advocate explicit types for public APIs and complex functions to aid readability, code review, and maintenance outside rich editors. The overall theme is not whether types are useful, but where to draw the line between inferred and annotated types so code remains both concise and clearly understood.

Language-specific clarifications

  • Several commenters note the article misstates Haskell: function type annotations are optional (except in rare advanced cases), though considered good practice. Rust generally requires explicit top-level function signatures.
  • OCaml, F#, Swift, C#, C++, and TypeScript are repeatedly cited as examples where type inference is heavily used and often appreciated.
  • Some point out that in C++ and Rust you can use partial annotations (e.g., underscores or auto with concepts) to express intent without fully spelling long types.

Readability, documentation, and APIs

  • Strong support for explicit types on public APIs, module boundaries, and non-private functions. These act as documentation and stabilize interfaces.
  • More disagreement around internal helpers and local variables: many prefer inference there to reduce noise; others want explicit types everywhere for readability, especially without IDE assistance.
  • Several emphasize that code is often read in diffs, reviews, browsers, blogs, or books, where hover-based type info is unavailable; they argue code should “stand alone.”

Ergonomics, boilerplate, and complex types

  • Advocates of inference highlight reduced boilerplate, especially for deeply nested or generic types, iterators, lambdas, and range pipelines. Without inference, C++-style types can dominate the code.
  • Critics counter that hiding complex types encourages over-complex designs and makes refactoring and understanding harder.

IDE and tooling perspectives

  • Many say modern IDEs and language servers mitigate readability issues by showing types on hover or as inline hints, and even auto-inserting explicit types on request.
  • Some propose format-on-save or codemods that automatically materialize inferred types into source for commits, while letting editors hide them during day-to-day work.

Scope and “how much” inference

  • A recurring middle-ground view:
    • Explicit types for top-level functions, interfaces, and complex logic.
    • Inference for local variables, obvious assignments, and at call sites (inferring type parameters).
  • Some mention bidirectional type checking and dependent/gradual typing as frameworks where partial annotations are necessary and beneficial.

Broader critiques and defenses

  • Detractors argue inference causes “spooky” distant errors, hurts readability, and can be overused under schedule pressure.
  • Supporters argue these are misuse and style problems, not flaws of inference itself, and that type inference research and tooling bring substantial real-world benefits.