Git: Introduce Rust and announce it will become mandatory in the build system

https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im/

by WhyNotHugo • 10 months ago

335 399 10 months ago

lore.kernel.org

politelemon• 10 months ago

Introducing Rust is impossible for some platforms and hard for others.

Please could someone elaborate on this.

ahdanggit2• 10 months ago

Rust doesn't support as many CPU architectures as C does (SH4 for example, though there's likely many more better examples.)

This might make a much more interesting case for GOT than before https://www.gameoftrees.org/

1oooqooq• 10 months ago

got is a waste of time, imo.

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.

DarkNova6• 10 months ago

My understanding: As Rust is built on LLVM and not GCC, it is also limited to operating systems supporting LLVM.

GCC simply supports more platforms.

JoshTriplett4• 10 months ago

Rust has a GCC backend as well, rustc_codegen_gcc. However, the NonStop platform just has a proprietary C compiler.

arccy• 10 months ago

because the rust compiler just doesn't support some platforms (os / architecture combination)?

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.

JoshTriplett4• 10 months ago

Rust can't support a platform when that platform's vendors just provide a proprietary C compiler and nothing else (no LLVM, no GCC). Perhaps someone could reverse-engineer it, but ultimately a platform with zero support from any FOSS toolchain is unlikely to get Rust support anytime soon.

whalee2• 10 months ago

See this page [1], particularly the 'Tier 3' platforms.

[1] https://doc.rust-lang.org/beta/rustc/platform-support.html

Alifatisk• 10 months ago

More precise link

https://doc.rust-lang.org/beta/rustc/platform-support.html#t...

bbor• 10 months ago

Thanks for the specifics, really fascinating list! I'm sure I'm being a bit flippant, but it's pretty funny that a list including the Playstation 1, N64, and Apple Watches is in the same conversation as systems that need to compile git from source.

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?

jmillikin• 10 months ago

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/

MangoToupe2• 10 months ago

How is this git's concern?

antihero• 10 months ago

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

Hizonner• 10 months ago

Sucks to be that platform?

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.

formerly_proven• 10 months ago

Nonstop is still supported? :o

maximilianburke2• 10 months ago

Maybe they can resurrect the C backend for LLVM and run that through their proprietary compilers?

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.

ksynwa• 10 months ago

Won't someome think of the financial sector

saghm7• 10 months ago

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.

motorest4• 10 months ago

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.

pxc• 10 months ago

Why should free software projects bend over backwards to support obscure proprietary platforms? Sounds absurd to me

jrpelkonen• 10 months ago

I am curious, does anyone know what is the use case that mandates the use of git on NonStop? Do people actually commit code from this platform? Seems wild.

doctorpangloss• 10 months ago

You’re chasing after the meaning of “impossible.” Easy. There’s two categories of developers:

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.

eklavya• 10 months ago

What are you on about?

daurentius5232• 10 months ago

To put in simply.

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.

comex• 10 months ago

Not especially relevant for Git which has never provided a shared library interface.

justinhj• 10 months ago

"Announce that Git 3.0 will make Rust a mandatory part of our build infrastructure."

Sounds like it will be mandatory to use Rust to build all of Git. The title implies Rust itself will be mandatory.

binary1322• 10 months ago

how is that not the same thing?

StopDisinfo9103• 10 months ago

One phrasing implies contributions will have to be in Rust, the other doesn’t.

I was confused in the same way after reading the submission title. Mandating Rust would be a far more radical change.

wongarsu• 10 months ago

You could read "Rust will become mandatory" as "all contributors will need to be able to code Rust" or even "all new code has to be written in Rust" or similar variations

kstrauser9• 10 months ago

My last company used Jenkins, so our build infrastructure depended on Java. We used zero code outside of supporting Jenkins. So Java was required to build our stuff, but not to write or run it.

Edit: nope, I’m wrong. On reading the link, they’re setting up the build infrastructure to support Rust in the Git code itself.

