https://xcancel.com/charliermarsh/status/1884651482009477368

We’re building a new static type checker for Python, from scratch, in Rust.

From a technical perspective, it’s probably our most ambitious project yet. We’re about 800 PRs deep!

Like Ruff and uv, there will be a significant focus on performance.

The entire system is designed to be highly incremental so that it can eventually power a language server (e.g., only re-analyze affected files on code change).

Performance is just one of many goals, though.

For example: we’re investing heavily in strong theoretical foundations and a consistent model of Python’s typing semantics.

(We’re lucky to have @carljm and @AlexWaygood on the team for many reasons, this is one of them.)

Another goal: minimizing false positives, especially on untyped code, to make it easier for projects to adopt a type checker and expand coverage gradually over time, without being swamped in bogus type errors from the start.

We haven’t publicized it to-date, but all of this work has been happening in the open, in the Ruff repository.

All driven by a uniquely great team: @carljm, @AlexWaygood, @sharkdp86, @MichaReiser, @DhruvManilawala, @ibraheemdev, @dcreager.

I’m learning so much from them.

Warning: this project is not ready for real-world user testing, and certainly not for production use (yet). The core architecture is there, but we’re still lacking support for some critical features.

Right now, I’d only recommend trying it out if you’re looking to contribute.

For now, we’re working towards an initial alpha release. When it’s ready, I’ll make sure you know :)

    • solrize@lemmy.world
      52·
      23 hours ago

      I don’t like the current landscape of python type checkers.

      I figure that Python itself is at the bottom of this. It simply wasn’t designed for static types. Mypy is still of some use but if you want a statically typed language, trying to graft a type system onto a unityped language hasn’t worked out well as far as I know. See also: the Erlang dialyzer, Typed Racket, and whatever that Clojure extension is called. Even Scala has its problems because the JVM has its own type system that isn’t that great a fit for Scala.

      Also, why Rust as the implementation language? Just for speed? It seems a shame to not use Python/PyPy.

      • esa@discuss.tchncs.de
        5·
        13 hours ago

        Astral is already a Rust shop; uv and ruff are written in Rust, and it makes sense for them to expand on what’s already considered very successful.

        Rust can enable a lot of speed and “fearless concurrency”; it also has a pretty good type system and a focus on correctness. They’d rather be correct than fast (C made the other choice, but is also from another age), but also show that that extra correctness comes with little runtime speed cost (compilation is another story).

      • Kogasa@programming.dev
        3·
        16 hours ago

        Yes, speed and the benefits of all the tooling and static analysis they’re bringing to Python. Python is great for many things but “analyzing Python” isn’t necessarily one of them.

      • Ephera@lemmy.mlEnglish
        2·
        17 hours ago

        I mean, we’ll probably disagree on this, but in my not so humble opinion, Python is very unsuited for this large of a project, whereas Rust excels at large projects. I imagine, these folks might have a similar opinion, given that they’re building this tool in the first place. 🙃

        But execution speed is also not something I’d ignore in a tool like that. I remember having to work with Pipenv and Poetry, and it was just cruel, having to wait more than a minute for it to tell you whether it can resolve dependencies for a fairly small project. And you’ll want to run a type checker a lot more often that that.