Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyrefly: A new type checker and IDE experience for Python

engineering.fb.com

Post reply on HN
Print view View original

171–177 of 177 posts

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

#171

Post by johnisgood »

disgruntledphd2 wrote: post #168
johnisgood wrote: post #133

Earlier quoted context omitted.

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

I don't like autotools, but I suppose that would be a good fit here, and perhaps proper pre-build instructions (e.g. "pacman -S libfoo").

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

#172

Post by ashf023 »

mdaniel wrote: post #83
lynndotpy wrote: post #65

Earlier quoted context omitted.

Static typing is a big one, but I've been so steeped in Python that I don't appreciate it as much as maybe I should. The big thing for me is that most Rust projects are statically(ish) compiled (like go) and only need a `cargo build`. No venvs or pip commands or node/npm/nvm or make, etc.

Also, the Zen of Python is supposed to be one obvious way to do something but ddg "python dependency manager" and have a good laugh. That actually becomes triple lol for when uv steps in and says "uh, your pip requirements.txt is unsatisifyable, what are you even?!" And let me just say what an absolutely stellar job the rustc authors have done with the error messages. Just out of this world thoughtful. I have not yet…

"one obvious way to do something" describes almost none of Python. Easier said than done I guess, but I find Python particularly bad at it

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

#173

Post by disgruntledphd2 »

johnisgood wrote: post #171
disgruntledphd2 wrote: post #168

Earlier quoted context omitted.

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

I don't like autotools, but I suppose that would be a good fit here, and perhaps proper pre-build instructions (e.g. "pacman -S libfoo").

Totally, autotools helps. However, it's generally dependency issues that cause the problems, you're missing some header files etc. Finding out about these at configure time is better, but there's still a bunch of toil in identifying and getting those dependencies.

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

#174

Post by phlakaton »

team_pyrefly wrote: post #72
phlakaton wrote: post #10

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?

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.

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

#175

Post by lynndotpy »

johnisgood wrote: post #133
lynndotpy wrote: post #105

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.

Yes, I meant the words I said. I haven't used OCaml, and some C projects are "just make" but that's not the rule like it is with Rust projects.

The time I spend doing things is much more valuable than the time my computer spends doing things.

I can only speak for why I like to know a project is written in Rust. I didn't add the build time because I didn't care.

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

#176

Post by fastball »

muglug wrote: post #170
CoolCold wrote: post #165

Earlier quoted context omitted.

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.

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

#177

Post by fastball »

melodyogonna wrote: post #125
alisonatwork wrote: post #113

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…

Honestly I think this is a feature not a bug.

This is going to sound elitist, but if you can grok Python but can't grok Rust then you probably shouldn't be writing ecosystem tools for Python anyway.

Post reply on HN