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

Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

blog.edward-li.com

Post reply on HN
Print view View original

41–50 of 166 posts

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#41

Post by Spivak »

MeetingsBrowser wrote: post #29
belmont_sup wrote: post #16

Earlier quoted context omitted.

Responding to your gradual typing anti-pattern bit: Agree that dynamic language behaviors can be extreme but it’s also easy to get into crazy type land. Putting aside a discussion of type systems, teams can always add runtime checks like pydantic to ensure your types match reality. Sorbet (Ruby typechecker) does this where it introduces a runtime checks on signatures. Similarly in ts, we have zod.

> teams can always add runtime checks like pydantic to ensure your types match reality. That's the problem with bugs though, there's always something that could have been done to avoid it =) Pydantic works great in specific places, like validating user supplied data, but runtime checks as a replacement for static type checkers are not really feasible. Every caller would need to check that the function is being called…

pydantic does have @validate_call for this use-case.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#42

Post by zem »

dcreager wrote: post #27

[ty developer here] We are happy with the attention that ty is starting to receive, but it's important to call out that both ty and pyrefly are still incomplete! (OP mentions this, but it's worth emphasizing again here.) There are definitely examples cropping up that hit features that are not yet implemented. So when you encounter something where you think what we're doing is daft, please recognize that we might have…

surfacing revealed types as `@TODO` made me laugh, but thinking about it it's actually a pretty neat touch!

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#43

Post by zem »

kuratkull wrote: post #11

> my_list = [1, 2, 3] > pyrefly, mypy, and pyright all assume that my_list.append("foo") is a typing error, even though it is technically allowed (Python collections can have multiple types of objects!) > If this is the intended behavior, ty is the only checker that implicitly allows this without requiring additional explicit typing on my_list. EDIT: I didn't intend my comment to be this sharp, I am actually rooting…

I am strongly for ty's behaviour here. working python code should not raise type errors unless the user explicitly opts in to a more static subset of the language by adding type annotations.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#44

Post by vintagedave »

What was not immediately obvious to me (but should have been) is that these are dev-time type checkers -- I think. (I think, both from from the github descriptions which focus heavily on editing, and from the article.) That's really useful because type inference is lacking, to me, in-editor. I tend to ask Copilot: 'add type annotations'.

So in complement to this can I share my favorite _run-time_ type checker? Beartype: this reads your type annotations (ie I see this is where Pyrefly and Ty come in), and enforces the types at runtime. It is blazingly fast, as in, incredibly fast. I use it for all my deployed code.

https://beartype.readthedocs.io/en/latest/

I suspect either of Pyrefly or Ty will be highly complementary with Beartype in terms of editor additions, and then runtime requirements.

The docs also have a great sense of humour.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#45

Post by genshii »

dcreager wrote: post #31
rendaw wrote: post #8

Earlier quoted context omitted.

Gradual typing means that an implicit "any" (unknown type) anywhere in your code base is not an error or even a warning. Even in critical code you thought was fully typed. Where you mistakenly introduce a type bug and due to some syntax or inference limits the type checker unexpectedly loses the plot and tells you confidently "no problems in this file!" I get where they're coming from, but the endgame was a huge issu…

> Gradual typing means that an implicit "any" (unknown type) anywhere in your code base is not an error or even a warning. Even in critical code you thought was fully typed. Where you mistakenly introduce a type bug and due to some syntax or inference limits the type checker unexpectedly loses the plot and tells you confidently "no problems in this file!" This is a good point, and one that we are taking into account…

This makes sense to me and is exactly what TypeScript does. Implicit `any`s do not raise TypeScript errors (which, by definition, is expected), but obviously that means if there is an `any`, it's potentially unsafe. To deal with this, you can turn on `noImplicitAny` or strict mode (which 99% of projects probably have enabled anyway).

Difference here that strict mode is a tsc option vs. having this kind of rule in the linter (ruff), but the end result is the same.

Anyway, that was a long winded way of saying that ty or ruff definitely needs its own version of a "strict" mode for type checking. :)

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#46

Post by maleldil »

vintagedave wrote: post #44

