Type Inference Was a Mistake

Original Article ↗ Hacker News Discussion ↗

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.