Comment by f311a
19 hours ago
Yeah, there are now 3 competitors and they all written in Rust:
- zuban
- ty (from ruff team)
- pyrefly
One year ago, we had none of them, only slow options.
19 hours ago
Yeah, there are now 3 competitors and they all written in Rust:
- zuban
- ty (from ruff team)
- pyrefly
One year ago, we had none of them, only slow options.
Speed is one of those "Quantity has a quality all its own" things. We use very fast tools in a qualitatively different way, even though all that changed was how long it takes in seconds.
It is interesting that nobody was writing these tools in C or in C++. There are obvious ergonomic reasons, but perhaps also it matters that Rust cares a lot more about types than either of those languages.
> It is interesting that nobody was writing these tools in C or in C++
This one's easier to explain. People interested in tooling for a specific language probably want to write that tooling in that language (hence pip, poetry, mypy, jedi, etc). Normally that would be the end if it, if Python wasn't 10-100x slower than a natively compiled language. And going from Python to Rust is an order of magnitude easier than going from Python to C or Python to C++, because the compiler is so good at identifying silly mistakes. Rust is just a friendlier language.
It's just very hard to write such systems in C/C++. Even all these Rust versions are segfaulting and panicking quite a lot. So many corner and edge cases that can be found in Python code, and the memory handling is also hard.
The author of Zuban started writing it back in 2020 or 2021, so it took him more than 4 years to complete it. And he is the author of Jedi, so he had prior experience already.
I get why they'd panic, but why have enough segfaults that you noticed? So, I went and read the code.
Zuban seems to have a bunch of scary "I'm not sure if this is correct" unsafe blocks, which to me would be a red flag. I mean, it's better that there's a comment expressing the doubt, but my experience is that if you're not sure whether it's correct, it's probably not correct.
2 replies →
Basedpyright is not rust but it's a fork of pyright with added features that are otherwise locked in vscode
It's written in Typescript, which is a super weird choice.
Wasn’t pyright made specifically for VSCode? That would explain TS.
2 replies →
[dead]
I'm sorry, I can't take seriously any piece of software which decided to prefix the previous version's name with "based". I'm aware this is a me problem.
Definitely this. I commend author of BPyright, but clown (?) avatar, unknown identity of maintainer, and name of the fork rub me off wrong way.
Hah. I love the name. It implies that whatever the original “pyright” was doing wasn’t keepin’ it real. This new version, it’s “based” so it must be somehow more “real” and “grounded” and “legit”.
All I know is it is much more strict about stuff than pylance was.
Also a me problem!
It's also horrible for fasle positives unless your project happens to be the exact same setup as the maintainers' - I had to turn off the actual type checking on it. I've since moved wholesale to the Ty alpha and it feels a hell of a lot smarter.
It also inherits the unfortunate attitude of Pyright that it will warn against idiomatic Python (EAFP) in favour of non-idiomatic Python (LBYL):
https://github.com/microsoft/pyright/issues/1739
https://docs.python.org/3/glossary.html#term-EAFP
https://docs.python.org/3/glossary.html#term-LBYL
7 replies →
it'll be like python package managers and js web frameworks.... a new one every quarter
uv works so well for the vast majority of scenarios that I don't really see a demand for further innovation in the Python package manager domain.
yeah we all heard that story every 3 months with all the previous package managers. until there's adoption by an overwhelming majority of projects, it isn't really settled yet.
1 reply →
it still needs to add handling for binaries (the one thing conda can do that uv can't)