Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

Original Article ↗ Hacker News Discussion ↗

Gradual typing & the “gradual guarantee”

  • Many commenters like Ty’s gradual guarantee for legacy Python: removing annotations should not introduce new type errors, easing adoption in large untyped codebases.
  • Others argue gradual typing often leaves hidden Any/Unknown holes, so you can’t be sure critical code is actually checked. They want a way to assert “this file/module is fully typed”.
  • Several people explicitly request a TypeScript-style strict/noImplicitAny mode (or equivalent linter rules via Ruff) so teams can migrate from permissive to strict over time.

Pyrefly vs Ty: inference and list behavior

  • Pyrefly is praised for strong inference and stricter behavior, closer to TypeScript: e.g., treating my_list = [1,2,3]; my_list.append("foo") as an error.
  • Ty currently infers list[Unknown] for list literals, so appending anything is allowed; some see this as catering to legacy/dynamic styles, others as masking real bugs.
  • Ty developers clarify this is incomplete behavior; they plan more precise, possibly bidirectional inference and may even compromise on the pure gradual guarantee in this area.

Static vs runtime checks (Pydantic, beartype, Sorbet, etc.)

  • Runtime validators (Pydantic, beartype, zod-like tools) are seen as complementary at system edges (user input, JSON) but not a replacement for static checking, due to performance and coverage limits.
  • Some emphasize that as more of the codebase is statically typed, runtime checks can be pushed outward to boundaries.

Dynamic frameworks and hard-to-type patterns (Django, ORMs)

  • Django ORM is highlighted as extremely challenging to type: heavy use of dynamic attributes, lazy initialization, metaprogramming, and runtime shape changes.
  • Partial shims and descriptor-based typings are possible for common cases, but full soundness is considered impossible without constraining Django’s API or usage patterns.

Tooling, notebooks, and LSPs

  • There’s enthusiasm for Rust-based checkers as fast dev-time tools, especially with editor/LSP and notebook integration to catch errors before long-running cells.
  • Ty already ships some LSP features but is not yet a pyright/basedpyright replacement; full parity is expected to take significant time.

Ecosystem, business, and language-level reflections

  • Questions arise about Astral’s long-term business model (services, enterprise tools, possible acquisition) but this is seen as a generic OSS/VC concern.
  • Some argue that deep static typing in Python is inherently painful and that effort might be better spent migrating to natively typed languages; others report high ROI from incremental annotation of existing Python code.
  • Overall sentiment: multiple checkers with different philosophies (Pyrefly strict vs Ty gradual) are valuable, but the community wants clearer paths to “fully checked” subsets of Python.