Live data from Hacker News

Pyrefly: A new type checker and IDE experience for Python

engineering.fb.com

121–130 of 177 posts

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

#121

Earlier quoted context omitted.

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

> tooling/llm assisted conversion to pyrefly would've been preferable

Is this how it is now? Not the first time I hear this brainrot idea.

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

#122
post #30

Earlier quoted context omitted.

1. Maybe it's time to drop the crazy runtime generation and have something statically discoverable, or at least a way to annotate the typing statically. 2. Astral indicated already they plan to just add direct support for Django and other popular languages. 3. As people replied to similar comments on the previous threads (maybe to you?): that's not why ty is fast and why mypy is slow. It's also an easy claim to dispr…

> 1. Maybe it's time to drop the crazy runtime generation and have something statically discoverable, or at least a way to annotate the typing statically. That, and duck typing, are one of the biggest things that make Python what it is. If I have to drop all that for type checking and rewrite my code, why would I rewrite it in Python?

Not only duck types (ie structural type hierarchies) can be statically verified but they can be statically infered as well, as demonstrated for instance by ocaml since 1996.

"Here is a nickel, kid, get yourself a better programming language" :-p

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

#123
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....

JSX has a constrained interface that is a tree of objects with some properties on each. I guess you can have a lsp for lit-html but it will inherit the unconstrained nature of html, which is everything being string, and therefore useless as a programming interface.

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

#124
post #118

Earlier quoted context omitted.

Yes but the idea is that by slightly upgrading python code to mojo (which is a controlled superset of python), you get complied very high performance code. So for example if it were possible to convert mypy to mojo it could be as fast as rust but pythonic.

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

#125

The Rust code written here is so easy to follow but all these new Python tooling being written in Rust worries me, it adds yes another vector to the N-language problem. I hope Mojo can offer something here

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, things also have to behave the same when the semantics of static typing allows.

Mojo is not deeply embedded in the AI/LLM hype, there is nothing in the language that is targeted specifically for AI. The standard Library has a GPU package for general-purpose gpu programming, but that isn't AI specific.

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

#126
post #52

Earlier quoted context omitted.

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

I feel bad for that people that love JSX and don't know about lit-html yet.

> and don't know about lit-html yet.

You mean strings with custom non-standard syntax and weird rules of hooks, sorry, directives?

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

#127
I just tried pyrefly on a project that really needed it. It complained about an assignment of a new value to a global int variable within a function, even though the function contained the 'global' statement that should have made that OK, I think. I know that globals and assigning to them here and there are problematic for real good software, but I am surprised that Pyrefly is stricter than python on something that I don't see as a type- checking issue. But it did find a decent list of other problems that I haven't finished working my way through.

I had gotten so messed up trying to put together a quicky hobby-type program to create a data structure of perhaps a hundred data items in various overlapping and inter-related hierarchies, tuples, dicts, and lists akimbo, that I gave up on it about 10 days ago. I hypothecated that bondage and discipline might be the way to control the confusion, so I'm rewriting, using SQLite for the dataflow from function to function, lots of little tables and no optional fields. Can anyone opine on whether that is a sensible option?

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

#128

Earlier quoted context omitted.

Having used Python for many years, it’s the least interesting aspect of the language. Almost all such tricks can be done with compile time meta programming, often even without API changes.

I'd like to read a blog post on this subject, if anyone knows one.

I don’t know about a blog post, but I mean the obvious stuff like codegen, generics/templates or macros to achieve the same things Python does by being dynamic.

Almost no one actually uses eval/exec.

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

#130

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.

[deleted]
Post reply on HN