"We're building a new static type checker for Python"

Original Article ↗ Hacker News Discussion ↗

Excitement and Project Goals

  • Many commenters are enthusiastic, based on prior experience with Ruff and uv, and expect similar “step change” improvements in speed and UX.
  • The checker is currently codenamed “red_knot” and is being developed in the open within the Ruff repo; it’s not ready for general use yet.
  • Stated goals (from linked threads): fast, highly incremental static analysis suitable both for CI batch runs and IDE/LSP-style interactive checking, likely using Rust and salsa for incremental computation.

Comparisons with Existing Type Checkers

  • Strong appetite for an alternative to mypy; complaints include:
    • Slowness on large codebases (though experiences vary widely).
    • Less precise analysis, many false positives, weaker inference, and difficulty with “Pythonic” patterns.
    • Awkward plugin/stub ecosystem and uneven third‑party stubs.
  • Pyright is widely praised for quality and precision, but:
    • Its Node.js dependency is a deal-breaker for some.
    • Performance is “ok but could be better.”
  • Others mention pytype, Pyre, and runtime tools (beartype, TypeGuard, PyContracts, icontract); the new checker is expected to be static only, but some wish it would optionally support runtime checks.

Fragmentation, Standards, and Django

  • Some worry a third major checker will exacerbate divergence (mypy vs Pyright vs new tool), making CI and team workflows painful when tools disagree.
  • Others respond that:
    • Syntax and semantics are largely standardized via PEPs and the typing community.
    • Multiple active implementations help drive out spec ambiguities and converge behavior over time.
  • Django support is a major concern:
    • Mypy wins today because of its plugin interface and django-stubs.
    • Other checkers are seen as “DOA” for large Django codebases without comparable plugin capabilities.
    • It’s unclear whether the new checker will support Django-level dynamism.

Business Model and Sustainability

  • Several commenters question how a VC-backed company can sustain open-source tooling like Ruff, uv, and a checker.
  • A linked explanation describes a strategy of selling vertically integrated enterprise products (e.g., private package registries) to companies already using the tools.
  • Some doubt the size or uniqueness of such markets versus cloud-provider offerings; others are content as long as tools remain open source but worry about long‑term maintenance if funding dries up.

Typing Philosophy and Python’s Direction

  • Ongoing debate:
    • One side: Python’s charm was dynamic typing; if you want static types, choose another language.
    • Other side: people often can’t choose the language (e.g., ML/AI and legacy codebases), and gradual typing dramatically improves refactoring, IDE support, and team safety on large projects.
  • Several describe a progression: enjoying dynamic Python early on, then coming to rely heavily on type hints as projects and teams scale.

Ecosystem and Future Directions

  • Some see Astral as delivering practical solutions faster than official bodies and hope for:
    • A unified toolchain: formatter, linter, type checker, package manager, task runner, build, deploy, and maybe a future Python interpreter in Rust.
  • There’s curiosity about why Python needs so many generations of tooling, and discussion of “gradual typing” as a general trend in dynamic languages.
  • A few argue for entirely new statically typed “Python-like” languages, but most acknowledge Python’s ecosystem lock‑in as decisive.