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

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!

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.

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

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.

Happy to see instructions for integrating into Vim/Neovim: https://pyrefly.org/en/docs/IDE/#other-editors

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

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?

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?

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.

How close to a statically-typed language does such addition make Python ?

Sounds like a project that is trying to solve too many things at once ...

ofcourse it has it rewritten in rust.

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

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

how does this compare to mypy

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.

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