ziml772• 10 months ago

Does anyone with insight into Git development know if we should care about this? Is this just a proposal out of nowhere from some rando or is this an idea that a good portion of Git contributors have wanted?

ekidd2• 10 months ago

For whatever it might be worth...

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.

ziml772• 10 months ago

Interesting! I'd certainly say that's worth something. Definitely didn't expect it though given how poorly some people have reacted to Rust being introduced as an optional part of the Linux kernel.

altairprime7• 10 months ago

You can perhaps learn more about their involvement in the community from this year’s summit panel interview: https://youtu.be/vKsOFHNSb4Q

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.

phkahler• 10 months ago

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.

saghm7• 10 months ago

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 to tell them that directly if it actually affects you rather than making a passive-aggressive comment they'll likely never read on an unrelated forum.

altairprime7• 10 months ago

If they’re running the project with a Linus-type approach, they won’t consider backlash to be interesting or relevant, unless it is accompanied by specific statements of impact. Generic examples for any language to explain why:

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”.

egorfine6• 10 months ago

It's literally a test of how people will react

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?

egorfine6• 10 months ago

They did expect backlash, so I believe no amount will cause them to cancel. Rust fanboys() thrive off backlash.

() am myself. Love rust. Hate rust rewrites.

monkeyelite7• 10 months ago

How does this help me as a user of git?

cschep2• 10 months ago

My guess is that we (I am also a user of git) won't even notice.

johnisgood10• 10 months ago

I will leave this here for the future:

  $ ldd /usr/bin/git
          linux-vdso.so.1 (0x00007f69c2d64000)
          libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f69c2c81000)
          libz.so.1 => /usr/lib/libz.so.1 (0x00007f69c2c67000)
          libc.so.6 => /usr/lib/libc.so.6 (0x00007f69c2616000)
          /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f69c2d66000)
  $ ls -alh /usr/bin/git
  -rwxr-xr-x 1 root root 4.0M Aug 25 11:40 /usr/bin/git

I did not measure but it does not take long on my old hardware to compile git from scratch either, for now.

jaas• 10 months ago

Rust is generally a much better tool for building software than C. When your software is built with better tools, you will most likely get better software (at least eventually / long term, sometimes a transition period can be temporarily worse or at least not better).

monkeyelite7• 10 months ago

That would be a stronger argument if people were facing implementation deficiencies in git

johnisgood10• 10 months ago

You missed "IMO". We get it, you love Rust and/or hate C, and if so, I wonder why. Try Ada + SPARK though if you really want REAL safety. Its track record speaks for itself.

egorfine6• 10 months ago

Rust is generally a much better tool for building software than C.

This is an extremely strong statement. And factually incorrect.

IshKebab13• 10 months ago

In future it might be more reliable and faster, maybe with more features.

But we probably won't see any effect for 10 years or so.

tankenmate2• 10 months ago

Except there are far less Rust developers than C developers, so contributions will start to drop as Rust usage expands in git.

veber-alex2• 10 months ago

10 years? are they going to contribute 1 line of a code a day or something?

alexchamberlain• 10 months ago

The developers of git will continue to be motivated to contribute to it. (This isn’t specific to Rust, but rather the technical choices of OSS probably aren’t generally putting the user at the top of the priority list.)

veber-alex2• 10 months ago

I am pretty sure that developers motivated to contribute code benefits end users plenty.

uecker8• 10 months ago

By not getting timely security updates:

https://www.debian.org/releases/trixie/release-notes/issues....

MarsIronPI3• 10 months ago

And the reason this is a problem is because of the me-first attitude of language developers these days. It feels like every language nowadays feels the need to implement its own package manager. These package managers then encourage pinning dependencies, which encourages library authors to be a less careful about API stability (though obviously this varies from library to library) and makes it hard on distro maintainers to make all the packages work together. It also encourages program authors to use more libraries, as we see in the Javascript world with NPM, but also in the Rust world.

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.

