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

131–140 of 177 posts

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

#131

Post by johnisgood »

lynndotpy wrote: post #56
doug_durham wrote: post #49

Why is "written in Rust" a feature to be mentioned? Who cares? So my type checker has memory protection and is compiled. I'm not running my type checker on an embedded system or in a mission critical service. It seems kind of like "written in Erlang". I'd prefer to have non-performance critical code for Python written in Python. That way the broader community can support and extend it.

Have you used Rust before? As a user, the speed and safety is nice. But as a developer, Rust projects are easier to hack on and contribute to. That's kind of the whole appeal of Astral. I know Python better than Rust, but it's a lot easier for me to hack on Rust projects. The whole appeal of Astral is that they want to bring Rust-quality tooling to Python.

> Rust projects are easier to hack on and contribute to.

You can say that about any languages that you yourself know, or other people know. There are beautiful codebases in many other languages, and awful ones in the same languages.

If your Rust codebase has a lot of unwraps and lifetime annotations (among other things), I will probably not find it a joy to contribute to it, at all.

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

#132

Post by johnisgood »

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.

Yeah, and static typing is not limited to Rust, and there are many other programming languages that do not have any of that venvs / pip nonsense.

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

#133

Post by johnisgood »

lynndotpy wrote: post #105
rafram wrote: post #96

Earlier quoted context omitted.

Rust has very arcane syntax and a lot of rules that developers coming from interpreted / garbage-collected languages (like the ones using these tools) would have a hard time grasping. It’s easy for people who are already familiar with it, but isn’t that always the case?

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.

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

#135

Post by dontlaugh »

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…

IntelliJ sadly has slow UI, including bizarrely high typing latency. That is unrelated to analysis it does, which is acceptable to be slow.

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

#136

Post by lynndotpy »

johnisgood wrote: post #131
lynndotpy wrote: post #56

Earlier quoted context omitted.

Have you used Rust before? As a user, the speed and safety is nice. But as a developer, Rust projects are easier to hack on and contribute to. That's kind of the whole appeal of Astral. I know Python better than Rust, but it's a lot easier for me to hack on Rust projects. The whole appeal of Astral is that they want to bring Rust-quality tooling to Python.

> Rust projects are easier to hack on and contribute to. You can say that about any languages that you yourself know, or other people know. There are beautiful codebases in many other languages, and awful ones in the same languages. If your Rust codebase has a lot of unwraps and lifetime annotations (among other things), I will probably not find it a joy to contribute to it, at all.

> You can say that about any languages that you yourself know, or other people know.

No, I'm saying that Rust was easier to hack on and contribute to (on my own) when I had never written any Rust before. Rust (and almost Go) is the only language I can confidently say this about. It's not even in my top 5 strongest languages now, but I still stand by this.

E.g. Look at the build instructions for Gimp and all its prerequisites: https://developer.gimp.org/core/setup/build/

Very normal C++ project, ~500 words of instructions. Once I started thinking about using a chroot to fix dependency issues after I'd already built bebl and gegl, I gave up, because I ran out of free time. It didn't matter how much C++ I knew.

Rust projects, comparatively, almost never demand that. It's almost always just `cargo build`, with some rare exceptions (e.g. The one exception I know of for which this is not true for is Graphite, which is a web app and also uses npm. )

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

#137

Post by lynndotpy »

johnisgood wrote: post #132
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.

Yeah, and static typing is not limited to Rust, and there are many other programming languages that do not have any of that venvs / pip nonsense.

What languages? I'm asking this earnestly, because there are dozens of languages I can name but I have not used. Every language I've used (except maybe Julia) asks you also to install and use something extra, like "meson" or "ninja" or "maven" or "cmake", for its build phase.

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

#138

Post by johnisgood »

lynndotpy wrote: post #137
johnisgood wrote: post #132

Earlier quoted context omitted.

Yeah, and static typing is not limited to Rust, and there are many other programming languages that do not have any of that venvs / pip nonsense.

What languages? I'm asking this earnestly, because there are dozens of languages I can name but I have not used. Every language I've used (except maybe Julia) asks you also to install and use something extra, like "meson" or "ninja" or "maven" or "cmake", for its build phase.

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.

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

#139

Post by johnisgood »

lynndotpy wrote: post #136
johnisgood wrote: post #131

Earlier quoted context omitted.

> Rust projects are easier to hack on and contribute to. You can say that about any languages that you yourself know, or other people know. There are beautiful codebases in many other languages, and awful ones in the same languages. If your Rust codebase has a lot of unwraps and lifetime annotations (among other things), I will probably not find it a joy to contribute to it, at all.

> You can say that about any languages that you yourself know, or other people know. No, I'm saying that Rust was easier to hack on and contribute to (on my own) when I had never written any Rust before. Rust (and almost Go) is the only language I can confidently say this about. It's not even in my top 5 strongest languages now, but I still stand by this. E.g. Look at the build instructions for Gimp and all its prere…

I do not know about Rust (because of all these lifetime and borrow checking stuff), but Go is definitely one of the languages one can easily contribute to without knowing much about the language, especially if you use VSCode with its Go extension.

I do not like C++ projects, they are behemoths, slow to compile, and C++ continues getting so much bullshit bolted on top of the language. It is extremely complicated, at least for me.

Most of my projects - regardless of language - has extremely simple build instructions, no matter how large it is.

As for GIMP, "meson" and "ninja" is not too bad, I have come across projects with much worse build instructions, but I agree, it is leaning towards "complicated".

> Once I started thinking about using a chroot to fix dependency issues after I'd already built bebl and gegl

Been there, done that. I remember compiling GCC myself, it was not as straightforward as, say, LLVM + clang. I think the issue is not with the language itself, however, but the developers who do not simplify the build process.

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

#140

Post by [deleted] »

90s_dev wrote: post #52
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…

JSX is my favorite thing to come out of Facebook (also the only good thing).

[deleted]
Post reply on HN