Ty: A fast Python type checker and language server

Original Article ↗ Hacker News Discussion ↗

Performance vs Existing Type Checkers

  • Multiple users benchmarked ty against mypy and Pyright:
    • mypy (warm cache) ~18s vs ty ~0.5s on a “fairly large” project.
    • On another codebase: ty 0.2s vs Pyright 4.7s; in another: ty 2.5s vs Pyright 13.6s; mypy ~0.74s vs ty ~0.11s on a smaller OSS repo.
  • Several people initially thought ty had failed to run because it was so fast.
  • Rust implementation is seen as a major driver of speed versus Python-based tools, with some arguing that type-checkers are especially sensitive to data-structure and tree-walking performance.

Accuracy, Maturity, and False Positives

  • Ty is repeatedly described (including by its developers) as pre‑alpha / not production‑ready.
  • Users report many diagnostics being incorrect (e.g., 1,599 mostly false positives vs 10 real errors from Pyright on the same project).
  • Developers explicitly say they expect a “good chunk” of current errors to be wrong and invite bug reports.

Tooling Integration and LSP / Editor Support

  • There is already a VS Code extension; current LSP functionality is limited to diagnostics and go‑to‑type‑definition.
  • Plans include a full LSP server with code completion and broader language‑server features, but with modest expectations for early sophistication.
  • Ty is currently a separate binary from Ruff; long‑term, people want a unified toolchain, similar to how Ruff absorbed formatting.

Environment & Python Version Handling

  • Ty can auto-detect environments via .venv, VIRTUAL_ENV, and being run through uv/poetry/pdm/hatch; missing env detection manifests as unresolved third‑party imports.
  • It currently defaults to an older Python version, which explains errors like datetime.UTC “not existing”; devs plan to change default to the newest supported version and already honor versions from pyproject.toml / virtualenv metadata.

Extensibility, Plugins, and Library Support

  • Some users strongly want extensibility (e.g., Django, dataclasses before PEP‑681, pytest fixtures), arguing otherwise they must “write worse code to please the checker.”
  • Ty’s developers say they are not planning a plugin architecture for now:
    • Prefer driving improvements in the typing spec and embedding special‑case support for major libraries directly.
    • Note that robust plugin support would deeply entangle ty’s internal type model and Rust plugin mechanisms.
  • Others see “no plugins” as a feature: plugin requirements make cross‑project type checking fragile.

Comparison with Pyright, Pylance, and Basedpyright

  • Pyright is widely praised as the current “gold standard” for correctness and features, but criticized for memory usage and, on some codebases, speed.
  • Some report Pyright being slow or OOM‑prone; others find it the most reliable among existing tools.
  • Basedpyright is highlighted as a more feature‑complete, Pylance‑like fork of Pyright.
  • Ty is seen as much faster but currently less capable in inference, especially around inheritance and complex patterns; users express hope it can eventually match Pyright’s precision.

Other Rust Type Checkers and Ruff/uv Ecosystem

  • Facebook’s Rust-based pyrefly is noted as a parallel effort; both pyrefly and ty reuse Ruff’s parser/AST, but otherwise are separate projects.
  • Rust is portrayed as a “sweet spot” for language tooling, and Astral’s prior work (Ruff, uv) is repeatedly cited as proof.

Python Typing & Language Debates

  • There’s extensive discussion of Python’s bolted‑on, evolving type system vs TypeScript’s more holistic design.
  • Limitations of Python typing specs (kwargs, dynamic patterns, complex ORMs like Django/SQLAlchemy, pandas) are seen as a bigger blocker than any single checker.
  • Some argue that many “crazy” dynamic patterns simply cannot be perfectly type‑checked without executing code; others counter that tools should aim to match the “real-world Python” in practice.
  • Broader debate about dynamic vs static languages: some wish Python had been designed as statically typed; others defend dynamic features and see type checking as an optional discipline.

Business Model and Trust Concerns

  • Multiple commenters ask how Astral plans to monetize, wary of the now-familiar pattern: open‑source tooling → VC funding → “not capturing enough value” → relicensing or lock‑in.
  • Astral respondents reiterate a plan of paid services built atop free tools (e.g., CI/CD, hosted/private registries) and emphasize:
    • Code is genuinely open source.
    • There is already visible external contribution and an intent to build a real community.
  • Some suggest that even in a worst‑case “rug pull,” the community would retain valuable, forkable Rust tooling.

Adoption Experiences and Ecosystem Impact

  • Several users immediately swapped mypy for ty in editors or tried it on mid‑sized codebases and were impressed by speed and additional feedback, while acknowledging correctness issues.
  • There is enthusiasm for Astral’s emerging “toolchain” (uv + Ruff + ty) as a de‑facto standard for Python development, replacing a fragmented ecosystem of slow tools.
  • A few question whether multiple competing checkers (ty, pyrefly, Pyright, mypy) are necessary; others see competition as healthy given differing goals (speed, strictness, ecosystem fit).