Mikhail_K• 10 months ago

It doesn't, it hurts you by limiting the number of platforms Git is available on.

pipsterwo• 10 months ago

If it works on mac & linux I've got nothing to worry about

gitaarik• 10 months ago

That git development will be modern, secure and fast?

syngrog66• 10 months ago

mandatorty: best new word of 2025

maxbond• 10 months ago

mandatorty (adj.): Simultaneously required and a civil offense.

I need you to fill out this TPS report. Unfortunately it's mandatorty to fudge section 15A.

jmull• 10 months ago

I'm wondering what's on the horizon with git 3.0?

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.

turkishdelight• 10 months ago

SHA-256 will become the default hash.

stebalien• 10 months ago

See https://git-scm.com/docs/BreakingChanges#_git_3_0

delusional4• 10 months ago

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.

loeg4• 10 months ago

Do you think any new, Git-relevant platform is going to gain C compiler support via anything other than Clang/LLVM?

bArray4• 10 months ago

In theory you should be able to use TCC to build git currently [1] [2]. If you have a lightweight system or you're building something experimental, it's a lot easier to get TCC up and running over GCC. I note that it supports arm, arm64, i386, riscv64 and x86_64.

[1] https://bellard.org/tcc/

[2] https://github.com/TinyCC/tinycc

delusional4• 10 months ago

The nature considering the future is that our actions _now_ affect the answer _then_. If we tie our foundational tools to LLVM, then it's very unlikely a new platform can exists without support for it. If we don't tie ourselves to it, then it's more likely we can exist without it. It's not a matter of if LLVM will be supported. We ensure that by making it impossible not to be the case. It's a self fulfilling prophecy.

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.

171862744026• 10 months ago

Code doesn't need to "gain C compiler support", that's the point of having a language standard.

kstrauser9• 10 months ago

One argument from the git devs is that it’s very hard to implement smarter algorithms in C, though. For example, it uses arrays in places where a higher level language would use a hash, because the C version of that is harder to write, maintain, and debug. It’s also much easier to write correct threaded code in Rust than C. Between those 2 alone, using a more robust language could make it straightforward to add performance gains that benefit everyone.

delusional4• 10 months ago

That's a one time gain though. There's no reason for every platform to check the validity of some hash table implementation when that implementation is identical on all of them.

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.

fuhsnn2• 10 months ago

As a practical example, the latest Git version can be compiled by an extremely simple (8K lines of C) C compiler[1] without modification and pass the entire test suite. Gonna miss the ability to make this claim.

[1] https://github.com/fuhsnn/widcc

addcn• 10 months ago

Feel like there’s a ton of interesting things ahead for SCM — want to see more of those proposals.

For example…had to build my own tool to extend git blame and track the AI generated code in our repository and save prompts:

https://github.com/acunniffe/git-ai

bArray4• 10 months ago

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 within it. I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git.

GrayShade• 10 months ago

I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git.

And they will keep working because the repository format isn't affected by the language git is written in.

account427• 10 months ago

Believing that this will be the case forever is naive. At some point there will be extensions. Then those extensions will become all but mandatory for interacting with other git users.

IshKebab13• 10 months ago

I'm just old and moany, and I need to step aside for bigger and better things such as Rust.

You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry.

In any case Rust is usually easier than C (excluding buggy C which is very easy to write), and certainly easier than actually learning the Git or Linux codebases.

hedgehog5• 10 months ago

I think it is often under appreciated by people who haven't worked in security how hard high quality C is in practice.

toast0• 10 months ago

You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry.

It's viable, but limiting. Sometimes you have to do things you don't want to, which is why it's called work. But if you can choose what platforms you work on, you can orient towards things where things change less, and then you don't need to learn new things as often.

Chances are, if you get into the weeds in a lot of C programs, Rust is in your future, but it's viable to not want that, and to moan about it while doing it when you need to.

ajsnigrutin• 10 months ago

