Pyrefly and Ty: Two new Rust-powered Python type-checking tools compared

What is most striking about Python’s latest wave of third-party tooling is that they aren’t written in Python. Instead, many of the newer tools for project management, code formatting, and now type checking, are written in Rust.

This isn’t a swipe at Python; every language has its place. But modern language tooling demands a real-time feedback loop that Python can’t always deliver at the speed required. Rust fills that gap. Modern project management tools like uv and code formatters like ruff run fast and lean thanks to Rust.

The newest projects in this space aim to provide type-checking tools for Python that are faster and potentially more powerful than Python-based tools like mypy and pyright.

Ty from Astral (makers of the uv package manager and the ruff code formatter) and Pyrefly from Meta have essentially the same use case: providing high-speed type checking and language services for Python. Both have comparable performance, running many times faster than similar Python-based projects. This article tells you where these new tools stand right now in terms of usability and features.

Pyrefly

Pyrefly is not the first Python type-checking tool from Meta. Previously, the company delivered Pyre, written in OCaml. Pyre has since been retired; Pyrefly, written from scratch in Rust, replaces it.

Run Pyrefly out of the box on an existing Python codebase, and you’ll typically get a flood of errors the first time around. If you use the command pyrefly check --suppress-errors, all the flagged errors will be suppressed in your source via specially interpreted comments. You can then selectively remove those suppressions and run pyrefly check --remove-unused-ignores to clean up the codebase as you go. This allows you to migrate an untyped codebase gradually.

Pyrefly, like all modern Python tooling, uses pyproject.toml to store its project-level configuration data. You can also add per-directory configurations with standalone pyrefly.toml projects that use the same syntax. Or, you can provide directory-specific overrides for options in a single config file.

The list of linted error types is comparable to what mypy and Pyright can handle. Migrating from both tools is easy, as Pyrefly can do it automatically. In Pyright’s case, there’s almost a one-to-one mapping for the error-checking settings, so the change isn’t too jarring.

For a project in its early stages, Pyrefly already feels fleshed out. Detailed documentation, a VS Code extension, and even an online sandbox where you can try it out are all already here. If you are using the uv tool, you can run uvx pyrefly to experiment with it on a codebase without having to install anything. Note that this causes uv to be used as the virtual environment provider for Python, so it may generate spurious errors if you are using a different venv for your project.

Ty

Astral’s ty project is also still in its early stages, and it shows. Its documentation isn’t as fleshed-out as Pyrefly’s, and its feature set is less impressive. To be fair, the project was only recently made public and is admittedly in its early stages.

You can install Ty from pip or run it from uvx. It intelligently detects a source directory in a pyproject.toml-configured project, so it doesn’t mistakenly chew through Python files in your project’s virtual environment. But its configuration options are more minimal than Pyrefly’s; for instance, excluding files from checks is done via.gitignore or other external files rather than from configuration rules.

Ty’s ruleset for checking files seems more condensed than Pyrefly or existing tools, although it covers some cases not found elsewhere. For instance, while it doesn’t check for async errors, Ty does detect if class definitions have conflicting usages of __slots__, although the former seems like a far more common problem than the latter.

Despite being in its early stages, ty already has two key features nailed down. It is compatible with the Language Server Protocol, and it offers a VS Code extension to leverage that. Another plus—one significant enough to call out this early on—is the level of detail in its error reports. Pyrefly’s errors report the line number and type of error, but ty calls out the error akin to what you’d see in modern Python’s contextually detailed error messages.

Conclusion

With the performance playing field about level between the two tools, Pyrefly is the more immediately useful project. Pyrefly offers a broader existing feature set, better documentation, and tooling to allow elegant migration from other type-checkers and onboarding existing codebases. That said, ty is in its early stages, so it’ll be worth circling back to both tools once they are out of their respective alpha and beta phases.