Hacker Newsnew | past | comments | ask | show | jobs | submit | typedpython's commentslogin

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!


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…


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!


Where do those speed ups come from? 10x seems extraordinary for a task that’s pretty IO-bound. Was Pyre ineffectively parallelised or something?


IO bound, how you define that? From my perspective, modern consumer grade SSDs/NVMes producing 7GB/s-8GB/s (yep, Giga Byte per second) for reads gives me 1/7-1/8 of second to load that data in RAM the rest of the 1 second is for CPU.


"pretty" was doing too much work, but there's the twin cost of reading and parsing the file, which usually needs to be done twice (once for static reflection, and once for analysis). The reading and parsing eats up about 16% of the analysis phase, and slightly more overall — maybe 20% of the total runtime.


Parsing is not IO and clearly an area you can get much better performance in-program.


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


Thanks! But my real question is why the departure from OCaml. I'm guessing performance wasn't the rationale there.


> 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 :)


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


Hi Hackernews, our team launched an Alpha of our new Python type checker and IDE extension today. It supports type inference, go to definition and find references in your IDE. The blog links to a podcast where a few engineers from our team talk about how we made it. We address a good number of questions in our FAQ: https://pyrefly.org/en/docs/pyrefly-faq/, and are happy to answer additional questions that you may have.


Hi! I'm on the team behind Pyrefly. Thanks for taking a look and raising the need for poetry support. We added a GitHub issue to track that here: https://github.com/facebook/pyrefly/issues/166


We go into it a bit more here: https://pyrefly.org/en/docs/pyrefly-faq/ The short answer is that the scale of the Python projects we work on is huge. Pyre is the only checker that can scale for our needs today. To bring modern features like type inference and better IDE integration, a full rewrite needed to happen. We are not done just yet, but have been using our massive codebases to test the performance and flexibility of the checker. Thanks for the question!


We totally get why you might be skeptical and even address this in our FAQ: https://pyrefly.org/en/docs/pyrefly-faq/#how-do-i-know-this-...

We know we can't just ask for trust upfront. Instead, we want to earn it by showing up consistently and following through on our commitments. So, take us for a spin and see how we do over time. We're excited to prove ourselves!


Thanks for giving this a try! We go over how to use the upgrade tooling (`--suppress-errors`) in the guide here: https://pyrefly.org/en/docs/installation/. This is intended to make upgrading from different versions of type checkers easier. It’s something we use internally and wanted to share with the community along with the checker itself.

We also allow you the ability to suppress whole classes of errors if you want to ignore specific error types and avoid inline ignores: https://pyrefly.org/en/docs/configuration/ A word of caution: this will ignore future errors of this type as well.

First, make sure your project is properly configured and then follow the instructions. `--suppress-errors` will add ignores inline allowing the project to check cleanly. We have thought about a feature that allows you to keep suppressions in a separate file, but we have not put it on the roadmap yet. If this is something important for your workflow, we would like to learn more - please add a feature request on GitHub.



Hi Hackernews, I’m on the team working on Pyrefly at Meta. We address a lot of the comments in our FAQ: https://pyrefly.org/en/docs/pyrefly-faq/. I will try to address some questions directly too!

Pyrefly is a work in progress, but you can install it from pypi and/or try our alpha VSCode extension if you are interested. You may still get false positive errors on your project as we are still burning down bugs and some features. We would love comments, bugs, or requests on our GitHub as you try it out.

Lastly, one of our team members is giving a talk at PyCon about the design if folks are interested: https://us.pycon.org/2025/schedule/presentation/118/. We didn’t expect much attention before then, so thanks for taking a look!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: