Earlier quoted context omitted.
Guilt by association is very in vogue these days
These talented engineers could take their skills elsewhere. That's the message.
And make so much less money
Pyrefly: A new type checker and IDE experience for Python
111–120 of 177 posts
Re: Pyrefly: A new type checker and IDE experience for Python
#112Why 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.
> 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.
Re: Pyrefly: A new type checker and IDE experience for Python
#113The 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
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.
Re: Pyrefly: A new type checker and IDE experience for Python
#114Re: Pyrefly: A new type checker and IDE experience for Python
#115Why 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.
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 narrowe…
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.
Re: Pyrefly: A new type checker and IDE experience for Python
#116ofcourse it has it rewritten in rust.
Re: Pyrefly: A new type checker and IDE experience for Python
#117I'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…
Like Angular.
Re: Pyrefly: A new type checker and IDE experience for Python
#118Earlier quoted context omitted.
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.)
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.
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.
Re: Pyrefly: A new type checker and IDE experience for Python
#119This is very cool but why wouldn’t they just contribute to uv and ruff and ty https://github.com/astral-sh/ty
I just ran ty and it can't resolve any imports whereas pyrefly passes. Why would that be? I hate Python so much.
ty doesn't invoke a Python interpreter to discover imports yet — so you need to either set `VIRTUAL_ENV` or pass `--python` to configure your target environment. We'll expand support here in the future, but this part of ty's interface is intentionally minimal while we focus on core type checking features.
Re: Pyrefly: A new type checker and IDE experience for Python
#120Hi 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!
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…