pyrefly vs ty in 2026: Which Rust Type Checker Wins?
pyrefly vs ty in 2026: Which Rust Type Checker Wins?
TL;DR
Two new Rust-powered Python type checkers — Meta's pyrefly and Astral's ty — arrived in 2025 and are rewriting the performance ceiling of what type checking can be. Both are 10–60x faster than mypy and pyright on full runs, making the old Python-based tools feel like dial-up. ty is faster (especially in the editor, where it recomputes diagnostics 500x faster than pyrefly), while pyrefly has better conformance today (~58% vs ~15%) and broader feature completeness. Neither is production-ready for all codebases yet — but if you're evaluating now, ty is the better bet for editor-centric workflows and pyrefly for catching the most errors on a cold CI run.
Key Takeaways
- ty (Astral) is the fastest — 10–60x faster than mypy/Pyright on CLI; 500x faster than Pyrefly for LSP incremental updates (4.7ms vs 2.38s)
- pyrefly (Meta) has better typing spec conformance today — ~58% vs ty's ~15%, comparable to mypy's ~57%
- Both crush pyright on raw speed — Django 5.2.1 benchmarks: ty 578ms, pyrefly 911ms, pyright 16.3s
- Different philosophies: ty uses a "gradual guarantee" (conservative, fewer false positives); pyrefly uses aggressive inference (catches more errors)
- Neither is production-stable — both are in alpha/beta as of March 2026; pyright/mypy remain the safe choice for critical workloads
- Astral joins OpenAI in March 2026 — big signal that ty development continues at scale
- Migration guides exist for both — pyrefly ships with mypy/pyright migration tooling built-in
The Rust Tooling Wave Hits Python
Something has been happening in developer tooling. Tools that were "fast enough" for a decade are suddenly not — because Rust rewrites have redefined what fast means. Ruff replaced ESLint/Black for Python linting. uv replaced pip/Poetry for package management. Biome rewrote ESLint and Prettier in Rust for JavaScript.
Now that same wave is crashing into Python's type checking world, historically dominated by two incumbents: mypy (the original, Python Software Foundation-backed reference implementation) and pyright (Microsoft's production-grade checker, the engine behind Pylance and VS Code's Python support).
In May 2025, Meta open-sourced pyrefly — a Rust rewrite of their internal Pyre type checker, claiming 1.8 million lines of code checked per second and up to 35x speedups over Pyre. In December 2025, Astral (the team behind Ruff and uv) launched ty — an "extremely fast Python type checker and language server, written in Rust," built on the same Salsa incremental computation framework that powers rust-analyzer.
The comparison has been trending on Lobste.rs and Hacker News ever since. So let's look at the actual data.
Meet the Four Contenders
mypy — The Original Standard
mypy started as Guido van Rossum's personal project and became the reference implementation for PEP 484 type hints. It's written in Python (with a self-hosting mypyc optimization pass), mature, battle-tested, and has the widest ecosystem support — more stubs, more plugins, more CI integrations than any other checker.
Install: pip install mypy
Speed verdict: Slowest of the four. PyTorch's torch subdirectory takes 24.7 seconds.
pyright — Microsoft's Production Tool
Pyright is written in TypeScript, runs on Node.js, and powers VS Code's Python language server (Pylance). It's the most feature-complete type checker available today — comprehensive support for typed dicts, protocol matching, overloads, type narrowing, and generics. Microsoft uses it in production across massive codebases.
Install: npm install -g pyright or pip install pyright
Speed verdict: Faster than mypy, but still slow compared to Rust. Django 5.2.1 takes 16.3 seconds.
pyrefly — Meta's Rust Rewrite
Meta built Pyre (their internal Python type checker) years ago and used it across the Instagram codebase. Pyrefly is the public, Rust-rewritten successor — open-sourced under MIT in May 2025. It takes an aggressive stance on type inference, trying to infer types even when annotations are absent, and claims to check 1.8 million lines per second.
Install: pip install pyrefly
Speed verdict: 14x faster than mypy/pyright by Meta's benchmarks. Django 5.2.1 takes 911ms.
ty — Astral's New Checker
Astral — the team that already gave Python developers Ruff (the fastest Python linter) and uv (the fastest Python package manager) — announced ty in December 2025. Built on the Salsa framework (fine-grained incremental computation), ty is designed from the ground up for editor-first performance, where sub-10ms diagnostic updates make real-time feedback possible.
Install: uv tool install ty@latest or pip install ty
Speed verdict: Fastest of the four. Django 5.2.1 takes 578ms. LSP incremental updates on PyTorch: 4.7ms.
Benchmark Numbers: The Speed Story
Let's put the numbers side by side. These benchmarks come from independent testing on real-world codebases:
Full Codebase Check (Cold Run)
| Codebase | ty | pyrefly | mypy | pyright |
|---|---|---|---|---|
| Django 5.2.1 | 578ms | 911ms | N/A | 16,324ms |
| PyTorch (full) | 4.0s | 13.0s | N/A | 262.7s |
| PyTorch (torch dir) | 1.1s | 2.3s | 24.7s | 48.1s |
| mypy (mypyc dir) | 74ms | 136ms | 3,544ms | 2,852ms |
| home-assistant | 2.19s | N/A | 45.66s | 19.62s |
On raw throughput, ty is 2–3x faster than pyrefly and both Rust-based tools are 10–50x faster than mypy and pyright.
Editor / LSP Performance (Incremental Updates)
This is where ty's architecture really separates itself. After editing a load-bearing file in the PyTorch repository:
| Checker | Incremental re-check |
|---|---|
| ty | 4.7ms |
| pyright | 386ms (80x slower) |
| pyrefly | 2,380ms (500x slower) |
This gap isn't incidental — it's architectural. ty uses Salsa, a framework for fine-grained incremental computation where only the specific computations that depend on changed data are invalidated. Pyrefly uses module-level incrementalism (roughly: if a module changes, recheck everything that imports it). For editor use cases where a single keystroke can trigger a re-check, this 500x gap matters enormously.
Correctness: The Conformance Gap
Speed is only half the story. Type checkers need to be correct. The Python typing community maintains a conformance test suite — a formal battery of tests measuring whether a checker's behavior matches the typing specification.
| Checker | Conformance pass rate |
|---|---|
| Zuban | ~69% |
| pyrefly | ~58% |
| mypy | ~57% |
| ty | ~15% |
This is ty's current weak point. 15% is low — though it's worth understanding what this number means. The test suite is comprehensive, and ty is relatively new (announced December 2025). Astral's published roadmap targets >60% conformance, and the number is climbing rapidly. But today, if your codebase relies on advanced typing features — complex protocol matching, TypeVar variance, overload resolution — ty may miss errors that pyright catches.
Pyrefly's 58% is more encouraging. It's essentially on par with mypy (57%), which has been refined over a decade. For a tool that's been public for under a year, that's strong evidence Meta put serious work into the typing semantics before open-sourcing.
Philosophy: Two Schools of Thought
Beyond benchmarks, pyrefly and ty have meaningfully different stances on how a type checker should behave. This isn't just implementation detail — it affects daily developer experience.
Pyrefly: Aggressive Inference
Pyrefly tries to be maximally helpful by inferring types even when you haven't annotated them. If you write:
def process(data):
return data * 2
Pyrefly may infer data based on call sites and flag None * 2 as an error. This "aggressive inference" catches real bugs — but can also produce false positives, especially in partially-typed codebases where inference chains produce unexpected results.
The philosophy: type checking should do the work for you, even on legacy code.
ty: The Gradual Guarantee
ty follows what Astral calls "the gradual guarantee" — the principle that removing type annotations from working code should never introduce new type errors. ty introduces an Unknown type (distinct from Any) to represent the absence of annotation. Code typed as Unknown flows without complaints; code annotated as Any explicitly opts out of checking.
def process(data): # data: Unknown — ty stays silent
return data * 2 # no error
def process(data: Any): # data: Any — explicitly untyped
return data * 2 # still no error (you opted out)
The philosophy: a type checker should never yell at you for code that worked before you added types.
For teams migrating large legacy codebases incrementally, ty's approach is much more practical. For teams starting greenfield projects with complete type coverage, pyrefly's aggressive inference catches more edge cases.
Feature Completeness & Ecosystem Maturity
This is where mypy and pyright still lead — and where the new tools have the most catching up to do.
| Feature | mypy | pyright | pyrefly | ty |
|---|---|---|---|---|
| Production stability | ✅ | ✅ | ⚠️ alpha | ⚠️ beta |
| TypedDict support | ✅ | ✅ | Partial | Partial |
| Protocol matching | ✅ | ✅ | Partial | Partial |
| Overload resolution | ✅ | ✅ | ✅ | Partial |
| Intersection types | ❌ | ❌ | ❌ | ✅ |
| Negation types | ❌ | ❌ | ❌ | ✅ |
| LSP / Language server | Via plugins | ✅ (Pylance) | ✅ | ✅ |
| VS Code extension | Via Pylance | ✅ | ✅ | ✅ |
| Stub ecosystem | ✅ Large | ✅ Large | Growing | Growing |
| Migration tooling | — | — | ✅ Built-in | ❌ |
| Online playground | ❌ | ❌ | ✅ pyrefly.org | ✅ play.ty.dev |
Two notes worth highlighting:
Intersection and negation types are a genuine ty innovation. Neither mypy nor pyright supports these natively, yet they're part of the typing spec and useful for modeling complex constraints. This is ty building toward the spec's theoretical ceiling, not just reimplementing the status quo faster.
Migration tooling is pyrefly's current advantage. Meta ships conversion utilities that analyze your existing mypy/pyright config and translate ignore comments. If you're migrating a large existing codebase, pyrefly reduces friction significantly.
Migration Guide
From mypy to ty
# Install ty
uv tool install ty@latest
# Run on your project
ty check .
# Or with pip
pip install ty
python -m ty check .
ty doesn't yet have automated mypy config migration, so you'll need to manually map mypy.ini settings to ty's configuration (documented at the ty GitHub repo). Expect ty to miss some errors that mypy catches — treat the initial run as a baseline rather than a full audit.
From mypy/pyright to pyrefly
# Install pyrefly
pip install pyrefly
# Run the migration helper (analyzes existing config)
pyrefly migrate --from mypy
# Check your project
pyrefly check .
# Explore errors interactively
# Visit pyrefly.org/sandbox to paste code snippets
Pyrefly's migration tooling reads your existing type ignore comments and converts them to pyrefly equivalents. Meta used this internally when migrating the Instagram codebase.
Staying on pyright (valid choice)
If you need production stability and maximum conformance today, pyright remains the right answer. It runs everywhere (npm or pip), integrates with every IDE, has the largest stub ecosystem, and Microsoft actively maintains it. Speed is its only weakness — and 16 seconds on Django is only a problem if you're running it in a tight feedback loop.
Decision Matrix
Use mypy if:
- You need maximum compatibility with the broadest Python ecosystem
- Your CI pipeline has existing mypy integration and custom plugins
- You're on a legacy codebase with years of accumulated
# type: ignorecomments - You need rock-solid stability above all else
Use pyright if:
- You use VS Code (Pylance is pyright under the hood — you're already using it)
- You need the most complete typing spec support available today
- Your team is comfortable with TypeScript/Node.js tooling in CI
- Performance isn't a blocker
Use pyrefly if:
- You want Rust-level speed today with acceptable (mypy-level) conformance
- You're migrating from mypy or Pyre and want tooling assistance
- You want aggressive type inference to catch errors in partially-annotated code
- You're willing to deal with alpha-quality rough edges
Use ty if:
- You're building editor extensions or developer tooling where LSP latency matters
- You're starting a new project and want to invest in the stack that Astral is building
- You prioritize developer experience over maximum error-catching
- You want intersection/negation types and are comfortable with lower conformance for now
What This Means for the Python Ecosystem
The arrival of pyrefly and ty is the most significant shift in Python type checking since mypy became standard. The performance gap is too large to ignore — when ty checks Django in 578ms and pyright takes 16 seconds, that's not a marginal improvement, it's a qualitative change in what real-time feedback looks like.
Astral's track record with Ruff (which went from zero to dominant Python linter in about two years) suggests ty will follow a similar trajectory. Ruff didn't win because it was perfect on day one — it won because it was fast, actively maintained, and systematically closed the feature gap. Astral's joining OpenAI's Codex team in March 2026 adds headcount and infrastructure to that bet.
Meta's commitment to pyrefly is backed by real production scale — the tool has to work on the Instagram codebase, which is one of the largest Python codebases in the world. That's a different kind of conformance pressure than a benchmark suite.
The incumbent tools aren't going anywhere yet. But the question is no longer "will Rust replace mypy and pyright" — it's "which Rust type checker wins, and when?"
Methodology
- Benchmarks sourced from independent testing by Edward Li (blog.edward-li.com) and pydevtools.com, March 2025 — January 2026
- Conformance data from sinon.github.io's typing spec conformance analysis
- Astral ty performance numbers from the official ty launch post (astral.sh/blog/ty, December 2025)
- Meta pyrefly numbers from engineering.fb.com and InfoQ coverage, May 2025
- Sources consulted: 9 primary sources across official announcements, independent benchmarks, and community discussions
Running Rust-based tools across your Python stack? Also see oxc-vs-swc: Rust JavaScript Toolchain in 2026 and Biome vs ESLint vs Oxlint in 2026 for how the same trend is playing out in the JavaScript ecosystem.
Interested in compiler rewrites for other languages? See our breakdown of tsgo vs tsc: TypeScript's Go Compiler Rewrite.