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
Pyrefly: A new type checker and IDE experience for Python
161–170 of 177 posts
Re: Pyrefly: A new type checker and IDE experience for Python
#162Earlier 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…
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
#163Earlier 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.…
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
#164Earlier 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!
Re: Pyrefly: A new type checker and IDE experience for Python
#165Earlier 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?
Re: Pyrefly: A new type checker and IDE experience for Python
#166Earlier 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…
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
#167Earlier 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.
Re: Pyrefly: A new type checker and IDE experience for Python
#168Earlier 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.
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
#169Earlier 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
Re: Pyrefly: A new type checker and IDE experience for Python
#170Earlier 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.