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 :)
There is no such thing as an end user. Those folks who are on a smartphone playing a video game or watching youtube? And absolutely paying using a convenient digital payment method.
They are not us
Lets pray they die out quickly.
Python is a pile of interconnected packages, very rarely do they get woven into an end user facing app.
Instead we are interacting with packages. If the package doesn't work: the maintainer is gone, refuses ur request, or doesn't respond in a timely manner, the onus to fix the mess is on us.
I have not looked at the source for 80-90% of the python packages I've used. if a tool is well-maintained, I don't care about its language if implementation. while I agree with the caveats you suddenly introduced in your last sentence, none of them apply to any of the tools you initially mentioned (uv, ruff, pyright) so I think you're actually arguing two different things and don't want to be convinced otherwise.