What was not immediately obvious to me (but should have been) is that these are dev-time type checkers -- I think. (I think, both from from the github descriptions which focus heavily on editing, and from the article.) That's really useful because type inference is lacking, to me, in-editor. I tend to ask Copilot: 'add type annotations'. So in complement to this can I share my favorite _run-time_ type checker? Bearty…

beartype is great, but I only find it useful at the edges. Runtime checks aren't needed if you have strict typing throughout the project. On a gradually-typed codebase, you can use beartype (e.g. is_bearable) to ensure the data you're ingesting has the proper type. I usually use it when I'm dealing with JSON types.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#47

Post by alfalfasprout »

kombine wrote: post #19

Are any of these already useful as LSPs for code editors such as Neovim? I run pyright in my Neovim config but I could certainly use something faster.

Not yet tbh. I would realistically expect at least a year or more before you can expect any kind of parity with eg; pyright/basedpyright. Type checkers are hard and have a long tail of functionality that must be implemented.

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#48

Post by echelon »

dcreager wrote: post #27

[ty developer here] We are happy with the attention that ty is starting to receive, but it's important to call out that both ty and pyrefly are still incomplete! (OP mentions this, but it's worth emphasizing again here.) There are definitely examples cropping up that hit features that are not yet implemented. So when you encounter something where you think what we're doing is daft, please recognize that we might have…

Totally orthogonal question, but since you're deep in that side of Rust dev -

The subject of a "scripting language for Rust" has come up a few times [1]. A language that fits nicely with the syntax of Rust, can compile right alongside rust, can natively import Rust types, but can compile/run/hot reload quickly.

Do you know of anyone in your network working on that?

And modulus the syntax piece, do you think Python could ever fill that gap?

[1] https://news.ycombinator.com/item?id=44050222

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#49

Post by suspended_state »

I am not well versed in python programming, this is just my opinion as an outsider.

For anyone interested in using these tools, I suggest reading the following:

https://www.reddit.com/r/Python/comments/10zdidm/why_type_hi...

That post should probably be taken lightly, but I think that the goal there is to understand that even with the best typing tools, you will have troubles, unless you start by establishing good practices.

For example, Django is large code base, and if you look at it, you will observe that the code is consistent in which features of python are used and how; this project passes the stricter type checking test without troubles. Likewise, Meta certainly has a very large code base (why develop a type checker otherwise?), and they must have figured out that they cannot let their programmers write code however they like; I guess their type checker is the stricter one for that reason.

Python, AFAIK, has many features, a very permissive runtime, and perhaps (not unlike C++) only some limited subset should be used at any time to ensure that the code is manageable. Unfortunately, that subset is probably different depending on who you ask, and what you aim to do.

(Interestingly, the Reddit post somehow reminded me of the hurdles Rust people have getting the Linux kernel guys to accept their practice: C has a much simpler and carefree type system, but Rust being much more strict rubs those C guys the wrong way).

Re: Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

#50

Post by mdaniel »

echelon wrote: post #48
dcreager wrote: post #27

[ty developer here] We are happy with the attention that ty is starting to receive, but it's important to call out that both ty and pyrefly are still incomplete! (OP mentions this, but it's worth emphasizing again here.) There are definitely examples cropping up that hit features that are not yet implemented. So when you encounter something where you think what we're doing is daft, please recognize that we might have…

Totally orthogonal question, but since you're deep in that side of Rust dev - The subject of a "scripting language for Rust" has come up a few times [1]. A language that fits nicely with the syntax of Rust, can compile right alongside rust, can natively import Rust types, but can compile/run/hot reload quickly. Do you know of anyone in your network working on that? And modulus the syntax piece, do you think Python co…

> And modulus the syntax piece, do you think Python could ever fill that gap?

I would never ever want a full fledged programming language to build type checking plugins, and doubly so in cases where one expects the tool to run in a read-write context

I am not saying that Skylark is the solution, but it's sandboxed mental model aligns with what I'd want for such a solution

I get the impression the wasm-adjacent libraries could also help this due to the WASI boundary already limiting what mutations it is allowed

Post reply on HN