It's not "having to learn something new", but "having to be good at two things, both of which are full languages with their own specifics, problems and ways to solve them, two sets of compilers and some duct tape to hold them together.

It's like putting steak on a pizza... pizza is good, steak is good, pizza on a steak might be good too, but to actually do that in production, you now need two prep stations and you can't mess up either one.

hoppp5• 10 months ago

Technical debt is real tho and the rust-c interop is not the best ever.

Why not rewrite the entire git in rust and have two compatible versions?

matheusmoreira2• 10 months ago

I've also sent some patches git's way and I can't say I'm thrilled about being forced to (finally) learn Rust if I want to contribute again in the future. I guess I'm outdated...

saghm7• 10 months ago

They're proposing porting over one small piece that has no dependencies and exposing it to the rest of git via a C interface. Yes, they'll presumably port more over in the future if it goes well, but it's a gross exaggeration to characterize this as somehow making it impossible to contribute without knowing Rust.

IshKebab13• 10 months ago

I feel the same way about C code though. I don't think C gets the right to be the one true programming language that everyone must know forever.

Luker88• 10 months ago

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 project is and where it is going, it's time to think about safety, performance and remove old hacks.

Rust feels like a good fit, imho.

bArray4• 10 months ago

I did check this out. The shell, perl and python are likely for scripting and not used during runtime. TCL is likely some form of dynamic scripting.

I think we also have to be honest about what the project here is too, it's not to have both C and Rust together, but to replace all C with Rust. In which case, it probably makes sense to just clone to repo and work on a fork like they did with SSH.

fuhsnn2• 10 months ago

Perl, TCL and Python are all written in C, as well as many shells, so despite their interdependency the total complexity can be satisfied with a C11 compiler.

motorest4• 10 months ago

Now rather than needing to understand just C to work on Git/kernel, you now need to also know Rust.

I'm yet to know a single software engineer who isn't well versed on multiple programming languages. This is not a problem.

lucasoshiro• 10 months ago

Agreed. And if someone is interested in contributing to the Linux kernel, a new programming language is far from the hardest thing that they need to learn...

oreally5• 10 months ago

Except now these software engineers have to code switch between languages.

Could you software engineers stop making things harder for yourselves and playing this meaningless flex of a status game, and you know, focus on something tangible, meaningful, instead of adding more bureaucracy?

Borg34• 10 months ago

Im on the same boat :) But no worries. You can always build and use older git without rust. Of course, it will work for a while until those kids will change the proto for the "better". And being old and grumpy also means, you can slowly care less and less about all that moot :)

Kids: now downvote it into oblivion :) Like I give a shit...

171862744026• 10 months ago

These things often get presented as an age thing, but I think they aren't. It's very weird, I'm young but I feel like having the same stance in a lot of topics, in politics, but also here. I don't know how to deal with this. You guys have it easy (/s), you don't have to live with this for long, but I feel like I'm growing up into an increasingly hostile environment.

jdiaz97• 10 months ago

Removing Perl and adding Rust instead is probably reducing complexity rather than increasing it.

thayne• 10 months ago

Look at it from the other angle, there are many developers (myself included), especially younger developers who would much prefer developing rust to c, and for at least some of them, don't want to learn how to write c (including how to avoid undefined behavior).

I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git.

How does the git project using rust inhibit your ability to do any of that?

gedy• 10 months ago

Maybe rewrite or create a new SCM called `grit`, etc

OCTAGRAM• 10 months ago

Will they introduce Ada and announce that it will become mandatory

johnisgood10• 10 months ago

Only if safety really is their concern... so no.

riedel4• 10 months ago

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.

GoblinSlayer3• 10 months ago

Git works only on cygwin too?

Kwpolska• 10 months ago

No, it doesn't. OP meant that the Rust support on Cygwin is bad; it is better with the native Windows API.

lame_lexem• 10 months ago

jj has msvc builds and is still tire 1 target maybe something particular about your configuration?

riedel4• 10 months ago

