111–120 of 433 posts
I am curious, what is the reason behind introducing Rust in Git? I am not familiar with Git development, I am just a user. But my impression is that it is already a complete tool that won't require much new code to be written. Fixes and improvements here and there, sure, but that does not seem like a good reason to start using a new language. In contrast, I understand why adding it to e.g. Linux development makes sen…
C is unsafe.
Given that rust only works on e.g. cygwin recently (and still does not build many crates: i try to compile jujutsu and failed), this is a big blow to portability IMHO. While I try to like rust, I think making it mandatory for builds of essential tools like git is really too early.
Earlier quoted context omitted.
> There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. That's fine. The only impact is that they won't be able to use the latest and greatest release of Git. Once those platforms work on their support for Rust they will be able to jump back to the latest and greatest.
It's sad to see people be so nonchalant about potentially killing off smaller platforms like this. As more barriers to entry are added, competition is going to decrease, and the software ecosystem is going to keep getting worse. First you need a lib C, now you need lib C and Rust, ... But no doubt it's a great way for the big companies funding Rust development to undermine smaller players...
> Introducing Rust is impossible for some platforms and hard for others. Please could someone elaborate on this.
There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/
Earlier quoted context omitted.
There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/
Shouldn't these platforms work on getting Rust to support it rather than have our tools limited by what they can consume? https://github.com/Rust-GCC/gccrs
It seems unwise, to me, to tie the life of a project as fundamental, and conceptually simple, as git to a compiler and runtime as complicated as rust. The beauty of the unsafety of C is partially that it's pretty easy to spin up a compiler on a new platform. The same cannot be said of Rust.
Do you think any new, Git-relevant platform is going to gain C compiler support via anything other than Clang/LLVM?
I prefer to ask another question: "Is this useful". Would it be useful, if we were to spin up a different platform in the future, to be able to do so without LLVM. I think the answer to that is a resounding yes.
That doesn't leave rust stranded. A _useful_ path for rust to pursue would be to defined a minimal subset of the compiler that you'd need to implement to compile all valid programs. The type checker, borrow checker, unused variable tracker, and all other safety features should be optional extensions to a core of a minimal portable compiler. This way, the rust compiler could feasibly be as simple as the simplest C compiler while still supporting all the complicated validation on platforms with deep support.
Earlier quoted context omitted.
There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/
At this point maybe it's time to let them solve the problem they've created for themselves by insisting on a closed C compiler in 2025.
Ideally upstream git would become better as a library as part of being rewritten in Rust.
Maybe I'm just old and moany, and I need to step aside for bigger and better things such as Rust. But. Now rather than needing to understand just C to work on Git/kernel, you now need to also know Rust. The toolchain complexity is increasing, and the mix of these languages increases the barrier to entry. I'm highly invested into Git, having learned the tooling and having a significant number of projects constructed w…
AFAIK git already uses multiple languages, github says its 50% C, 38% shell, 4% perl, then 4% TCL python 1% So "another language" here probably does not weigh as much, especially considering perl/TCL are the weirder one there. But for big projects like linux and git, this could actually be a consolidation step: you spent decades growing, hacking things on top of each other. You have mostly figured out what this proje…
It's to a "test balloon" if you have a plan to mandate it and will be announcing that. Unless I suppose enough backlash will cause you to cancel the plan .
It's literally a test of how people will react, so yes, finding out if people will react negatively would be exactly the point of doing the test in the first place. Would you prefer that they don't publicize what their follow-up plans would be to try to make it harder to criticize the plans? If you're against the plan, I'm pretty sure that's the exact type of feedback they're looking for, so it would make more sense…
> How dare you! I’m going to boycott git!!
Self-identified as irrelevant (objector will not be using git); no reply necessary, expect a permaban.
> I don’t want to install language X to build and run git.
Most users do not build git from source. Since no case is made why this is relevant beyond personal preference, it will likely be ignored.
> Adopting language X might inhibit community participation.
This argument has almost certainly already been considered. Without a specific reason beyond the possibility, such unsupported objections will not lead to new considerations, especially if raised by someone who is not a regular contributor.
> Language X isn’t fully-featured on platform Y.
Response will depend on whether the Git project decides to support platform Y or not, whether the missing features are likely to affect Git uses, etc. Since no case is provided about platform Y’s usage, it’ll be up to the Git team to investigate (or not) before deciding
> Language X will prevent Git from being deployed on platform Z, which affects W installations based on telemetry and recent package downloads, due to incompatibility Y.
This would be guaranteed to be evaluated, but the outcome could be anywhere from “X will be dropped” to “Y will be patched” to “Z will not be supported”.