Pyrefly: A new type checker and IDE experience for Python
176 comments
·May 17, 2025lacker
samwgoldman
Hey Kevin, we overlapped for a bit during your time at FB when I was working on Flow. Nice to hear from you!
I’m working on Pyrefly now, but worked on Flow for many years before. For what it’s worth, we are taking a different approach compared to Flow and have explicitly prioritized open source and community building, something I know we both care a lot about.
Of course, nothing is guaranteed and we’ve seen plenty of volatility in bigco investments to infra lately, but I do believe we’re starting this journey on the right foot.
Cheers, Sam
lacker
Best of luck!
theptip
Meta seems to place a pretty high premium on controlling its open source projects, especially dev tooling. I guess dating back at least to the git maintainers telling them they were doing things wrong with their monorepo and refusing to upstream scale fixes, which precipitated their migration to mercurial (who were more than happy to take the contributions).
Given the change velocity of internal tooling you can understand why owning your own project makes sense here.
90s_dev
JSX is my favorite thing to come out of Facebook (also the only good thing).
null
owebmaster
I feel bad for that people that love JSX and don't know about lit-html yet.
90s_dev
JSX supports
* Autocompletion
* Type checking
* Syntax highlighting
* Lack of runtime string parsing
Tagged template literals don't.
troupo
> and don't know about lit-html yet.
You mean strings with custom non-standard syntax and weird rules of hooks, sorry, directives?
null
simlevesque
Like Angular.
team_pyrefly
Hi folks, I work on the Pyrefly team at Meta. Our FAQ covers a good number of the questions raised here: https://pyrefly.org/en/docs/pyrefly-faq/. I can also try to answer some of your questions. Thanks for taking a look!
muglug
At Slack we have an internal Rust-based Hack typechecker that’s about 20% faster than the OCaml one (we use both)
Did you see better speedups over Pyre? Aka did I leave stuff on the table…
samwgoldman
Hack is quite a bit more optimized than Pyre was, but Pyrefly is at least 10x faster than Pyre on the IG codebase.
I didn’t know about the Rust-based Hack checker— that’s really cool!
muglug
Where do those speed ups come from? 10x seems extraordinary for a task that’s pretty IO-bound. Was Pyre ineffectively parallelised or something?
ThePhysicist
Seems there are at least three Rust-based competitors for type checkers in Python now (Microsoft, Facebook, Astral), and of course there's still mypy.
Yossarrian22
Close, Microsoft’s type checker Pyright is Typescript. Its still faster than mypy for me though.
chrisweekly
Pls forgive my ignorance, but how is Typescript (a superset of Javascript) used to type-check Python?
thraxil
You can write a parser and type checker for pretty much any language in pretty much any language. It's just text files as input and text as output.
ItsHarper
They're saying pyright is a Python type checker, but it's written in Typescript, not Rust.
Yoric
There's nothing magical to type-checking Python. You can write this in any programming language. TypeScript is actually a pretty nice language for writing static analysis tools.
dist-epoch
just like the Python compiler/interpreter is written in C.
null
morkalork
They're all static type checkers right? None for runtime?
Yossarrian22
Yes. If you want runtime validation of data you’re taking in people recommended pydantic. If you’re looking for runtime validation within your own code I’ve seen people use beartype, though to be honest I don’t personally understand the value added from it
rationably
...or Marshmallow, which allows one to do many complex validations in a relatively trivial manner.
null
null
homarp
this is the official announcement, but pyrefly was previously discuted a few weeks ago: https://news.ycombinator.com/item?id=43831524
"Today we’re releasing Pyrefly as an alpha. At the same time, we’re busy burning down the long-tail of bugs and features aiming to remove the alpha label this Summer. "
doug_durham
Why is "written in Rust" a feature to be mentioned? Who cares? So my type checker has memory protection and is compiled. I'm not running my type checker on an embedded system or in a mission critical service. It seems kind of like "written in Erlang". I'd prefer to have non-performance critical code for Python written in Python. That way the broader community can support and extend it.
lynndotpy
Have you used Rust before? As a user, the speed and safety is nice. But as a developer, Rust projects are easier to hack on and contribute to.
That's kind of the whole appeal of Astral. I know Python better than Rust, but it's a lot easier for me to hack on Rust projects. The whole appeal of Astral is that they want to bring Rust-quality tooling to Python.
mdaniel
> but it's a lot easier for me to hack on Rust projects
That static typing is nice, I wonder if it's going to catch on one day.
The amount of energy spent trying to bend dynamically types languages into being real ones is just comical. Even the standard library is barely typed, so they give no fucks https://github.com/python/cpython/blob/v3.13.3/Lib/re/__init...
What does it accept? Who knows. What does it return? Don't worry about it
lynndotpy
Static typing is a big one, but I've been so steeped in Python that I don't appreciate it as much as maybe I should.
The big thing for me is that most Rust projects are statically(ish) compiled (like go) and only need a `cargo build`. No venvs or pip commands or node/npm/nvm or make, etc.
mixmastamyk
regex.match takes strings and returns a match object. There are most likely stubs, if you are new to it and need support.
BrawnyBadger53
Hindly Milner type inference needs to catch on
fastasucan
Real ones?
faitswulff
> Rust projects are easier to hack on and contribute to.
This was actually the subject of a study at the University of Waterloo:
> We find that despite concerns about ease of use, first-time contributors to Rust projects are about 70 times less likely to introduce vulnerabilities than first-time contributors to C++ projects.
johnisgood
> Rust projects are easier to hack on and contribute to.
You can say that about any languages that you yourself know, or other people know. There are beautiful codebases in many other languages, and awful ones in the same languages.
If your Rust codebase has a lot of unwraps and lifetime annotations (among other things), I will probably not find it a joy to contribute to it, at all.
lynndotpy
> You can say that about any languages that you yourself know, or other people know.
No, I'm saying that Rust was easier to hack on and contribute to (on my own) when I had never written any Rust before. Rust (and almost Go) is the only language I can confidently say this about. It's not even in my top 5 strongest languages now, but I still stand by this.
E.g. Look at the build instructions for Gimp and all its prerequisites: https://developer.gimp.org/core/setup/build/
Very normal C++ project, ~500 words of instructions. Once I started thinking about using a chroot to fix dependency issues after I'd already built bebl and gegl, I gave up, because I ran out of free time. It didn't matter how much C++ I knew.
Rust projects, comparatively, almost never demand that. It's almost always just `cargo build`, with some rare exceptions (e.g. The one exception I know of for which this is not true for is Graphite, which is a web app and also uses npm. )
rafram
Rust has very arcane syntax and a lot of rules that developers coming from interpreted / garbage-collected languages (like the ones using these tools) would have a hard time grasping. It’s easy for people who are already familiar with it, but isn’t that always the case?
lynndotpy
I'm saying the opposite, actually. I found it easier to contribute to Rust projects (with zero hours Rust experience, and much Python/Java/C/C++/Ada) because Rust projects are significantly easier to build. (Just a `cargo build` in the default case.)
nine_k
An LSP is performance-critical code. It directly affects responsiveness of your IDE, or even the viable scope of a project that the LSP can handle.
Rust is both CPU- and memory-efficient, quite unlike Python. (It could have been OCaml / Reason, or Haskell, they are both reasonably fast and efficient, and very convenient to write stuff like typecheckers in. But the circle of possible contributors would be much narrower.)
yawaramin
The circle of possible contributors doesn't really matter. It's a Meta project, they have others written in OCaml and to this day they manage to have contributors eg https://github.com/facebook/flow because they hire and pay them.
maleldil
To be fair, pyright's performance as an LSP is tolerable. The main issue to me is running the type checker as a pre-commit hook or as part of CI. Mypy is awful, though.
dist-epoch
> I'd prefer to have non-performance critical code for Python written in Python
A type checker is performance critical code. You can watch how Pylint, just a linter, written in Python, lints your source code line by line. It's so slow it can take 30 seconds to update the linting after you change some lines.
misnome
Or entire projects abandoning checking because mypy is so damned slow for anything non-trivial
mixmastamyk
Many of these make the mistake of running against an entire codebase instead of checking vcs first and only running against changed files.
maleldil
You still need to type-check files that weren't changed if they were affected by a file that was.
beeb
It makes it easy to find performant and quality software by searching for "[insert tool description] rust", I personally don't mind! Seeing how 95% of the tools I use on the daily are written in Rust, I love finding new ones and am rarely disappointed.
tomrod
Shortcut for "noticeably fast."
Open source Rust is still review able.
fastasucan
>Why is "written in Rust" a feature to be mentioned? Who cares?
A lot of people. Correct or not, I think "written in rust" have become synonymous with "very much faster than the alrernatives" in the pyrhon community.
mcbuilder
I feel like 70% of open source projects on GitHub say written in the language that they were written in
bpshaver
I feel like the likelihood that a project will say what language it is written in is much higher if that language is Rust. I like Rust but I do find this trend a little annoying. (Even though I acknowledge that "written in Rust" probably means the tool is relatively new, not buggy, and easy to use.)
neongreen
> Even though I acknowledge that "written in Rust" probably means the tool is relatively new, not buggy, and easy to use.
I genuinely chose the language for one of my projects based on this reasoning. I want to be in the nice UX gang.
immibis
[flagged]
null
xwowsersx
Happy to see instructions for integrating into Vim/Neovim: https://pyrefly.org/en/docs/IDE/#other-editors
melodyogonna
The Rust code written here is so easy to follow but all these new Python tooling being written in Rust worries me, it adds yes another vector to the N-language problem.
I hope Mojo can offer something here
nine_k
For the Python ecosystem, it's natural to use Python where Python can cope, and a high-performance language where it cannot. There are two such languages in wide use around Python: Rust, and, inevitably, C. So N = 3.
(C, to my mind, should be eventually phased out from application programming altogether, so N would be 2, but it's a loooooong process; Python may become a legacy language before it converges.)
fluidcruft
Yes but the idea is that by slightly upgrading python code to mojo (which is a controlled superset of python), you get complied very high performance code. So for example if it were possible to convert mypy to mojo it could be as fast as rust but pythonic.
Hasnep
By the way, Mojo seems to have given up on being a strict superset of python, I think they're aiming for more of a C++ to C relationship where there are some small differences, but the majority of code will work without modification.
alisonatwork
Sadly I think the ship has sailed and Rust has hit critical mass now. Personally I find it aesthetically awkward, but for Python integration and tooling it seems like Rust has become the default C replacement. You would think Python devs might have preferred something more superficially Pythonic like Nim or perhaps something more C-ish like Zig, but those projects don't have the same buzz so here we are. There's probably more young devs who are into Rust than C nowadays.
I am not holding out much hope for Mojo because it feels deeply embedded in the AI/LLM hype space instead of being presented to Python devs outside of that niche as a useful language extension in its own right.
melodyogonna
I don't think it really matters whether Rust has hit critical mass or not tbh, just the fact that it is entirely a new language to learn with very different semantics compared to Python is a blocker for many people.
Mojo right now is not much better, but I've seen Python compatibility factor into the language design and semantics again and again. It is not enough to be a language that looks like Python, like Nim, things also have to behave the same when the semantics of static typing allows.
Mojo is not deeply embedded in the AI/LLM hype, there is nothing in the language that is targeted specifically for AI. The standard Library has a GPU package for general-purpose gpu programming, but that isn't AI specific.
alisonatwork
I am sure the language is capable, but if you search "mojo python" then the top hit is https://www.modular.com/mojo where the first line on the page talks about AI inference and the first code example seems to be referencing ML models or something completely unrelated to the everyday Python programming that people outside of the data science field do.
Alternatively if you try to search for the Github repo for Mojo, you end up here: https://github.com/modular/modular Which is all about control planes and k8s and AI something something. Sure, it seems this is just a monorepo under which one of the folders actually is Mojo itself, but this packaging does not inspire confidence that the creators of the language are interested in building a language that exists outside of their ecosystem.
fastball
Honestly I think this is a feature not a bug.
This is going to sound elitist, but if you can grok Python but can't grok Rust then you probably shouldn't be writing ecosystem tools for Python anyway.
lucas_membrane
I just tried pyrefly on a project that really needed it. It complained about an assignment of a new value to a global int variable within a function, even though the function contained the 'global' statement that should have made that OK, I think. I know that globals and assigning to them here and there are problematic for real good software, but I am surprised that Pyrefly is stricter than python on something that I don't see as a type- checking issue. But it did find a decent list of other problems that I haven't finished working my way through.
I had gotten so messed up trying to put together a quicky hobby-type program to create a data structure of perhaps a hundred data items in various overlapping and inter-related hierarchies, tuples, dicts, and lists akimbo, that I gave up on it about 10 days ago. I hypothecated that bondage and discipline might be the way to control the confusion, so I'm rewriting, using SQLite for the dataflow from function to function, lots of little tables and no optional fields. Can anyone opine on whether that is a sensible option?
samwgoldman
Thanks for trying it out! If you run into any blockers, please let us know by filing a GitHub issue or sending us a message on Discord. Pyrefly is still alpha software, so bugs are expected, but your feedback is extremely valuable as we work to squash them.
phlakaton
I'm curious to know more about the Pyre to Pyrefly transition, specifically the rewrite in Rust. Was that merely a case of trading in a lesser-known language for the language du jour? Were there specific advantages they wanted to get out of Rust?
team_pyrefly
Hi! We address this question in our FAQ and probably could do a longer blog post about our experience after we are further along: https://pyrefly.org/en/docs/pyrefly-faq/#why-rust
phlakaton
Thanks! But my real question is why the departure from OCaml. I'm guessing performance wasn't the rationale there.
adsharma
> Not only is Pyrefly written in a new language (Rust instead of OCaml), but its design deviates in a major way from Pyre.
I'm sure you had reasons to do it this way. But given sufficient time to market, implementing the algorithm in pyre and then tooling/llm assisted conversion to pyrefly would've been preferable.
May be you'd have had some humans in the loop initially. But that tech is getting better and aligned with the direction Meta and the rest of the industry are taking.
Yes, I'm biased :)
wiseowise
> tooling/llm assisted conversion to pyrefly would've been preferable
Is this how it is now? Not the first time I hear this brainrot idea.
globalnode
Its probably cool n' all but fb isnt getting any of my attention. They'd need to come up with AGI for that to happen, and even then I'd shrug it off.
frogperson
I agree. I simply can't support anything Mark Zuckerberg does at this point.
surajrmal
This is an open source developer tooling project, not a product which Zuckerberg had anything to do with. What's the point of ignoring it?
voidfunc
Guilt by association is very in vogue these days
globalnode
> Why we built Pyrefly: Back in 2017, we embarked on a mission to create a type checker that could handle Instagram’s massive codebase of typed Python
They're saying this on fb.com. How does it not have anything to do with fb?
The feedback section takes you to fb's github.
insane_dreamer
what if they pull off the metaverse? ;)
globalnode
ok that would be impressive, " no no we're not interested in AGI -- we want to become god "
liotier
How close to a statically-typed language does such addition make Python ?
amelius
Sounds like a project that is trying to solve too many things at once ...
I'm a little worried on behalf of the "Python Language Tooling Team" at Meta, because uv has been so popular, and I wouldn't be surprised if ty wins out in this space.
So watch out, or this will become like Atom or Flow, an internal competitor of a technology that is surpassed by the more popular external open source version, leaving the directors/vps muttering to themselves "It's too bad that this team exists at all. Could we get rid of them and just switch to the open source stuff?"
Perhaps just something for the manager (Aaron Pollack?) to keep an eye on....