I want it to be cygwin native, i.e. passing calls through the cygwin posix layer and not use the windows binary. Sure I can use the windows binary, but that is a different thing.

sunshowers9• 10 months ago

?? I build Jujutsu and many other Rust programs from source on Windows.

Rust has a much better Windows story than C and bash do, due to its heritage as a language built by Mozilla for Firefox.

riedel4• 10 months ago

As said before I wasn't complaining about windows, but rather of not so common posix layers like cygwin [0]. Most C posix compliant stuff compiles in my experience.

[0] https://github.com/rust-lang/rust/issues/137819

egorfine6• 10 months ago

Rust has a much better Windows story than C

This is an extremely strong statement. Which is so obviously factually incorrect that I tend to think you might have meant something else.

secondcoming• 10 months ago

what's a 'test balloon'?

petiepooo• 10 months ago

A viral commit

oreally5• 10 months ago

Ironically it's original use was in political* parlance.

From wiki it's "information sent out to the media in order to observe the reaction of an audience. It is used by companies sending out press releases to judge customer reaction, and by politicians who deliberately leak information on a policy change."

Yup I have no doubt that there's a Rust 'evangelist' group somewhere aiming for inorganic growth of the language.

metaltyphoon2• 10 months ago

Yup I have no doubt that there's a Rust 'evangelist' group somewhere aiming for inorganic growth of the language.

So anything using Rust now must be the ‘evangelists’ work right?

sebtron3• 10 months ago

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 sense, since new drivers will always need to be written.

Can anyone explain what I might be missing?

jcrben3• 10 months ago

C is unsafe.

sebtron3• 10 months ago

I honestly can't tell if this is meant as serious reply to my question (in that case: let's say I agree that Rust is 100% better than C; my question still stands) or as a way to mock Rust people's eagerness to rewrite everything in Rust (in that case: are you sure this is the reason behind this? They are not rewriting Git from scratch...)

conradev2• 10 months ago

Changing well-tested code is unsafe.

gre• 10 months ago

https://github.com/Speykious/cve-rs

altairprime7• 10 months ago

https://lore.kernel.org/git/ZZ9K1CVBKdij4tG0@tapette.crustyt... has a couple dozen replies and would be a useful place to start reading about it; beyond that, search that list for Rust. (Note, I’m only responding the opening question, not evaluating the arguments pro/con here or on the list; in any case, someone else surely will.)

striking3• 10 months ago

Git is constantly gaining features, even if for the most part it seems like the core functionality is unchanged.

If you'd like to review the changelog, the Git repo has RelNotes but I've found GitHub's blog's Git category to be a more digestible resource on the matter: https://github.blog/open-source/git/

mhh__• 10 months ago

git feels complete until you use a tool like jj or git-branchless (latter of which has things like in-memory merges in rust)

eYrKEC2• 10 months ago

Or if you use its predecessor, bitkeeper.

feelamee3• 10 months ago

can you elaborate please? Why jj is more feature complete for you than git? I tried jj and for now it looks like too raw. The problem is also its git backed. I really don't want to care about two states of repo at the same time - one is my local jj, and another is remote git repo.

I think jj just has other conceptions compared to git. E.g. in git you probably will not change history too much (if pushed to remote especially), while in jj simple editing of commits is a front feature. So, comparing them in feature completeness looks strange to me

After some experience with jj I understand that jj is a user-oriented, user friendly tool with batteries included, while git is double-edged knife which is also highly customizable

bsder• 10 months ago

I am curious, what is the reason behind introducing Rust in Git?

More developers. Old C projects simply don't have enough incoming developers anymore.

No one is clamoring to join the Git project and write C code.

The Rewrite It In Rust(tm) brigade, on the other hand, will be happy, for now, to join and spread the gospel of Rust.

dangus• 10 months ago

I'm not even a Rust or C developer and know this take is BS, Rust pretty clearly has major maintainability and code reliability/safety/stability benefits over C.

