Pyrefly: A new type checker and IDE experience for Python

Original Article ↗ Hacker News Discussion ↗

Meta affiliation and ethics

  • Some refuse to use anything associated with Meta, regardless of technical merit, citing distrust of the company.
  • Others argue this is misapplied “guilt by association” for infra tools: it’s open source developer tooling, not a consumer product, and likely not influenced by executives.
  • There’s pushback that Meta still controls the repo, branding, and feedback channels, so boycotting remains a valid stance for some.

Why another type checker vs contributing to existing ones

  • Several question why Meta didn’t just contribute to uv/ruff/ty or mypy/pyright instead of launching a new checker.
  • Suspicions include NIH and copyright control; others say Pyrefly and ty were developed independently and announced around PyCon timing.
  • Analogies to Poetry vs uv and TypeScript vs Flow: sometimes you need a new project to make big design bets, even if goals overlap.
  • A minority explicitly prefers Meta-backed tooling for perceived long-term maintenance and “proven at massive scale,” while others cite Astral’s tools as counterexamples to “only bigcos can build good tooling.”

Technical positioning vs existing tools

  • Pyrefly joins mypy, pyright, and ty as another (Rust-based) static type checker implementing Python typing PEPs.
  • Commenters note that even with the same specs, tools differ in strictness, inference, and conformance; ambiguity in evolving PEPs is a major driver.
  • Performance is a key theme: Meta staff claim Pyrefly is ~10x faster than Pyre on the Instagram codebase; others note pyright and ty are already dramatically faster than mypy.
  • There’s concern that newer fast checkers may not handle highly dynamic frameworks (e.g., Django’s runtime-generated attributes). Some say this is why they’re stuck on mypy + plugins; others argue speed doesn’t inherently require dropping support and expect framework-specific plugins or special-casing over time.

Rust implementation and ecosystem effects

  • “Written in Rust” is debated: some see it as hype or irrelevant; others treat it as a useful proxy for speed, safety, and simpler single-command builds (cargo build).
  • LSP/type-checker performance is framed as “performance-critical” for IDE responsiveness and CI/pre-commit usage; Python-based tools like pylint and mypy are criticized as too slow on large codebases.
  • There’s broader meta-discussion about dynamic vs static typing in Python, the complexity of typing a historically dynamic ecosystem, and whether the effort suggests people “should just use a better statically-typed language.”
  • Some worry about the growing N-language problem around Python (Python + C + Rust); alternatives like Mojo are mentioned but acknowledged as immature and tied to a different ecosystem.

IDE / UX and early experiences

  • The article’s VS Code framing disappoints users who prefer PyCharm or “real IDEs”; others emphasize Pyrefly is an LSP and can integrate with any editor, with docs for Vim/Neovim.
  • An early user reports Pyrefly flagging a global assignment that CPython allows, suggesting stricter or buggy behavior; maintainers point to its alpha status and request bug reports.

Organizational and adoption dynamics

  • Some predict a Flow/Atom pattern: an internal tool overshadowed by popular external alternatives (e.g., ty), potentially threatening the internal team’s mandate.
  • Others note Meta’s history of wanting control over its infra tools, and claim Pyrefly is being launched with more explicit focus on open source and community than previous efforts.