Earlier quoted context omitted.
These talented engineers could take their skills elsewhere. That's the message.
And make so much less money
Money isn't everything. We only invented capitalism a few centuries ago.
Pyrefly: A new type checker and IDE experience for Python
141–150 of 177 posts
Re: Pyrefly: A new type checker and IDE experience for Python
#142Why is "written in Rust" a feature to be mentioned? Who cares? So my type checker has memory protection and is compiled. I'm not running my type checker on an embedded system or in a mission critical service. It seems kind of like "written in Erlang". I'd prefer to have non-performance critical code for Python written in Python. That way the broader community can support and extend it.
Have you used Rust before? As a user, the speed and safety is nice. But as a developer, Rust projects are easier to hack on and contribute to. That's kind of the whole appeal of Astral. I know Python better than Rust, but it's a lot easier for me to hack on Rust projects. The whole appeal of Astral is that they want to bring Rust-quality tooling to Python.
> Rust projects are easier to hack on and contribute to.
This was actually the subject of a study at the University of Waterloo:
> We find that despite concerns about ease of use, first-time contributors to Rust projects are about 70 times less likely to introduce vulnerabilities than first-time contributors to C++ projects.
Re: Pyrefly: A new type checker and IDE experience for Python
#143I lost all interest when I saw VS Code. I don’t get why people consider this a suitable IDE for python when you can have a real IDE like PyCharm.
What can you do in PyCharm that you cannot do in VS Code? I recently switched from PyCharm to VS Code to maintain a project with 250k LoC in Python (Django) and VS Code has been like a breath of fresh air. While you may need to install some plugins to get it "just right", it's more extensible. PyCharm is more "batteries included", and maybe that's the rub here.
Re: Pyrefly: A new type checker and IDE experience for Python
#144Earlier quoted context omitted.
What languages? I'm asking this earnestly, because there are dozens of languages I can name but I have not used. Every language I've used (except maybe Julia) asks you also to install and use something extra, like "meson" or "ninja" or "maven" or "cmake", for its build phase.
You want languages that can be compiled similarly to "cargo build"? Well, Go is one of them. Many C projects are just one "make" command away. OCaml has "dune build". Odin has "odin build", too. There are a lot of other languages I am missing here though.
Oh yeah, right about Go. Odin and OCaml are languages I don't use but have heard their names.
I'm not saying Rust has exclusivity here, I'm only explaining why I like to know a project was written in Rust.
Re: Pyrefly: A new type checker and IDE experience for Python
#145Why is "written in Rust" a feature to be mentioned? Who cares? So my type checker has memory protection and is compiled. I'm not running my type checker on an embedded system or in a mission critical service. It seems kind of like "written in Erlang". I'd prefer to have non-performance critical code for Python written in Python. That way the broader community can support and extend it.
>Why is "written in Rust" a feature to be mentioned? Who cares?
A lot of people. Correct or not, I think "written in rust" have become synonymous with "very much faster than the alrernatives" in the pyrhon community.
Re: Pyrefly: A new type checker and IDE experience for Python
#146Earlier quoted context omitted.
Have you used Rust before? As a user, the speed and safety is nice. But as a developer, Rust projects are easier to hack on and contribute to. That's kind of the whole appeal of Astral. I know Python better than Rust, but it's a lot easier for me to hack on Rust projects. The whole appeal of Astral is that they want to bring Rust-quality tooling to Python.
> but it's a lot easier for me to hack on Rust projects That static typing is nice, I wonder if it's going to catch on one day. The amount of energy spent trying to bend dynamically types languages into being real ones is just comical. Even the standard library is barely typed, so they give no fucks https://github.com/python/cpython/blob/v3.13.3/Lib/re/__init... What does it accept? Who knows. What does it return? Do…
Real ones?
Re: Pyrefly: A new type checker and IDE experience for Python
#147This is very cool but why wouldn’t they just contribute to uv and ruff and ty https://github.com/astral-sh/ty
I just ran ty and it can't resolve any imports whereas pyrefly passes. Why would that be? I hate Python so much.
> I hate Python so much.
Look I get that it's frustrating, but the tool you're whinging about is literally pre-alpha.
Re: Pyrefly: A new type checker and IDE experience for Python
#148How close to a statically-typed language does such addition make Python ?
Re: Pyrefly: A new type checker and IDE experience for Python
#149Earlier quoted context omitted.
pyrefly is not tied to vscode? Also please try to be more considerate of people preferences, and pycharm is not strictly better. Remote dev on vscode is very convenient for me, should I go on the Internet saying that pycharm is trash? No
I’m not saying VS Code is trash but I think it’s closer to a text editor than an IDE. I even use it for some things non python but I remain curious to the fact why people use it for python. It might not be tied to VS Code but the title clearly says “New […] IDE experience for…” which is why I commented. I had hoped to see something for PyCharm or even a new IDE.
Thats what you think, other people think something else.
Re: Pyrefly: A new type checker and IDE experience for Python
#150Earlier quoted context omitted.
The only inherent feature of JSX is compile time "parsing" whereas tagged literals inherently require runtime string parsing. But yeah other than that you're right. I'm just talking about first-class VS Code support. Which to me means a lot.
Of course tagged string literals can be compiled down to a form where no string parsing occurs. This is a really old technique; I implemented it, like many others, in PHP in late 1990s. Vut inside an IDE or an LSP, tagged literal strings need quite a bit more special support than JSX, AFAICT.
Do you mean at runtime but only once at startup, like parsing a Lua program into bytecode? Or do you mean at true compile time like Zig and Rust format strings?