Pyrefly: A new type checker and IDE experience for Python

[lacker]

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....

[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

[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).

[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!

[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.

[morkalork]

They're all static type checkers right? None for runtime?

[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.

[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.)

[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.

[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

[smitty1e]

> Why is "written in Rust" a feature to be mentioned? Who cares?

If one is a "purist", the idea of non-python tool involvement may dissatisfy.

Scare-quoting "purist", given the general lack thereof anywhere in Open Source, python itself being a case in point.

[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.)

[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.

[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?

[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.

[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 ...

[weekendcode]

ofcourse it has it rewritten in rust.

[kingkongjaffa]

This is very cool but why wouldn’t they just contribute to uv and ruff and ty https://github.com/astral-sh/ty

[djinnish]

I think astral and meta were both working on their own type-checkers independently. My current understanding is that meta released so they could preempt the initial release of ty. It seems like they're a bit further ahead in development. Not sure if there are going to be any real differences between the two down the line.

[munro]

That's sort of how I felt about things before, but the reality I believe is we wouldn't have uv if they 'just contributed to poetry'.

[simonw]

ty is so new right now - it only got its current name a few weeks ago!

[koakuma-chan]

I just ran ty and it can't resolve any imports whereas pyrefly passes. Why would that be? I hate Python so much.

[ldng]

NIH + copyright

[colesantiago]

Because this has been tested at Meta / Facebook scale which means it's faster for any Python codebase massive and small.

Since Meta built this, I have confidence this will be maintained more than others and I will use this and ask for Pyrefly experience in the future.

[aleksanb]

To repeat an earlier comment of mine from the launch of uv on hn (tl; dr: these new type checkers never support django):

The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code.

The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods.

I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck the constructs we think you SHOULD be using".

[vivzkestrel]

how does this compare to mypy

[oellegaard]

I lost all interest when I saw VS Code. I don’t get why people consider this a suitable IDE for python when you can have a real IDE like PyCharm.

[rw2]

non AI IDEs are going to have a hard time in the future.

[bpshaver]

Unsure how this comment is relevant