Live data from Hacker News

Pyrefly: Python type checker and language server in Rust

pyrefly.org

81–90 of 150 posts

Re: Pyrefly: Python type checker and language server in Rust

#81
post #76

Earlier quoted context omitted.

> Hmm. Presumably mypy and pyrefly use the same ones, but then I don't understand why pyrefly is complaining and mypy isn't: > …where is it even puling "tuple[Any]" from… Perhaps it's a bug in pyrefly, perhaps mypy or pyrefly is able to infer something about the types that the other isn't. I would strongly suggest checking their issues page, and if not seeing a report already report it yourself. While there is an ong…

> it does not actually cover what rules you can check or infer from type hints Indeed this is the cause of maybe 30% of the warnings I'm seeing… items being added to lists or dicts in some place (or something else making it infer a container type), and pyrefly then refusing other types getting added elsewhere. The most "egregious" one I saw was: def something(x: list[str]) -> str: foo = [] for i in x: foo.append(i) r…

I assume in your example if you update the foo declaration to the following it solves the complaint:

    foo: list[str] = []
If so this a type checking design choice:

  * What can I infer from an empty collection declaration?
  * What do I allow further down the code to update inferences further up the code?
I don't know Pyrefly's philosophy here, but I assume it's guided by opinionated coding guidelines inside Meta, not what is perhaps the easiest for users to understand.

Re: Pyrefly: Python type checker and language server in Rust

#82
post #23

Earlier quoted context omitted.

Interestingly besides typescript, javascript in 2025 is still super fragmeneted but by a bunch of well-polished tools that all do approximately the same thing. esbuild/vite(rollup)/trubopack(swc), prettier/biome/oxc, npm/bun/pnpm/yarn, bun/node/deno/worker-runtimes

The fact that you even didn't mention webpack, once a champion, is especially sad.

Doesn't Next.js still use webpack?

Re: Pyrefly: Python type checker and language server in Rust

#83
post #23

Python is starting to feel a bit like JavaScript circa 2014. Remember grunt, gulp, webpack, coffeescript, babel? Now we've got pyright, mypy, pyrefly, black, ruff, ty, flake8, poetry, uv... I used to find this kind of tooling explosion exhausting (and back then with JS it truly was), but generally speaking it's a good sign that the community is hungry to push things forward. Choice is good, as long as we keep the Uni…

Interestingly besides typescript, javascript in 2025 is still super fragmeneted but by a bunch of well-polished tools that all do approximately the same thing. esbuild/vite(rollup)/trubopack(swc), prettier/biome/oxc, npm/bun/pnpm/yarn, bun/node/deno/worker-runtimes

It's just people refusing to use new tools. Prettier is so much slower than any Rust formatter, it's painful. `yarn install` takes forever. Why not switch to Bun? It's 5 minutes.

Re: Pyrefly: Python type checker and language server in Rust

#84
post #23

Earlier quoted context omitted.

Interestingly besides typescript, javascript in 2025 is still super fragmeneted but by a bunch of well-polished tools that all do approximately the same thing. esbuild/vite(rollup)/trubopack(swc), prettier/biome/oxc, npm/bun/pnpm/yarn, bun/node/deno/worker-runtimes

It's just people refusing to use new tools. Prettier is so much slower than any Rust formatter, it's painful. `yarn install` takes forever. Why not switch to Bun? It's 5 minutes.

I interviewed at one company a few months ago and they said they don't use TypeScript because the compiler gets in their way, jesus chirst.

Re: Pyrefly: Python type checker and language server in Rust

#85
post #23

Python is starting to feel a bit like JavaScript circa 2014. Remember grunt, gulp, webpack, coffeescript, babel? Now we've got pyright, mypy, pyrefly, black, ruff, ty, flake8, poetry, uv... I used to find this kind of tooling explosion exhausting (and back then with JS it truly was), but generally speaking it's a good sign that the community is hungry to push things forward. Choice is good, as long as we keep the Uni…

Interestingly besides typescript, javascript in 2025 is still super fragmeneted but by a bunch of well-polished tools that all do approximately the same thing. esbuild/vite(rollup)/trubopack(swc), prettier/biome/oxc, npm/bun/pnpm/yarn, bun/node/deno/worker-runtimes

For me it is easy, Spring/Quarkus/ASP.NET, if it has to be a JavaScript framework, Next.js the way Vercel intended.

Anything whatever the FE team feels like using, and the less I know about it, the better.

Re: Pyrefly: Python type checker and language server in Rust

#86
post #5

Earlier quoted context omitted.

It's written in Typescript, which is a super weird choice.

Wasn’t pyright made specifically for VSCode? That would explain TS.

Yes, but why they did not write it in a compiled language? Pyright is pretty slow in large code bases and takes a lot of RAM. Javascript can be faster than python in some cases, but Python is so easily extendable with C,C++, Cython, Rust. They could use Python with one of the compiled language.

Re: Pyrefly: Python type checker and language server in Rust

#87

Python is starting to feel a bit like JavaScript circa 2014. Remember grunt, gulp, webpack, coffeescript, babel? Now we've got pyright, mypy, pyrefly, black, ruff, ty, flake8, poetry, uv... I used to find this kind of tooling explosion exhausting (and back then with JS it truly was), but generally speaking it's a good sign that the community is hungry to push things forward. Choice is good, as long as we keep the Uni…

"There can be only one" - just need to wait till the deathmatches are over.

Re: Pyrefly: Python type checker and language server in Rust

#88

I much prefer the rigidity of pyrefly. It enforces a standard expectation across the code base, which will lead to less surprises IMO.

The weird Literal promotion makes pyrefly unusable for me, except if I'd avoid Literal types: https://github.com/facebook/pyrefly/issues/742

Re: Pyrefly: Python type checker and language server in Rust

#89
post #66

Earlier quoted context omitted.

If ruff & uv have proved anything, it's that a tool that's effortless, a net-positive and fast will get adopted. New typecheckers don't need to be perfect. They need to be good enough, easy to integrate and have low false positives. Sure, they will improve with time, but if feels like a pain then no one will pick it up. Python users are famously averse to tools that slow down their dev cycles, even if it means better…

If typechecking is tongue on cheek, why even bother?

Because "all or nothing" is a bad idea.

Re: Pyrefly: Python type checker and language server in Rust

#90
post #76

Earlier quoted context omitted.

> it does not actually cover what rules you can check or infer from type hints Indeed this is the cause of maybe 30% of the warnings I'm seeing… items being added to lists or dicts in some place (or something else making it infer a container type), and pyrefly then refusing other types getting added elsewhere. The most "egregious" one I saw was: def something(x: list[str]) -> str: foo = [] for i in x: foo.append(i) r…

I assume in your example if you update the foo declaration to the following it solves the complaint: foo: list[str] = [] If so this a type checking design choice: * What can I infer from an empty collection declaration? * What do I allow further down the code to update inferences further up the code? I don't know Pyrefly's philosophy here, but I assume it's guided by opinionated coding guidelines inside Meta, not wha…

Yes, annotating the type explicitly fixes it; but tbh I'd consider that type annotation "unnecessary/distracting code litter".

As far as their philosophy goes, it's an open issue they're working on, so their philosophy seems to agree this particular pattern should work :)

Post reply on HN