monkeyelite7• 10 months ago

To capture existing status for Rust promoters.

surajrmal• 10 months ago

Developers who work on git think it will help them do their jobs better. Do you need any more reasons beyond that? They don't need to justify it to users necessarily.

bitwize3• 10 months ago

There's also the fact that if you want to recruit systems programmers for a project like git, the 19-year-old catgirls who are likely to be interested in that sort of work all work in Rust. Ask one to hack a legacy C code base and she might nyao at you angrily >:3

bitwize3• 10 months ago

The whole point of Rust is that C, and all the code written therein (or as much as is feasible), be eventually replaced and abandoned. The potential costs of continuing to use C, and all the memory and concurrency bugs that come with it, runs in the billions worldwide if not more.

Besides which, in 2025 all the real ones are using jj, which is 100% Rust, not git—so if git wishes to remain competitive it needs to catch up.

AlexeyBelov2• 10 months ago

I don't know even one developer who uses Jujutsu.

Ericson2314• 10 months ago

Curious what this means for libgit2.

Ideally upstream git would become better as a library as part of being rewritten in Rust.

saltcured3• 10 months ago

Is this a bit of chickens coming home to roost as far as developer culture forgetting how to work with cross-compiling toolchains? When I started my career, it was common understanding that the developer may be manipulating sourcecode on a different system and/or platform than where it will be executed.

Our source control, editing, compilation, and execution was understood to happen in different computational spaces, with possible copy/staging steps in between. You were doing something very naive if you assumed you could execute the built program on the same system where the sourcecode files existed and the editor/IDE was running.

This was a significant fraction of the build rules we used to manage. E.g. configuration steps had to understand that the target platform being measured/characterized is not the same as the platform executing the build tools. And to actually execute a built object may require remote file copies and remote program invocation.

bloppe• 10 months ago

Actually, the Rust toolchain makes cross-compiling way easier than any other fully-compiled language I've ever used. There are like 100 different platforms you can target by just setting the `--target` flag, and they all pretty much just work on any host platform.

Sounds like the real issue is that some Git developers have ancient, rigid requirements for their own development machines.

cogman102• 10 months ago

A good example of it is how easy it is to do WASM from rust. WASM is even one of the harder platforms to target with rust.

saltcured3• 10 months ago

Others have said Rust does not support NonStop.

But, my point is you shouldn't even have to cross-compile Git to a platform like NonStop in order to develop NonStop apps. So the portability of Rust shouldn't even matter here. The app developer should be able to run their Git commands on a supported platform and cross-compile their own app to NonStop.

pdpi• 10 months ago

Actually, the Rust toolchain makes cross-compiling way easier than any other fully-compiled language I've ever used

Zig takes the crown on that one, to the point that some people use Zig to cross-compile Go projects with CGo dependencies.

dabinat3• 10 months ago

That has not been my experience. I develop on Windows and need to compile for Linux. After spending several hours trying to get cross-compilation working, I gave up and do it via WSL now.

I switched from Go and I feel like Go was much better at this than Rust.

(I tried “cross” but it was very slow and I found it faster to rsync the files inside the container and then run the build scripts)

rcxdude2• 10 months ago

I suspect the majority of developers never even learnt as such. Cross-compilation is almost always a second-class citizen and I never expect it to work correctly on an external project. Linux distros have given up, with fedora even insisting on running compilation on the real target hardware for platforms like the raspberry pi, which is kind of insane, and as a result basically no-one puts in the effort to make it work.

forrestthewoods2• 10 months ago

Is this a bit of chickens coming home to roost as far as developer culture forgetting how to work with cross-compiling toolchains?

I don't understand your comment. Completely ignorning Rust the modern state of cross-compilation is an unmitigated disaster.

Linux is especially bad because glibc is badly architected pile of garbage stuck in the 80s. It should be trivially possible to target any minimum glibc version for any possible Linux hardware environment. But glibc and Linux distros don't even attempt to make this possible. Linux toolchains make it nearly impossible to not use the default system libraries which is the opposite of correct for cross-compiling.

