EMemptysea·Apr 29, 2025
A rewrite of https://github.com/facebook/pyre-check in rust?
In Pyrefly - A faster Python type checker written in Rustmeta
pyre-check
OCaml2018–2025
meta / pyre-check · Archived
pyre-check
Performant type-checking for python.
24Distinct people
26Mentions
0Explicit recommenders
7.2KGitHub stars
What to know before exploring
What it is
Performant type-checking for python.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- google/pytype · linked in 5 of the same discussions
- microsoft/pyright · linked in 3 of the same discussions
- python/mypy · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year26 dated mentions
Observed mentions: 2018-05-11 16:24:10 UTC to 2025-04-29 15:17:18 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
26 sourcesDid you come across pyre in your search? MIT license and pretty fast.
https://github.com/facebook/pyre-check
In Pylyzer – A fast static code analyzer and language server for PythonPyre, written in OCaml, is the closest thing that's stable. It has been discussed on HN a couple of times. Here is the 2021 discussion: https://news.ycombinator.com/item?id=27107647.
Note that Pyre does not support Windows (https://github.com/facebook/pyre-check/issues/554) and only provides wheels for x86_64 Linux and macOS (https://pypi.org/project/pyre-check/0.9.18/#files). While I don't use Windows, it makes me reluctant to adopt it. First, I want Windows users to be able to contribute to my projects that work on Windows. Mypy and (predictably) Pyright won't create an obstacle for Windows users. Second, the limited number of platforms makes Pyre seem a little internal-toolish.
It may still be worth it. As of today, actually, one of my projects has a Pyre branch. I want to see what it is like developing with it.
In Mypy 1.6https://github.com/facebook/pyre-check
https://github.com/facebook/flow
https://github.com/facebook/infer
https://github.com/facebook/hhvm/tree/master/hphp/hack
In Should I Rust or Should I Go?Pyright is pretty recent and started development years after mypy. But some of pyright's design goals (laziness for LSP) would have made it very difficult to do in mypy without a very large refactor/rewrite. Pyright is implemented in typescript for better LSP/vscode integration and performance. pytype (google's type checker) is only one I know that predates mypy for when it started development.
Pyre's reason is interesting, https://github.com/facebook/pyre-check/issues/38. Pyre is based off of Hack, facebook's php compiler. Facebook made pyre to re-use tooling/techniques from Hack on python. Secondary reason is performance. Pyre is done in OCaml and having same performance in type checker implemented within python is hard.
In Pyright: Static Type Checker for PythonI can vouch for use of Pyright as LSP for neovim and helix. Very useful, especially the strict mode.
I usually pair it with pyre, another great tool
https://github.com/facebook/pyre-check
In Pyright: Static Type Checker for Pythonone of their employees could doubtless say more, but at the very least I'm familiar with the actively developed https://github.com/facebook/pyre-check
In Learning OCaml in 2023Python is statically typed though. [1][2][3][4]
These aren't just some third-party tools bolted on. The type annotation syntax is built into the language[5] and standard library[6][7].
I personally find static typing to be more trouble than it's worth most of the time. Industry typing metalanguages are not expressive enough to deal with even fairly basic real-world programs and force you to write bad code to work around the type checker's stupidity. And, of course, you still have to write tests. Maybe someday they'll catch up to Idris. Python's static typing is no better, but at least it allows you to turn it off when it's not worth it.
[1]: https://github.com/microsoft/pyright
[2]: https://github.com/python/mypy
[3]: https://github.com/google/pytype
[4]: https://github.com/facebook/pyre-check
[5]: https://peps.python.org/pep-3107/
[6]: h
Read the rest
I'd be curious if the pyre-check compilation is any faster for you either by removing the inlining optimization flag (the `-Oclassic` here https://github.com/facebook/pyre-check/blame/36243764ab81a82...) or whether there's a way to compile pyre-check to bytecode instead of the native compilation step (which unfortunately it looks like there's no easy way to modify pyre-check's build config to do so).
In OCaml at BloombergPyre[1] is about 20k loc of ocaml[2].
$ time make -C source -j8
make: Entering directory '/home/fnord123/src/download/pyre-check/source'
../scripts/setup.sh --configure
Build info: Linux x86_64 @ Mon Aug 23 2021 (development build)
abort: no repository found in '/home/fnord123/src/download/pyre-check/source' (.hg not found)!
Git commit: 1e4dd5a39db1631fd13a3a8df74d6e0f5d801fbc
dune build @install -j auto --profile dev
menhir parser/generator.{ml,mli}
Warning: 31 states have shift/reduce conflicts.
Warning: 5 states have reduce/reduce conflicts.
Warning: 77 shift/reduce conflicts were arbitrarily resolved.
Warning: 75 reduce/reduce conflicts were arbitrarily resolved.
make: Leaving directory '/home/fnord123/src/download/pyre-check/source'
real 0m43.700s
user 4m3.030s
s
Read the rest
ys 0m41.005s
I must be doing something wrong.
[1] https://github.com/facebook/pyre-check
[2]
$ tokei
-------------------------------------------------------------------------------
Language Files Lines Code Comments Blanks
-------------------------------------------------------------------------------
Autoconf 2 235 204 3 28
C 15 242641 165361 60669 16611
C Header 10 14267 2617 11094 556
Coq 10 2391 1968 220 203
CSS 5 713 540 44 129
Dockerfile 2 71 42 11 18
HTML 2 35 30 0 5
INI 1 12 9 0 3
Java 31 2654 2080 267 307
JavaScript 7 867 752 61 54
JSON 17 939 939 0 0
Makefile 5 229 145 45 39
Markdown 47 7213 7213 0 0
OCaml 791 229096 198302 10455 20339
Python 398 61909 50119 2917 8873
Shell 5 111 59 34 18
SVG 2 2 2 0 0
TeX 4 929 642 129 158
Plain Text 5 457 457 0 0
TOML 1 2 2 0 0
TypeScript 2 130 84 20 26
-------------------------------------------------------------------------------
Total 1362 564903 431567 85969 47367
-------------------------------------------------------------------------------
mypy has implementations in other languages – PyCharm's is in Java, Facebook's Pyre's is in OCaML https://github.com/facebook/pyre-check
In Adoption of Mypy for Python type checking: 45% already use it, 40% don't plan toI work at Instagram, which is a O(millions) LOC Python monorepo with massive throughput and a large engineering team. It's actually quite nice — but our code is heavily, heavily typed. It would be miserable without the type system. Some of the older parts of the codebase are more loosely typed (although they're shrinking reasonably quickly), and those sections are indeed a huge pain to ramp up on.
Part of the success of IG's large Python codebase is FB's investment into developer tooling; for example, FB wrote (and open-sourced, FWIW) our own PEP-484 compliant type checker, Pyre [1], because mypy was too slow for a codebase of our size.
1: https://github.com/facebook/pyre-check
In Guido van Rossum joins MicrosoftAlso Pyre [0] by Facebook and Pytype [1] by Google. More importantly, the core part (type annotations) allowing these libraries to exist has been added to core python for years now and keeps on evolving, so it is an ongoing effort.
EDIT: As mentioned below, also added Pyright [2] by Microsoft
[0] https://github.com/facebook/pyre-check
[1] https://github.com/google/pytype
[2] https://github.com/microsoft/pyright
In Guido van Rossum joins MicrosoftThe reasons turn out to be decently boring here. Zoncolan [0] and Pyre [1], which Pysa shares core libraries with, are also written in OCaml, and the language made sense to use from the perspective of both sharing code and having people who are proficient and comfortable writing in OCaml working on the project.
[0]: https://engineering.fb.com/security/zoncolan/
[1]: https://github.com/facebook/pyre-check
In Pysa: An open source tool to detect and prevent security issues in Python codeFacebook/pyre-check: Performant type-checking for Python
2 points · Open discussionShowing the 15 most recent of 26 sources. Enable JavaScript to search and browse every indexed mention.