Git: Introduce Rust and Announce It Will Become Mandatory in the Build System
Posted4 months agoActive4 months ago
lore.kernel.orgTechstoryHigh profile
heatednegative
Debate
85/100
GitRustSoftware Development
Key topics
Git
Rust
Software Development
The Git development team proposes introducing Rust into the build system, sparking controversy and debate among developers about the implications for portability, complexity, and the project's future direction.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
104
0-6h
Avg / period
14.5
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Sep 20, 2025 at 8:17 AM EDT
4 months ago
Step 01 - 02First comment
Sep 20, 2025 at 9:34 AM EDT
1h after posting
Step 02 - 03Peak activity
104 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 23, 2025 at 9:04 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45312696Type: storyLast synced: 11/20/2025, 8:14:16 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Please could someone elaborate on this.
This might make a much more interesting case for GOT than before https://www.gameoftrees.org/
they could just port the multiprocess pledge stuff to git (and benefit linux too with namespaces)
then all the userfacing changes (i.e. work on git bare instrad of wc) I've been doing for the last decade with a couple lines on my gitconfig file.
GCC simply supports more platforms.
RESF members tend to say it the other way around as in the platform doesn't support rust, but the reality is that it's the compiler that needs to support a platform, not the other way around.
Actually, I'm surprised HPE doesn't already ship a Rust fork, given how NonStop is supposed to be a "reliable" OS...
[1] https://doc.rust-lang.org/beta/rustc/platform-support.html
Anyone know of anything on that list with more than a thousand SWE-coded users? Presumably there's at least one or two for those in the know?
Platform support needs to be maintained. There is no way around that. Any change in the codebase has the possibility of introducing subtle platform-specific bugs. When platform support means that some teenager a decade ago got it to compile during the summer holiday and upstreamed her patches, that's not worth a lot. Proper platform support means having people actively contributing to the codebase, regularly running test suites, and making sure that the project stays functional on that platform.
On top of this, it's important to remember that platform support isn't free either. Those platform-specific patches and workarounds can and will hold back development for all the other platforms. And if a platform doesn't have a maintainer willing to contribute to keeping those up-to-date, it probably also doesn't have a developer who's doing the basic testing and bug fixing, so its support is broken anyways.
In the end, is it really such a big deal to scrap support for something which is already broken and unlikely to ever be fixed? At a certain point you're just lying to yourself about the platform being supported - isn't it better to accept reality and formally deprecate it?
In theory I agree with you, and code written in a platform-agnostic way is definitely something we should strive for, but in practice: can keeping broken code around really be called "good engineering culture"?
https://doc.rust-lang.org/beta/rustc/platform-support.html#t...
Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/
But, I wasn't arguing against noting changes in a changelog, I'm arguing against putting portability to abstruse platforms before quality.
But even then Git doesn’t mind losing some plateformes when they want to move forward on something.
I don’t maintain any tools as popular as git or you’d know me by name, but darned if I’m going to put in more than about 2 minutes per year supporting non-Unix.
(This said as someone who was once paid to improve Ansible’s AIX support for an employer. Life’s too short to do that nonsense for free.)
To me it looks like big corps enjoying the idea of having free service so they can avoid maintaining their own stuff, and trying the "too big to fail" fiddle on open source maintainers, with little effect.
Oh no, if only these massive companies that print money could do something as unthinkable as pay for a support contract!
It's not like older versions of git won't work perfectly fine. Git has great backwards compatibility. And if there is a break, seems like a good opportunity for them to fork and fix the break.
And lets be perfectly clear. These are very often systems built on top of a mountain of open source software. These companies will even have custom patched tools like gcc that they aren't willing to upstream because some manager decided they couldn't just give away the code they paid an engineer to write. I may feel bad for the situation it puts the engineers in, I feel absolutely no remorse for the companies because their greed put them in these situations in the first place.
Seriously, I guess they just have to live without git if they're not willing to take on support for its tool chain. Nobody cares about NonStop but the very small number of people who use it... who are, by the way, very well capable of paying for it.
If that is due to the build environment deviating from the standard, then I agree with you. However, when its due to the codebase deviating from the standard, then why blame the build environment developers for expecting codebases to adhere to standards. That's the whole point of standards.
According to git docs they seem to try to make a best effort to stick to POSIX but without any strong guarantees, which this change seems to be entirely in line with: https://github.com/git/git/blob/master/Documentation/CodingG...
If your codebase used to conform to a standard and the build environment relies on that standard, and now the your codebase doesn't anymore, then its not the build environment that deviates from the standard, its the codebase that brakes it.
Because they don’t. For instance, if they were fully POSIX compliant, they’d probably already have LLVM.
It's probably not straightforward but the users of NonStop hardware have a lot of money so I'm sure they could find a way.
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.
But no doubt it's a great way for the big companies funding Rust development to undermine smaller players...
In any case HPE may have 60k employees but they're still working to create a smaller platform.
It actually demonstrates the point I was making. If a company with 60k employees can't keep up then what chance do startups and smaller companies have?
They build on open source infrastructure like LLVM, which a smaller company will probably be doing anyway.
Your comment is needlessly dramatic. The only hypothetical impact this has is that whoever uses these platforms won't have upgrades until they do something about it, and the latest and greatest releases will only run if the companies behind these platforms invests in their maintenance.
This is not a good enough reason to prevent the whole world from benefiting from better tooling. This is not a lowest common denominator thing. Those platforms went out of their way to lag in interpretability, and this is the natural consequence of these decisions.
> I like programming
> I program to make money
If you belong to the second category - I’m going to be super charitable, it sounds like I’m not going to be charitable and I am, so keep reading - such as by being paid by a giant bank to make applications on Nonstop, there might be some policy that’s like
“You have to vet all open source code that runs on the computer.”
So in order to have Rust, on Nonstop, to build git, which this guy likes, he’d need to port llvm, which isn’t impossible. What’s impossible is to get llvm code reviewed by legal, or whatever, which they’re not going to do, they’re going to say “No. No llvm. HP who makes Nonstop can do it, and it can be their legal problem.”
I’m not saying it’s impossible. The other guy is saying it’s impossible, and I’m trying to show how, in a Rube Goldberg way, it looks impossible to him.
You and I like programming, and I’m sure we’re both gainfully employed, though probably not making as much money at guy, but he doesn’t like programming. You are allowed to mock someone’s sincerity if they’re part of a system that’s sort of nakedly about making lots of money. But if you just like programming, you’d never work for a bank, it’s really fucking boring, so basically nobody who likes programming would ever say porting Rust or whatever is impossible. Do you see?
It’s tough because, the Jane Street people and the Two Sigma people, they’re literally kids, they’re nice people, and they haven’t been there for very long, they still like programming! They feel like they need to mook for the bank, when they could just say that living in New York and having cocktails every night is fun and sincere. So this forum has the same problem as the mailing list, where it sounds like it’s about one thing - being able to use fucking hashmaps in git - and it’s really about another - bankers. Everywhere they turn, the bankers run into people who make their lifestyle possible, whether it’s the git developers who volunteer their time or the parents of the baristas at the bars they’re going to paying the baristas’ rent - and the bankers keep hating on these people. And then they go and say, well everyone is the problem but me. They don’t get it yet.
Linux systems: Any library is system library because otherwise there will be no real OS libraries or API.
Rust: No ABI. = No (real) shared libraries.
Debian: https://www.debian.org/releases/trixie/release-notes/issues....
Me who wrote long, long comment and then accidentally pushed close tab shortcut. !!@@!
I would recommend building some packages containing rust, especially on older hardware - and then realize that because of static linking you will need to rebuild it very very often - and don't forget that you are building clean. Because it is expected that you will use required shared libraries to make life easier.
I think that rust people should maybe sometimes just consider - that rust if pushed in such way will be more hated than C.
Maybe you should not try to deflect criticism about stable ABI and shared libraries - linux OSes REQUIRE IT - nobody will change OS architecture because you want it. And maybe we should be more conservative architecturally in especially most critical pieces of software architecture.
Also you are incorrect - because you are already making wrong assumption:
> crates are not libraries
"never provided a shared library interface" - it doesn't need to, it just need to USE library - distros will convert static one to shared one if that what is reasonable.
Now we have to have C library connected by C headers to (in future) rust application. Sure this somehow works - at cost of memory safety. So someone WILL suggest using rust crate instead of C library, and the problem will inevitably pop up.
You could only say it works correctly as platform stipulates if you did not use any rust crate, or used ones that only your app/lib uses, or trivial finished ones - and I do not see people use rust like that. Even then it is from most linux distributions perspective the distribution job to decide if it should be static or shared linked NOT app-developer.
SSL is something that is prime example of would it best to be written in memory safe language, with safe headers, provided that language makes stable ABI connections, so we can update 0-day not waiting for app developer.
Rust fails spectacularly at last point unless library uses C headers.
But at least it seems that OpenSSL is dynamically loaded after start so they are not changing that too soon.
When I decide to patch some library for my use case I may want to use such library in every instance in every program on the system. Rust crate makes this impossible - now I need to rebuild everything even if I could not reasonably touch ABI boundary in same C code.
Ultimately I think many of linux rust critics see it correctly as company-first/app-centered/containerized/not developement-aware user language (i.e user who can patch software for their specific needs who actively want to inspect every dependency in ONE way), and they prefer the known pro-community/pro-distro/pro-user-developer C/C++ paradigm instead. (At least fact that many criticism start immediately when GPL project get BSD rust rewrite does point it to free-software/open-source i.e pro-community/pro-company schism)
Many linux users especially developement-aware users just have enough of pip, cargo and every 'modern' stuff - they just want old good apt or pacman.
Then you have people that think slow development and no revolutionary changes should be IT priority in modern times.
Then you have people that do believe that any alternative should be better, easier and simpler than old stuff before it should be treated as even a alternative way.
And then you have contrarians.
Sounds like it will be mandatory to use Rust to build all of Git. The title implies Rust itself will be mandatory.
I was confused in the same way after reading the submission title. Mandating Rust would be a far more radical change.
Edit: nope, I’m wrong. On reading the link, they’re setting up the build infrastructure to support Rust in the Git code itself.
Looking at the comment thread, at least one person I recognize as a core maintainer seems to be acting as if this is an official plan that they've already agreed on the outline of, if not the exact timing. And they seem to acknowledge that this breaks some of the more obscure platforms out there.
rustc_codegen_gcc is close to becoming stable, and conversely the Linux kernel is dropping more esoteric architectures. Once the supported sets of architectures fully overlap, and once the Linux kernel no longer needs unstable (nightly-only) Rust features, it'd be more reasonable for Linux to depend on Rust for more than just optional drivers.
However, adapting the conventions and mechanisms of a large complex C system like the Linux kernel to Rust is taking time.
In a brief search, they’re engineering manager for GitLab, appear to be a frequent contributor of high-difficulty patches to Git in general, and are listed as a possible mentor for new contributors.
Given the recent summit, it seems likely that this plan was discussed there; I hadn’t dug into that possibility further but you could if desired.
> 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”.
I disagree. Perhaps these roguelike examples will clarify.
You can Raise Concerns towards the project. The project is mired in your concerns! The project loses 5 HP extricating itself from the muck! The project moves forward. --more--
This indicates that the project considered the concern raised and chose not to halt work over it; those 5 HP who might be impacted should continue planning for that impact. Most likely, in Git's case, that's either 'the good of the project outweighed the impact to the few' and/or 'no one is willing to commit developer/maintainer hours to us for that platform so we're bailing on it'. I haven't uncovered any evidence that they tend to lie about project motivations, and certainly I would not classify the project founder as 'uncomfortable sharing unpalatable views', so I have no evidence supporting the accusation that the Git project might refuse to consider a supported claim that has not already been evaluated.
You cast Unsupported Claims towards the project. The project's shield reflects them! You take 5 HP of Reasoning damage! The project moves forward. --more--
A politely-phrased objection is meaningless if it isn't backed by reasoning that can be considered and either accepted or rejected by a project. People do try, but disappointingly, human beings are sometimes vulnerable to politeness attacks of this sort. I can assert with near-perfect certainty that Git is not vulnerable to polite but unsupported objections.
You cast Hostile Tirade towards the project. The project casts Protection from Hostility! Your tirade has no effect. You blink away! --more--
Everyone is looking to ignore this kind of criticism. The roguelike joke makes it especially clear that the criticism was not considered solely due to how it was presented, rather than by whatever merits it may have. Doesn't matter how substantive the claims, being mean typically guarantees both disregard and eviction from the chosen battlefield.
ps. Note that in some cases, the project will abandon the requested outcome. Human beings have a certain percentage chance of sacrificing personal gain to 'reward' hostility with an outcome that is maximally undesirable to those being hostile. This can result in ending support for platforms that might otherwise have remained support, or even outright shutdown of an entire project. See also: Fez 2, libxslt, et al.
pps. None of these outcomes guarantee that they will change course, even if a perfectly-supported and politely-presented argument is made and considered. None of these outcomes guarantee that one will receive a considered rejection rather than a blind rejection, either. There is no Konami code, but one thing is certain: one cannot win an boss fight by throwing the controller at the TV.
What's there to test? It was obvious that the reaction would be overwhelmingly negative, so that's definitely not something they would care about. What else?
While I love rust, I can't imaging being both sane and positive about that change.
(
) am myself. Love rust. Hate rust rewrites.While we are on Hacker News, this is still an enormously obtuse way to communicate.
Are you saying that as users of git we will be negatively affected by deps being added and build times going up? Do you have evidence of that from past projects adding rust?
Why not just say that??
We will see!
Clear enough for you? It is a note to myself, and for others who care. You might not care, I do, and some other people do, too.
This program is still dynamically linked:
Not sure, why it needs all these dependencies, this is C Hello World: And I think the C binary is already bloated.To stress it again: The Rust Hello World program is 2.5-times larger then the whole Git executable with functionality of 20 years!
This also makes it easier to refactor and add features without risk of breaking things.
The borrow checker also encourages ownership structures that are less error-prone.
Finally the more modern tooling makes it easier to write tests.
If you're thinking "where is the peer reviewed study that proves this?" then there isn't one, because it's virtually impossible to prove even simple things like that comments are useful. I doubt there's even a study showing that e.g. it's easier to write Python than assembly (although that one probably isn't too hard to prove).
That doesn't mean you get to dismiss everything you disagree with simply because it hasn't been scientifically proven.
The things I'm talking about have been noted many times by many people.
However what you're doing is to reply with the same platitudes and generalities that all rust aficionados seem to have ready on demand. Sure, rust is better at those things, but I don't see how that would make a rewrite of an existing feature better by default. I don't doubt that new features of git that would be written in rust will be safer and more ergonomic, but for existing code to be rewritten, which is what I understand to be your stance, I remain skeptical.
This is an extremely strong statement. And factually incorrect.
But we probably won't see any effect for 10 years or so.
Btw 10 lines of code per day is a typical velocity for full time work, given it's volunteers 1 line per day might not be as crazy as you think.
https://www.debian.org/releases/trixie/release-notes/issues....
Now, Rust in Git and Linux probably won't head in these directions, so Debian might actually be able to support these two in particular, but the general attitude of Rustacians toward libraries is really off-putting to me.
I need you to fill out this TPS report. Unfortunately it's mandatorty to fudge section 15A.
From my (very limited) perspective, I just kind of thought git had settled in to 2.x and there wasn't any reason to break compatibility.
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.
[1] https://bellard.org/tcc/
[2] https://github.com/TinyCC/tinycc
But like, so does 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.
mrustc is a bootstrap Rust compiler that doesn't implement a borrow checker but can compile valid programs, so it's similar to to your proposed subset. Rust minus verification is still a very large and complex language though, just like C++ is large and complex.
A core language that's as simple to implement as C would have to be very different and many people (I suspect most) would like it less than the Rust that exists.
In my opinion, the verification of the implementation should be separate from the task of translating that implementation to bytecode. This leaves you with a simple compiler that is easy to implement but still with a strong verifier that is harder to implement, but optional.
That's a very unkind assumption of my argument.
I ask that you read https://news.ycombinator.com/item?id=45314707 to hopefully better understand my actual argument. It doesn't involve calling anybody stupid or lazy.
253 more comments available on Hacker News