Zig moves mountains to make cross-compiling possible. But almost no projects actually attempt to support cross-compile.

saltcured3• 10 months ago

You mostly understand my comment, but not my graybeard perspective.

The modern disaster is exactly that developer culture has forgotten how to do this for the most part.

But, you're focusing on Rust compiling when I don't think it is relevant. If those weird financial platform developers were aware of cross-compiling, they wouldn't think that a developer tool like Git has to be built to run on the target financial server platform. They would be capable of cross-compiling or otherwise staging their build into that platform while still using Git on a supported workstation platform to manage the sources.

taminka• 10 months ago

bruh what is that goofy ass capcha protection??

AnyTimeTraveler• 10 months ago

That's Anubis. A proof-of-work based protection against AI-Crawlers.

https://github.com/TecharoHQ/anubis

nayak• 10 months ago

This series was in response to another thread [1] which wanted to make rust mandatory in an upcoming release.

The authors proposal was to instead take the middle ground and use rust as an optional dependency until a later point of time where it becomes mandatory.

The later point of time was decided based on when rust support lands in gcc, which would make things smoother, since platforms which support gcc would also be included.

[1] https://lore.kernel.org/git/pull.1980.git.git.1752784344.git...

djha-skin3• 10 months ago

The GCC compiler collection has been hit and miss though. Nobody uses gcj for example. I sort of doubt that they'll be able to implement a good compiler for a language that doesn't even have a standard without that implementation going wildly out of date in the future, just like what happened with Java.

aw162110714• 10 months ago

There's two different methods by which Rust support can be added to GCC: adding a Rust frontend to GCC and adding a GCC backend to the Rust compiler (rustc_codegen_gcc). The latter approach would not be (as?) susceptible to implementation divergence as an independent frontend.

oldsecondhand• 10 months ago

Since OpenJDK was released there isn't much point maintaining GCJ.

cozzyd3• 10 months ago

As long as binary sizes don't explode...

djha-skin3• 10 months ago

Rust suffers from the same problems that functional programming languages suffer from: deep learning curve and high complexity. The high complexity is intended to push more runtime errors back to compile time, but boy does that mean the language pays for it. Rust is a tire fire of complexity.

For these reasons I believe it is not a good idea. The kernel also sort of rejected Rust. The kernel is complex enough without adding a Haskell type system and a lisp-level macro system capable of obfuscating what code calls what code. serde code is so hard to spelunk for this reason. Contrast this with Go's Unmarshall, much easier to follow.

nixosbestos2• 10 months ago

I was going to roll my eyes at "Rust is a tire fire of complexity". Because it's not. Especially compared to C++. But then you just go on to outright lie in your second paragraph.

nixosbestos2• 10 months ago

Dear Rust haters, lying about Rust in the Linux kernel is not effective for your cause, and in fact just makes it further look like you're throwing a tantrum. Downvoting me doesn't change the fact that more and more Rust is merged into the kernel, new, serious drivers are being written in Rust. It also doesn't change Firefox, Chrome, Microsoft, the US Government and others are recommending and writing new code in Rust. It's over, qq. It's absurd.

I really wish I could find the Lobsters comment the other day from someone that broke down the incredible list of nuanced, spec-level detail you needed to know about C++ to actually use it at scale in large projects. It's laughably, absurdly complex compared to Rust in huge code bases.

righthand• 10 months ago

I actually think Rust is pretty easy to pick up for anyone that’s written Typescript and can use their linter to understand references and unwrapping a Result and catching an error.

Beyond that, Rust has pretty forgiving syntax.

No Linux did not reject Rust from the kernel.

Yoric4• 10 months ago

That's... an interesting point of view.

