Live data from Hacker News

Pyrefly: A new type checker and IDE experience for Python

engineering.fb.com

161–170 of 177 posts

Re: Pyrefly: A new type checker and IDE experience for Python

#161
post #156

Earlier quoted context omitted.

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

I love the language, but I do hate the import system too, it makes everything harder

I just put __init__.py everywhere, not sure it does something but to be safe

Re: Pyrefly: A new type checker and IDE experience for Python

#162

Earlier quoted context omitted.

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 prob…

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, thi…

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.

Re: Pyrefly: A new type checker and IDE experience for Python

#163

Earlier quoted context omitted.

Sure, but in this case they are both implementations of a spec defined by PEPs, so a bit more like gcc vs clang (less tightly bound than those, of course, in design decisions). Neither company is trying to invent a new language here.

The current major type checkers, mypy and pyright, are also based on the same PEPs, but you can still see differences between them. For example, my codebase passes pyright in strict mode, but mypy results in a bunch of type errors. I'd expect pyrefly and ty to be slightly different from each other. See also: https://github.com/microsoft/pyright/blob/main/docs/mypy-com... https://htmlpreview.github.io/?https://github.…

Sure, I agree. I’m just saying that most of their defacto disagreements are because of ambiguity in the specs, not because one of them is (intentionally) choosing to fork.

Fwiw I think performance and features are kind of intertwined here, since Pyright’s extra speed makes it possible to infer more things that are not easy for mypy, especially in an LSP implementation.

Pyright is very impressive in that second link (conformance check), very much a product of Eric Traut & others dedicating a lot of energy to this single problem.

Re: Pyrefly: A new type checker and IDE experience for Python

#164
post #120

Earlier quoted context omitted.

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?

Re: Pyrefly: A new type checker and IDE experience for Python

#165
post #164

Earlier quoted context omitted.

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.

Re: Pyrefly: A new type checker and IDE experience for Python

#166

Earlier quoted context omitted.

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, thi…

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, y…

That is because the language is really just in alpha, not open-source yet, and not much useful for anything except GPU kernel programming.

In the future that will change, Modular is aiming to get it ready for open-source by Q4 2026. By then it'll have full Python interop, so you can use existing Python packages in Mojo. Unlike Rust/Julia, Mojo does not have to bootstrap a community and ecosystem from scratch.

Re: Pyrefly: A new type checker and IDE experience for Python

#167

Earlier quoted context omitted.

You want languages that can be compiled similarly to "cargo build"? Well, Go is one of them. Many C projects are just one "make" command away. OCaml has "dune build". Odin has "odin build", too. There are a lot of other languages I am missing here though.

Oh yeah, right about Go. Odin and OCaml are languages I don't use but have heard their names. I'm not saying Rust has exclusivity here, I'm only explaining why I like to know a project was written in Rust.

Okay, fair enough. :)

Re: Pyrefly: A new type checker and IDE experience for Python

#168

Earlier quoted context omitted.

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

It makes no sense to me. You found it easier to contribute to Rust projects because... Rust projects are significantly easier to build? What? You can just do "dune build" in OCaml, or run "make" for many C projects. Plus, it is also significantly slower to build Rust projects, you should have probably added that.

> run "make" for many C projects.

This generally fails miserably, in my experience. It's normally a dance of error: libfoo missing, followed by install (which is generally only straightforward on linux), followed by libbar is missing etc.

Don't get me wrong, I have built lots of non-trivial C projects, but it's not straighforward at all (maybe if you always work in C it's easier).

Re: Pyrefly: A new type checker and IDE experience for Python

#169
post #118

Earlier quoted context omitted.

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.

It has not. They decided to change the messaging to reflect what the language is to today because people kept thinking it is already a superset

Thanks for the explanation, that makes more sense than them giving up.

Re: Pyrefly: A new type checker and IDE experience for Python

#170
post #164

Earlier quoted context omitted.

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.
Post reply on HN