Comment by doug_durham a day ago
Why 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.
> 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.
> 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? Don't worry about it
Static typing is a big one, but I've been so steeped in Python that I don't appreciate it as much as maybe I should.
The big thing for me is that most Rust projects are statically(ish) compiled (like go) and only need a `cargo build`. No venvs or pip commands or node/npm/nvm or make, etc.
Also, the Zen of Python is supposed to be one obvious way to do something but ddg "python dependency manager" and have a good laugh. That actually becomes triple lol for when uv steps in and says "uh, your pip requirements.txt is unsatisifyable, what are you even?!"
And let me just say what an absolutely stellar job the rustc authors have done with the error messages. Just out of this world thoughtful. I have not yet gotten on board with their compile time vs safety and insight tradeoff, but I can see why they chose those two axes
Yeah, and static typing is not limited to Rust, and there are many other programming languages that do not have any of that venvs / pip nonsense.
Type inference is handy, but as an observation source code is 90% written for humans - I believe that CPython knows what types they are, that's how TypeError even exists, but seeing "def doit(erthang):" doesn't help me in the slightest. Often PyCharm can figure it out, because bless their hearts, but then developers whine about "wwwaaa, pycharm too slo grug use ed" and then one gets AttributeError in production because who could have foreseen
regex.match takes strings and returns a match object. There are most likely stubs, if you are new to it and need support.
> Rust projects are easier to hack on and contribute to.
You can say that about any languages that you yourself know, or other people know. There are beautiful codebases in many other languages, and awful ones in the same languages.
If your Rust codebase has a lot of unwraps and lifetime annotations (among other things), I will probably not find it a joy to contribute to it, at all.
> You can say that about any languages that you yourself know, or other people know.
No, I'm saying that Rust was easier to hack on and contribute to (on my own) when I had never written any Rust before. Rust (and almost Go) is the only language I can confidently say this about. It's not even in my top 5 strongest languages now, but I still stand by this.
E.g. Look at the build instructions for Gimp and all its prerequisites: https://developer.gimp.org/core/setup/build/
Very normal C++ project, ~500 words of instructions. Once I started thinking about using a chroot to fix dependency issues after I'd already built bebl and gegl, I gave up, because I ran out of free time. It didn't matter how much C++ I knew.
Rust projects, comparatively, almost never demand that. It's almost always just `cargo build`, with some rare exceptions (e.g. The one exception I know of for which this is not true for is Graphite, which is a web app and also uses npm. )
I do not know about Rust (because of all these lifetime and borrow checking stuff), but Go is definitely one of the languages one can easily contribute to without knowing much about the language, especially if you use VSCode with its Go extension.
I do not like C++ projects, they are behemoths, slow to compile, and C++ continues getting so much bullshit bolted on top of the language. It is extremely complicated, at least for me.
Most of my projects - regardless of language - has extremely simple build instructions, no matter how large it is.
As for GIMP, "meson" and "ninja" is not too bad, I have come across projects with much worse build instructions, but I agree, it is leaning towards "complicated".
> Once I started thinking about using a chroot to fix dependency issues after I'd already built bebl and gegl
Been there, done that. I remember compiling GCC myself, it was not as straightforward as, say, LLVM + clang. I think the issue is not with the language itself, however, but the developers who do not simplify the build process.
Rust has very arcane syntax and a lot of rules that developers coming from interpreted / garbage-collected languages (like the ones using these tools) would have a hard time grasping. It’s easy for people who are already familiar with it, but isn’t that always the case?
It makes no sense to me. You found it easier to contribute to Rust projects because... Rust projects are significantly easier to build? What? You can just do "dune build" in OCaml, or run "make" for many C projects. Plus, it is also significantly slower to build Rust projects, you should have probably added that.
An LSP is performance-critical code. It directly affects responsiveness of your IDE, or even the viable scope of a project that the LSP can handle.
Rust is both CPU- and memory-efficient, quite unlike Python. (It could have been OCaml / Reason, or Haskell, they are both reasonably fast and efficient, and very convenient to write stuff like typecheckers in. But the circle of possible contributors would be much narrower.)
The circle of possible contributors doesn't really matter. It's a Meta project, they have others written in OCaml and to this day they manage to have contributors eg https://github.com/facebook/flow because they hire and pay them.
>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.
I feel like the likelihood that a project will say what language it is written in is much higher if that language is Rust. I like Rust but I do find this trend a little annoying. (Even though I acknowledge that "written in Rust" probably means the tool is relatively new, not buggy, and easy to use.)
> I'd prefer to have non-performance critical code for Python written in Python
A type checker is performance critical code. You can watch how Pylint, just a linter, written in Python, lints your source code line by line. It's so slow it can take 30 seconds to update the linting after you change some lines.
Many of these make the mistake of running against an entire codebase instead of checking vcs first and only running against changed files.
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.