I personally find functional programming languages, including Rust, much clearer than C or Go, in particular because you can offload much information onto the compiler. The example of Serde feels a bit weird, because I don't think I've ever encountered issues with Serde code, while almost 100% of the times I've used Go in production, I've needed to debug through Go's Unmarshal and its... interesting implementation.

Also, last time I checked, the kernel didn't reject Rust. There was a conflict between two specific developers on the best place to store some headers, which is slightly different.

alfiedotwtf• 10 months ago

The high complexity is intended to push more runtime errors back to compile time

I would almost say that the ergonomics of allowing this is almost as important as the borrow checker!

krior• 10 months ago

Rust is a tire fire of complexity.

And C isn't?

cxcl• 10 months ago

It really isn't. C is very simple.

dabinat3• 10 months ago

C is simple. Good, fast, secure C is complex.

Rust has a higher initial learning curve than C. But the gap between bare-minimum Rust and fast and secure Rust is much smaller than with C.

ochronus• 10 months ago

Yes, but :) Rust isn't complex because it has functional traits, but rather because of its other design choices. Complex, nonetheless, but, I'd also say, looks "scarier" from the outside. I recently gave in and learned it, and it's much easier to handle than I thought before.

djha-skin3• 10 months ago

The title is a bit of a misnomer. Rust will become mandatory in the build system, not mandatory for future patches.

dang• 10 months ago

Thanks! I've added that to the title above. If it's somehow inaccurate, we can change it again.

gbnbv• 10 months ago

What does that mean? Is it mandatory for building the build system or also for building the application?

heavyset_go• 10 months ago

If you want to build the project, you will need a Rust compiler in your toolchain.

drnick1• 10 months ago

What's the point of trying to introduce Rust everywhere? Git is a mature piece of software and I doubt a lot of new code needs to be written. Also, Rust is very complex relative to C. If you really need classes, templates, etc, you can stick to C++ 98 and get something that is still clean and understandable relative to recent C++ standards and Rust.

Too• 10 months ago

I doubt a lot of new code needs to be written

I bet someone could have easily said the same thing a year ago or even 5 years ago. It's easy to forget the progress and there are a lot of things happening under the hood that are not obvious to casual users. Just take a look at the git log of the git repository itself. It has a steady rate of close to 100 commits per week for the past year.

That says nothing of potential new features either. There is so much more to unlock in the VCS space, look at new tools like jj for example. Additionally, security landscape is getting more aggressive every day, keeping up with and being proactive against vulnerabilities will be needed more than today.

umanwizard• 10 months ago

Rust has neither classes nor templates.

mimd• 10 months ago

I suggest waiting till the gcc side matures, with the minimum of a working gcc frontend for a non optional dependency. Optional dependencies with gcc_codegen might be okay. Git is pretty core to a lot of projects, and this change is risky, it's on a fairly short time frame to make it a core dep (6 months?).

nicoburns7• 10 months ago

See also: https://github.com/GitoxideLabs/gitoxide which is a full rewrite of git in Rust.

johnisgood10• 10 months ago

So, I have been complaining about how Rust projects have over hundreds and often thousands of dependencies. I gave this random Rust project a try.

The results:

  Building [                           ] 5/338: libc(build), proc-macro2(build)

No thank you.

Can you Rust people stop doing this? Hundreds of dependencies is the norm in Rust culture. I swear humans will never learn.

nicoburns7• 10 months ago

You can't really count "dependencies" in the Rust ecosystem by counting the number of crates. Gix itself has 65 crates but if you depended on it that would only really be one dependency.

Your average Rust project will have more dependencies than your average C project, but it's not as dramatic as you might think.

leoh• 10 months ago

Would anyone know how to view the patch in question (as opposed to the `--stat`-like view in the thread) without pulling down source or Googling around?

hoppp5• 10 months ago

So they are adding technical debt to everything? Its either in the form of C code that will need to be rewritten in rust

Or rust code that the C devs now will need to learn to understand the entire system

Doesn't matter which way you look at it

Git: Introduce Rust and announce it will become mandatory in the build system

Related Stories