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

81–90 of 177 posts

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

#81

Post by lacker »

samwgoldman wrote: post #70
lacker wrote: post #41

I'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…

Hey Kevin, we overlapped for a bit during your time at FB when I was working on Flow. Nice to hear from you! I’m working on Pyrefly now, but worked on Flow for many years before. For what it’s worth, we are taking a different approach compared to Flow and have explicitly prioritized open source and community building, something I know we both care a lot about. Of course, nothing is guaranteed and we’ve seen plenty of…

Best of luck!

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

#83

Post by mdaniel »

lynndotpy wrote: post #65
mdaniel wrote: post #63

Earlier quoted context omitted.

> but it's a lot easier for me to hack on Rust projects That static typing is nice, I wonder if it's going to catch on one day. The amount of energy spent trying to bend dynamically types languages into being real ones is just comical. Even the standard library is barely typed, so they give no fucks https://github.com/python/cpython/blob/v3.13.3/Lib/re/__init... What does it accept? Who knows. What does it return? Do…

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 gotten on board with their compile time vs safety and insight tradeoff, but I can see why they chose those two axes

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

#84

Post by 90s_dev »

owebmaster wrote: post #76
90s_dev wrote: post #75

Earlier quoted context omitted.

JSX supports * Autocompletion * Type checking * Syntax highlighting * Lack of runtime string parsing Tagged template literals don't.

JSX does not support any of these, it was coded by others. tagged template literals can have all of these, some already exist¹ and doesn't need a build step. 1. https://marketplace.visualstudio.com/items?itemName=bierner....

The only inherent feature of JSX is compile time "parsing" whereas tagged literals inherently require runtime string parsing.

But yeah other than that you're right. I'm just talking about first-class VS Code support. Which to me means a lot.

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

#85

Post by ffsm8 »

90s_dev wrote: post #80
owebmaster wrote: post #76

Earlier quoted context omitted.

JSX does not support any of these, it was coded by others. tagged template literals can have all of these, some already exist¹ and doesn't need a build step. 1. https://marketplace.visualstudio.com/items?itemName=bierner....

Matt, who works pretty high level on VS Code, has written some amazing plugins. But they still don't have all the first-class features of JSX. I don't think this plugin works with type checking for instance.

I believe the argument was that jsx doesn't support that either, which should be correct as far as I know.

They're all features in the jsx ecosystem that are provided by other libs, which are often preconfigured with projects utilizing jsx.

I did miss a lot of the tooling I've gotten used to the last time I made a weekend project utilizing lit webcomponents for sure, but I believe the people advocating for it usually rejoice in having less tooling in their development pipeline - it's just a fundamental disconnect between people that have learned and gotten used to current frontend development and people that don't really want to bother with it, looking for simpler solutions with less moving parts.

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

#86

Post by mdaniel »

BrawnyBadger53 wrote: post #66
mdaniel wrote: post #63

Earlier quoted context omitted.

> but it's a lot easier for me to hack on Rust projects That static typing is nice, I wonder if it's going to catch on one day. The amount of energy spent trying to bend dynamically types languages into being real ones is just comical. Even the standard library is barely typed, so they give no fucks https://github.com/python/cpython/blob/v3.13.3/Lib/re/__init... What does it accept? Who knows. What does it return? Do…

Hindly Milner type inference needs to catch on

Type inference is handy, but as an observation source code is 90% written for humans - I believe that CPython knows what types they are, that's how TypeError even exists, but seeing "def doit(erthang):" doesn't help me in the slightest. Often PyCharm can figure it out, because bless their hearts, but then developers whine about "wwwaaa, pycharm too slo grug use ed" and then one gets AttributeError in production because who could have foreseen

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

#87

Post by adsharma »

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

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

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

#88

Post by Spivak »

mdaniel wrote: post #86
BrawnyBadger53 wrote: post #66

Earlier quoted context omitted.

Hindly Milner type inference needs to catch on

Type inference is handy, but as an observation source code is 90% written for humans - I believe that CPython knows what types they are, that's how TypeError even exists, but seeing "def doit(erthang):" doesn't help me in the slightest. Often PyCharm can figure it out, because bless their hearts, but then developers whine about "wwwaaa, pycharm too slo grug use ed" and then one gets AttributeError in production becau…

Pyright being so fast has gotten my coworkers (as well as myself) who dare to code using tooling not made by JetBrains an easy to use instant-feedback type checker that can be used in CI. So I think it's a huge win.

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

#90

Post by misnome »

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…

It’s not a rule. It’s a guide to being idiomatic.

It’s like laughing at photographers for not using the “rule of thirds” sometimes.

Post reply on HN