Type checking is a symptom, not a solution

Overall reaction

• Most commenters strongly reject the article’s thesis that type checking is a “symptom,” calling the argument confused, naive, or even ragebait/AI slop.
• A minority find the perspective interesting, reading it as a critique of function-centric architectures and a call for higher-level, time-aware, message-passing abstractions rather than an attack on types per se.

What types actually provide

• Repeated claim: types are explicit interfaces and contracts, not incidental bureaucracy. They define the “shape” of inputs/outputs and enable black-box composition.
• Types are described as specifications, theorems, or invariants; programs are proofs that satisfy them. Even untyped or assembly code implicitly has types, just unchecked.
• Strong static typing is framed as an automated, always-on subset of testing that catches classes of bugs early and localizes their source.

Scale, correctness, and tooling

• Many dispute the article’s “standard answer is scale” framing: types are about correctness at any size, though their value grows with codebase/developer count.
• Examples: TypeScript and Python typing catching bugs in tiny scripts; IDE autocomplete and refactoring depending heavily on static types.
• Others note types can enable over-engineering or more complex designs, but still see them as net-positive.

Hardware and electronics comparisons

• Multiple commenters with hardware experience say the article misrepresents electronics: HDLs have types; EDA tools perform extensive automated verification, rule-checking, and simulation.
• Some argue physics acts as a brutal “runtime type checker” (wrong voltage = burnt board), hence the need for even more checking up front.
• Several emphasize that software’s state space and dynamism (recursion, concurrency, unbounded data) make it inherently more complex than static circuits.

Unix pipelines and black-box composition

• The portrayal of UNIX pipelines as a superior, typeless composition model is widely criticized.
• Pipelines are said to be brittle, “stringly typed,” and reliant on undocumented assumptions about formats, delimiters, and ordering; small output changes often break chains.
• Some point to shells that pass structured data or JSON-oriented tools as implicit acknowledgments that richer “types” are needed even there.

Complexity, architecture, and higher abstractions

• Many agree that better architecture, simpler interfaces, and isolation are crucial—but note these are largely expressed through types and module boundaries.
• Skepticism is high that one can eliminate “unnecessary complexity” to the point that automated checks are largely irrelevant, especially in large, evolving systems.
• A few connect the article to older ideas like correctness-by-construction and dataflow/statechart-based systems, but say such approaches haven’t displaced typed languages in practice.

Dynamic languages and real-world anecdotes

• Commenters share pain stories from untyped or loosely typed ecosystems (old TensorFlow/Python, large pre-TypeScript JS codebases, shell scripts) where missing type info made APIs hard to use and evolution error-prone.
• Static typing in libraries is highlighted as crucial for avoiding accidental breaking changes and for making contracts clear to downstream users.