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.
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.
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.
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.
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/
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
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.)
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.
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
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.
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.
not changing working code to prevent issues is unsafe.
we can go in circles all day with blanket statements that are all true. but we have ample evidence that even if we think some real-world C code is safe, it is often not because humans are extremely bad at writing safe C.
sometimes it's worth preventing that more strongly, sometimes it's not, evidently they think that software that a truly gigantic amount of humans and machines use is an area where it's worth the cost.
believing that rewriting to rust will make code safe is unsafe)
Of course it will be safer, but not safe. Safety is a marketing feature of rust and no more. But a lot of people really believe in it and will be zealously trying to prove that rust is safe.
A test will never catch every bug, otherwise it's a proof, and any change has the probability to introduce a new bug, irregardless of how careful you are. Thus, changing correct code will eventually result in incorrect code.
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...)
Everyone on hackernews is well aware that C makes it relatively easy to create buffer overflows, and what buffer overflows are. You're still not responding to GP question.
I'm not involved in the initiative so I can't answer the question definitively? I provided one of the major reasons that projects get switched from C. I think it's likely to be a major part of the motivation.
Right, I never mentioned that I am a decently experienced C developer, so of course I got my fair share of buffer overflows and race conditions :)
I have also learned some Rust recently, I find a nice language and quite pleasant to work with. I understand its benefits.
But still, Git is already a mature tool (one may say "finished"). Lots of bugs have been found and fixed. And if more are found, sure it will be easier to fix them in the C code, rather than rewriting in Rust? Unless the end goal is to rewrite the whole thing in Rust piece by piece, solving hidden memory bugs along the way.
> though I'm curious whether Rust's integer overflow behavior in release builds would have definitely fared better?
Based on the descriptions it's not the integer overflows that are issues themselves, it's that the overflows can lead to later buffer overflows. Rust's default release behavior is indeed to wrap on overflow, but buffer overflow checks will remain by default, so barring the use of unsafe I don't think there would have been corresponding vulnerabilities in Rust.
This doesn't matter at all for programs like Git. Any non-free standing program running on a modern OS on modern hardware trying to access memory its not supposed to will be killed by the OS. This seams to be the more reasonable security-boundary then relying on the language implementation to just not issue code, that does illegal things.
Yeah sure, memory-safety is nice for debuggibility and being more confident in the programs correctness, but it is not more than that. It is neither security nor proven correctness.
Not quite the best example, since Git usually has unrestricted file access and network access through HTTP/SSH, any kind of RCE would be disastrous if used for data exfiltration, for instance.
If you want a better example, take distributed database software: behind DMZ, and the interesting code paths require auth.
Git already runs "foreign" code e.g. in filters. The ability to write code that reacts unexpectedly on crafted user input isn't restricted to languages providing unchecked array/pointer access.
I think bugs in the MMU hardware or the kernel accidentally configuring the MMU to allow access across processes that isn't supposed to be are quite rare.
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.
> 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.
We might also have different priorities. I do not care too much that google and apple want to lock down their smartphone spyware and sales platforms. The supply chain risks and maintenance burden imposed onto me by the Rust ecosystem are much more of an concern.
I don't know what this has to do with locking down phones, but I do appreciate not getting compromised just for cloning a repo or opening my laptop at a coffee shop.
This is not what I said, but memory safety is certainly not anything which is a high priority for my own security. I still think memory safety is important and I also think Rust is an interesting language, but... the hype is exaggerated and driven by certain industry interests.
Rust isn't popular just because of memory safety though. I think the memory safety message is maybe a little too loud.
It's also a modern language with fantastic tooling, very high quality library ecosystem and a strong type system that reduces the chance of all kinds of bugs.
It's obviously not perfect: compile time is ... ok, there aren't any mature GUI toolkits (though that's true of many languages), async Rust has way too many footguns. But it's still waaaaay better than C or C++. In a different league.
Rust is a nice language, but it pushed too aggressively with the argument of "memory safety" at all cost ignoring other considerations. And Cargo is certainly a disaster even though it may be considered "fantastic tooling" by some. In any case, I do not think it is funny that I now depend on packages without timely security update in my distribution. This makes me less secure.
I guess this depends on what you consider good tooling. I am relatively happy with C tooling. But if you want to quickly assemble something from existing libraries, then language-level package managers like npm, cargo, pip are certainly super convenient. But then, I think this convenience comes at a high cost. We now have worms again, I thought those times were long over... IMHO package management belongs into a distribution with quality control and dependencies should be minimized and carefully selected.
Fair enough. I just find it mind boggling how much money flows into completely new language ecosystems compared to improvements for C/C++ tooling which would clearly much more effective if you really cared about overall security of the free software world.
The issue with investing similar levels of effort into making C++ safer is the C++ standards committee doesn't want to adopt those kinds of improvements.
I am not interested in C++, it is also far too complex. In my opinion software needs to become simpler and not more complicated, and I fear Rust might be a step into the wrong direction.
Which is also the reason why we don't have #pragma once and many other extensions like it. Except we do. Compilers can add rust-like static analyzers without the standard committee mandating it.
Personally, I use Rust (and have been using it for close to 9 years) because I've been part of multiple teams that have delivered reliable, performant systems software in it, within a budget that would clearly be impossible in any other language. Rust acts as a step change in getting things done.
While I really really want devices I can own, I don't want to compromise security to do it. We need to do two things:
1. Lobby politicians to write laws that allow us to actually own the devices we bought.
2. Stop the FUD that a device that can be jailbroken is insecure. I heard this from our frigging CSO, of all people, and it's patently false, just FUD by Apple and Google who want you to be afraid of owning your device.
I want a device that's as secure as possible, but that I can own. I don't want to hack my own self just to get what I paid for.
It is a sad thing but I do root against secure boot initiatives because they almost entirely work to limit user's freedom instead of improving their security.
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.
> 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.
As someone with experience in this specific niche, yes they absolutely are. There are no longer ten thousand retail chains asking for COBOL-based counterpoint PoS mods on a yearly basis.
The COBOL market is basically tenured experts in existing systems or polyglots helping migrate the systems to VB or C# at this point. The market has plummeted and now it's in the final deflationary shrink before death.
Rust is over 10 years old now. It has a track record of delivering what it promises, and a very satisfied growing userbase.
OTOH static analyzers for C have been around for longer than Rust, and we're still waiting for them to disprove Rice's theorem.
AI tools so far are famous for generating low-quality code, and generating bogus vulnerability reports. They may eventually get better and end up being used to make C code secure - see DARPA's TRACTOR program.
The applicability of Rice's theorem with respect to static analysis or abstract interpretation is more complex than you implied. First, static analysis tools are largely pattern-oriented. Pattern matching is how they sidestep undecidability. These tools have their place, but they aren't trying to be the tooling you or the parent claim. Instead, they are more useful to enforce coding style. This can be used to help with secure software development practices, but only by enforcing idiomatic style.
Bounded model checkers, on the other hand, are this tooling. They don't have to disprove Rice's theorem to work. In fact, they work directly with this theorem. They transform code into state equations that are run through an SMT solver. They are looking for logic errors, use-after-free, buffer overruns, etc. But, they also fail code for unterminated execution within the constraints of the simulation. If abstract interpretation through SMT states does not complete in a certain number of steps, then this is also considered a failure. The function or subset of the program only passes if the SMT solver can't find a satisfactory state that triggers one of these issues, through any possible input or external state.
These model checkers also provide the ability for user-defined assertions, making it possible to build and verify function contracts. This allows proof engineers to tie in proofs about higher level properties of code without having to build constructive proofs of all of this code.
Rust has its own issues. For instance, its core library is unsafe, because it has to use unsafe operations to interface with the OS, or to build containers or memory management models that simply can't be described with the borrow checker. This has led to its own CVEs. To strengthen the core library, core Rust developers have started using Kani -- a bounded model checker like those available for C or other languages.
Bounded model checking works. This tooling can be used to make either C or Rust safer. It can be used to augment proofs of theorems built in a proof assistant to extend this to implementation. The overhead of model checking is about that of unit testing, once you understand how to use it.
It is significantly less expensive to teach C developers how to model check their software using CBMC than it is to teach them Rust and then have them port code to Rust. Using CBMC properly, one can get better security guarantees than using vanilla Rust. Overall, an Ada + Spark, CBMC + C, Kani + Rust strategy coupled with constructive theory and proofs regarding overall architectural guarantees will yield equivalent safety and security. I'd trust such pairings of process and tooling -- regardless of language choice -- over any LLM derived solutions.
Sure it's possible in theory, but how many C codebases actually use formal verification? I don't think I've seen a single one. Git certainly doesn't do anything like that.
I have occasionally used CBMC for isolated functions, but that must already put me in the top 0.1% of formal verification users.
It's not used more because it is unknown, not because it is difficult to use or that it is impractical.
I've written several libraries and several services now that have 100% coverage via CBMC. I'm quite experienced with C development and with secure development, and reaching this point always finds a handful of potentially exploitable errors I would have missed. The development overhead of reaching this point is about the same as the overhead of getting to 80% unit test coverage using traditional test automation.
You're describing cases in which static analyzers/model checkers give up, and can't provide a definitive answer. To me this isn't side-stepping the undecidability problem, this is hitting the problem.
C's semantics create dead-ends for non-local reasoning about programs, so you get inconclusive/best-effort results propped up by heuristics. This is of course better than nothing, and still very useful for C, but it's weak and limited compared to the guarantees that safe Rust gives.
The bar set for Rust's static analysis and checks is to detect and prevent every UB in safe Rust code. If there's a false positive, people file it as a soundness bug or a CVE. If you can make Rust's libstd crash from safe Rust code, even if it requires deliberately invalid inputs, it's still a CVE for Rust. There is no comparable expectation of having anything reliably checkable in C. You can crash stdlib by feeding it invalid inputs, and it's not a CVE, just don't do that. Static analyzers are allowed to have false negatives, and it's normal.
You can get better guarantees for C if you restrict semantics of the language, add annotations/contracts for gaps in its type system, add assertions for things it can't check, and replace all the C code that the checker fails on with alternative idioms that fit the restricted model. But at that point it's not a silver bullet of "keep your C codebase, and just use a static analyzer", but it starts looking like a rewrite of C in a more restrictive dialect, and the more guarantees you want, the more code you need to annotate and adapt to the checks.
And this is basically Rust's approach. The unsafe Rust is pretty close to the semantics of C (with UB and all), but by default the code is restricted to a subset designed to be easy for static analysis to be able to guarantee it can't cause UB. Rust has a model checker for pointer aliasing and sharing of data across threads. It has a built-in static analyzer for memory management. It makes programmers specify contracts necessary for the analysis, and verifies that the declarations are logically consistent. It injects assertions for things it can't check at compile time, and gives an option to selectively bypass the checkers for code that doesn't fit their model. It also has a bunch of less rigorous static analyzers detecting certain patterns of logic errors, missing error handling, and flagging suspicious and unidiomatic code.
It would be amazing if C had a static analyzer that could reliably assure with a high level of certainty, out of the box, that a heavily multi-threaded complex code doesn't contain any UB, doesn't corrupt memory, and won't have use-after-free, even if the code is full of dynamic memory (de)allocations, callbacks, thread-locals, on-stack data of one thread shared with another, objects moved between threads, while mixing objects and code from multiple 3rd party libraries. Rust does that across millions lines of code, and it's not even a separate static analyzer with specially-written proofs, it's just how it works.
Such analysis requires code with sufficient annotations and restricted to design patterns that obviously conform to the checkable model. Rust had a luxury of having this from the start, and already has a whole ecosystem built around it.
C doesn't have that. You start from a much worse position (with mutable aliasing, const that barely does anything, and a type system without ownership or any thread safety information) and need to add checks and refactor code just to catch up to the baseline. And in the end, with all that effort, you end up with a C dialect peppered with macros, and merely fix one problem in C, without getting additional benefits of a modern language.
CBMC+C has a higher ceiling than vanilla Rust, and SMT solvers are more powerful, but the choice isn't limited to C+analyzers vs only plain Rust. You still can run additional checkers/solvers on top of everything Rust has built-in, and further proofs are easier thanks to being on top of stronger baseline guarantees and a stricter type system.
If we mark any case that might be undecidable as a failure case, and require that code be written that can be verified, then this is very much sidestepping undecidability by definition. Rust's borrow checker does the same exact thing. Write code that the borrow checker can't verify, and you'll get an error, even if it might be perfectly valid. That's by design, and it's absolutely a design meant to sidestep undecidability.
Yes, CBMC + C provides a higher ceiling. Coupling Kani with Rust results in the exact same ceiling as CBMC + C. Not a higher one. Kani compiles Rust to the same goto-C that CBMC compiles C to. Not a better one. The abstract model and theory that Kani provides is far more strict that what Rust provides with its borrow checker and static analysis. It's also more universal, which is why Kani works on both safe and unsafe Rust.
If you like Rust, great. Use it. But, at the point of coupling Kani and Rust, it's reaching safety parity with model checked C, and not surpassing it. That's fine. Similar safety parity can be reached with Ada + Spark, C++ and ESBMC, Java and JBMC, etc. There are many ways of reaching the same goal.
There's no need to pepper C with macros or to require a stronger type system with C to use CBMC and to get similar guarantees. Strong type systems do provide some structure -- and there's nothing wrong with using one -- but unless we are talking about building a dependent type system, such as what is provided with Lean 4, Coq, Agda, etc., it's not enough to add equivalent safety. A dependent type system also adds undecidability, requiring proofs and tactics to verify the types. That's great, but it's also a much more involved proposition than using a model checker. Rust's H-M type system, while certainly nice for what it is, is limited in what safety guarantees it can make. At that point, choosing a language with a stronger type system or not is a style choice. Arguably, it lets you organize software in a better way that would require manual work in other languages. Maybe this makes sense for your team, and maybe it doesn't. Plenty of people write software in Lisp, Python, Ruby, or similar languages with dynamic and duck typing. They can build highly organized and safe software. In fact, such software can be made safe, much as C can be made safe with the appropriate application of process and tooling.
I'm not defending C or attacking Rust here. I'm pointing out that model checking makes both safer than either can be on their own. As with my original reply, model checking is something different than static analysis, and it's something greater than what either vanilla C or vanilla Rust can provide on their own. Does safe vanilla Rust have better memory safety than vanilla C? Of course. Is it automatically safe against the two dozen other classes of attacks by default and without careful software development? No. Is it automatically safe against these attacks with model checking? Also no. However, we can use model checking to demonstrate the absence of entire classes of bugs -- each of these classes of bugs -- whether we model check software written in C or in Rust.
If I had to choose between model checking an existing codebase (git or the Linux kernel), or slowly rewriting it in another language, I'd choose the former every time. It provides, by far, the largest gain for the least amount of work.
In my experience current AI is still far from reasoning about the kind of hard-to-spot bugs in C that lead to the worst exploits. Rust solves most of these by design. It isn't about adding a second language - it is about slowly phasing out a language that is being misused in areas it shouldn't be in.
C will at some point be relegated to being an educational language, incredibly valuable due to few but good abstractions over assembly. It will continue to exist for decades in most systems, but hopefully it won't be used outside of the maintenance of legacy systems.
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.
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.
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.
> The shell, perl and python are likely for scripting and not used during runtime.
Some git subcommands are implemented in these. git filter-branch is a shell script, git cvsimport is a Perl script, and git p4 (perforce interop) is a Python script. There are not too many left these days (git add -p/-i also used to call a Perl script), but they exist.
I'm sure you are aware, reading between the lines of what you said, why, but for some others who aren't aware of the history of git; it was originally about 50% C and 50% Perl, the performance critical parts were written in C and then various git commands were written in Perl. Over time almost all the Perl was removed because there were less Perl monks than C devs.
Now it would seem the logic is reversed; even though there are less Rust devs than C devs, Rust is going to replace C. Maybe now that git is large enough and entrenched enough such a move can be forced through.
> it was originally about 50% C and 50% Perl, the performance critical parts were written in C and then various git commands were written in Perl.
IIRC, it was mostly shell, not Perl, and looking at the proportion is misleading: the low-level commands (the "plumbing") like git-cat-file or git-commit-tree were all in C, while the more user-friendly commands (the "porcelain") like git-log or git-commit were all shell scripts calling the low-level commands. Yes, even things we consider fundamental today like "git commit" were shell scripts.
I believe gitk and git-gui are written in tcl. Those are definitely things that get shipped to the user, so (at least for those parts) you wouldn't need to have a toolchain on the build server.
A number of the git commands were implemented in perl and shell. Now I see only git-svn is perl here for me and there's still a few shell scripts in /usr/libexec/git.
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...
Rust will, in fact, make it significantly easier to contribute.
In C, you have to remember lots of rules of when what is safe and what locks to hold when. In Rust, APIs are structured to make unsafe use impossible without explicitly saying `unsafe`.
Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped.
> Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped.
This is how it works in the kernel on the C side, too. Usually by using guard/scoped_guard which wrap the generic mutexes with some RAII.
Interestingly enough, this is the only mention of scoped_guard in Documentation/. I will definitely argue that (that part of) Rust is way more approachable.
Using device-managed and cleanup.h constructs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Netdev remains skeptical about promises of all "auto-cleanup" APIs,
including even ``devm_`` helpers, historically. They are not the preferred
style of implementation, merely an acceptable one.
Use of ``guard()`` is discouraged within any function longer than 20 lines,
``scoped_guard()`` is considered more readable. Using normal lock/unlock is
still (weakly) preferred.
Low level cleanup constructs (such as ``__free()``) can be used when building
APIs and helpers, especially scoped iterators. However, direct use of
``__free()`` within networking core and drivers is discouraged.
Similar guidance applies to declaring variables mid-function.
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?
I'm guessing you aren't a software engineer based on this comment, but the difference between programming languages is tangible and meaningful. It isn't like human languages where they're mostly basically the same and achieve the same thing.
And code switching between languages is not hard at all.
It's hilarious that you can assume such a thing just by a couple of words on the internet. Or maybe I'm not a 'software engineer' by your standards because unlike your closed group of SWEs I'm a lot less focused on resume padding and keeping my codebase sane and not exploding in complexity.
I should specify - it's hard in that it's troublesome to have to code switch and do a bunch of recall before working on the thing.
Say you've not worked on this secondary language for a long time, which absolutely happens, and have spend hours of effort to recall it. This takes time that you need not spend on, it's how your memory works.
I didn’t make the assumption but it sounded like a reasonable assumption based on the pronouns you used. You said “could you software engineers stop making things harder for yourselves.” A reasonable interpretation of this is that you aren’t a software engineer.
Reinforced softly by the rest of your comment not being technically sound. Adding a second language that is meaningfully different in its strengths and weaknesses isn’t “bureaucracy”. Bureaucracy is more like “sign a CLA before you can contribute”.
Okay then how about another interpretation: I'm a software engineer questioning the boarder group of SWEs on what they're trying. (Somehow I have to show you another interpretation I can't believe how tunneled people can be).
Also bureaucracy is added friction, usually done by humans. It can be found everywhere where you're working with humans, from leetcode interviews and code styles and practices. It's not just a bunch of signed papers.
Sure you can add the second language if adds value, but let's not pretend that the added friction isn't there. If you could solve your problems without the friction of second language it would be better.
> I should specify - it's hard in that it's troublesome to have to code switch and do a bunch of recall before working on the thing.
You don't sound like you have any experience working on software projects. I can tell you it's not hard to switch between programming languages. If anything, the difficulty level is placed on onboarding onto projects you are not familiar with, but the programming language in use is far from being a relevant factor if you already are familiar with it.
Even if it's 'not hard' your brain has to compensate for switching to another realm/space and that takes energy and time especially if you haven't used that particular space for a long time.
This is backed by science. Go read up on short-term working memory and crystallized memory.
All this will add up the maintenance costs, so it had better be a good trade off.
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?
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...
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.
I know that it is a "slippery slope" argument, but in the future, it will become more difficult to contribute without knowing Rust. That's the entire point of introducing it.
I guess in a certain sense, yes, the total number of lines of code in C will go down, so the difficulty of finding a place to contribute will go down by that metric. On the other hand, I'd argue that it seems rather unlikely that literally all of the C code will be gone from git at least over the next couple of decades (and that's assuming that there's even a desire to rewrite it entirely, which doesn't seem like it's anywhere close to even being possible to discuss seriously any time soon), so it seems like the amount of difficulty will be so small that it's a bit silly to worry about it. Keep in mind that there's still not anything stopping new code from being written in C just because new code might also be possible to write in Rust. Right now, it's literally impossible to contribute Rust code to git, so if it becomes infinitesimally harder to contribute C code to make contributing Rust code possible, that's still a arguably a much larger increase in the net "contributability" of the git codebase, for lack of a better term.
I understand that it's a minor change in its current state. However, it is a fact that the long term goal is to port everything to rust. Once that goal is accomplished, rust will be required. So it is not at all a gross exaggeration. It's a prediction of the future.
I don't even disagree with that goal, I think it's desirable that things be written in rust, it's a really good language that provides a lot of benefits. I think I've just been infected with the C virus too long. I can't even tolerate C++.
> I understand that it's a minor change in its current state. However, it is a fact that the long term goal is to port everything to rust. Once that goal is accomplished, rust will be required. So it is not at all a gross exaggeration. It's a prediction of the future.
Whose goal is this? I know that there's a perception of there being a loud, vocal contingent of people who have this goal in general, but is there anyone who actually is involved in git maintenance who has stated this intent? The proposal linked above states the following:
> As said, the entire goal is for us to have an easy playground that we can experiment on and develop the infrastructure incrementally without yet having to commit to anything.
> I'm mostly splitting out the topic of introducing Rust from the larger series that introduce it into xdiff so that we can focus more on the actual process of introducing Rust into Git and less on the potential features that we want to build on top of it.
My reading of this is that there are specific features that they at least want to consider using Rust for, and that having support for it in the build process is a prerequisite for that. That doesn't imply at all to me that they would want to rewrite all existing features in it, or to prevent new C code from being written for git after some point in the future. Even if there are some people involved with that goal, it hardly seems like that goal is shared by everyone who might be involved in that type of decision, and I'd argue that people wouldn't even have to be in agreement about that goal to be in favor of this step. I don't find it that hard to believe someone might want to allow using Rust for new features but generally be against the idea of rewriting all features in Rust.
Having written Rust professionally for six years and used it for around a decade, my experience is that there are surprisingly few prolific Rust programmers who seem to devote much time to thinking about trying to get existing projects to rewrite all of their codebase into Rust. It's much more likely that they'd just start an entirely new project that overlaps substantially with an existing one, although even then it's rare for the new project to ever get anywhere close to fully replacing the existing one (if that's even the goal); ripgrep might have wide adoption alongside grep, but grep isn't going anywhere, and I suspect that burntsushi would be one of the last people to suggest it would.
There's also a lot of significant work spent on improving Rust's ability to interoperate with other languages. Libraries made with bindgen (and cbindgen in the other direction) probably have done far more to ameliorate Rust programmers to using existing libraries in other languages than to expedite them being rewritten, and there are some popular wrappers that try to go beyond that and try to provide even more idiomatic wrappers for specific languages like pyo3 for Python, neon for NodeJS, and cxx for C++ (which was written by the same person who basically single-handedly created the current proc macro ecosystem in Rust alongside specific libraries utilizing it like serde and thiserror, so hardly someone who would have no motivation to try to have more code rewritten in Rust). If there are people making an effort being made to try to tell everyone to rewrite everything in Rust, there's just as much effort going on from people writing Rust to actively try to work with existing code in other languages, and their work is having far more impact than the first group.
I honestly can't help but wonder if the only reason the debate about rewriting stuff in Rust is still going on is that the people against it engage with it rather than just ignoring it as empty bluster. My hot take is that there's never been anywhere close to the critical mass of people with the skill and desire to put in the work that would be required to make it happen, and there likely never will be, so the debate been sustained on one side by a range from armchair quarterbacking to intentional ragebait, and on the other side by a range from misguided attempts to engage seriously with what's essentially always been just a meme to pearl-clutching at the idea that someone would dare question the status quo. Maybe there was an interesting philosophical debate to be had about the hypothetical merits of rewriting the world in Rust in the early days, but we're long past the point where there's anything useful left to say on the topic, so we'd all be better off by just collectively moving on and figuring out how things will play out in the real world. C and C++ are definitely not going anywhere in our lifetimes, and Rust has sufficiently proved that it can be used successfully in professional contexts, so the remaining questions are all going to be about tradeoffs between legitimate choices rather than jockeying to see who sticks around in a "winner-takes-all" ecosystem.
I think it is really as simple as this: change is hard and a lot of people struggle with it to varying degrees for different reasons. Just look around at the people in your life and how they react to changes. It's really the same sort of pattern that plays out with Rust.
I distinctly remember reading the comments in the thread here about the initial release of ripgrep, and I remember coming away with a strong impression not just of your technical skill (which was apparent even before reading the thread), but just how pragmatic your viewpoint was. I didn't get the feeling you had any desire to displace anything, but just to solve a specific problem for people who wanted it, and if some people preferred not to use it, that was fine too! As someone who was fairly early on in my software career then, it was an extremely valuable lesson in humility from someone with a pedigree that I presumably wouldn't ever match.
Your reappearance here after my mention is probably another useful lesson for me to have a bit more empathy for those who are reacting more strongly to this announcement than I'd otherwise understand.
Thanks for the kind words! And I'm not perfect either. I find the resistance to change to be extremely frustrating at points. And especially so when it involves misinformation of some sort.
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...
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.
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.
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.
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.
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.
> Though I would argue the absurd amount of undefined behavior makes it not even simple by design.
What? UB is the simplest thing you can do when you just don't want to specify behavior. Any specified behavior can't be simpler that unspecified because it's just comparing nothing with something
Ferrocene has donated their specification to the project, so there absolutely is a specification now. What you can argue is that the memory model isn‘t fully defined, but it‘s almost certainly going to land somewhere around stacked borrows or tree borrows. Arguably C doesn‘t fare much better in that regard though as it doesn‘t even properly define its pointer provenance model either and Rust is much closer to defining its.
Note that, in compiler lingo, unspecified and undefined are two different things. C++ is specified to death, but full of undefined behavior (and also some unspecified behavior).
Rust is largely not specified, but aims to have no undefined behavior (outside of unsafe blocks).
I am aware but without a spec we don’t know which is which. You can’t say it has no undefined behavior because what happens is you try to specify it and find gaps or challenges.
In C undefined is used primarily when there is not a reliable and efficient mechanism for detecting a problem is happening. For example a C implementation may check every single invalid pointer deref, but more realistically it only detects only extreme out of range. So it’s undefined what happens.
> I am aware but without a spec we don’t know which is which.
I don't think I fully agree with this. A more accurate statement might be that "without a spec we don't always know which is which". You obviously don't need a spec to pin down at least some of a language's behavior, and even then the presence of a spec doesn't necessarily mean that you can answer arbitrary questions about what behavior is intended (c.f., various defect reports in the C/C++ spec asking clarifying questions, pointing out holes/deficiencies, or even admitting that certain behavior is not intended but being unsure about how to forbid it)
That being said, at least in C++, undefined has been used largely as a joker for compiler optimizations. In Rust, if my memory serves, having the same code produce different results depending on the optimization level would be considered a pretty serious bug. In C++, it's par for the course.
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.
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.
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.
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.
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.
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?).
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?
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?
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.
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...
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.
Since OpenJDK was released there isn't much point maintaining GCJ.
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.
I hope for the former since then the functionality might become available as attributes in C too.
yep, if git is content with rustc_codegen_gcc, then it's very doable they can require rust in the next few years
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?
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/
git feels complete until you use a tool like jj or git-branchless (latter of which has things like in-memory merges in rust)
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
Or if you use its predecessor, bitkeeper.
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.)
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.
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
Why not zig tho.. keep the C, compile with zigcc and write new code in zig. Best of both worlds.
uwu but zig doesn't give you memory and concurrency safety guarantees, oniichan!
Idk if it's funny or sad, cause it's true.
> 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.
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.
To capture existing status for Rust promoters.
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.
I don't know even one developer who uses Jujutsu.
[dead]
C is unsafe.
Changing well-tested code is unsafe.
not changing working code to prevent issues is unsafe.
we can go in circles all day with blanket statements that are all true. but we have ample evidence that even if we think some real-world C code is safe, it is often not because humans are extremely bad at writing safe C.
sometimes it's worth preventing that more strongly, sometimes it's not, evidently they think that software that a truly gigantic amount of humans and machines use is an area where it's worth the cost.
believing that rewriting to rust will make code safe is unsafe) Of course it will be safer, but not safe. Safety is a marketing feature of rust and no more. But a lot of people really believe in it and will be zealously trying to prove that rust is safe.
If the code is brittle to change, it must not have been particularly safe in the first place, right?
And if it's well-tested, maybe that condition is achieved by the use of a test suite which could verify the changes are safe too?
A test will never catch every bug, otherwise it's a proof, and any change has the probability to introduce a new bug, irregardless of how careful you are. Thus, changing correct code will eventually result in incorrect code.
I'm not sure if that's how probability works.
I mean if you want Git to never change you're free to stick with the current version forever. I'm sure that will work well.
I obviously don’t think that is wise, but Git is literally designed with this in mind: https://git-scm.com/docs/repository-version/2.39.0
Just like SQLite has an explicit compatibility guarantee through 2050. You literally do not have to update if you do not want to.
And it’s still a choice you can make regardless of Git moving to Rust or not, so what’s the problem?
This is the repo format version.
It's pretty different from the git version, which receives new releases all the time for things like security patches, improvements, and new features.
https://github.com/Speykious/cve-rs
Rust is not perfect, but perfect C is nearly impossible.
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...)
As a user, you may not be aware that C makes it relatively easy to create https://en.m.wikipedia.org/wiki/Buffer_overflow which are a major source of security vulnerabilities.
This is one of the best reasons to rewrite software in Rust or any other more safe by default language.
Everyone on hackernews is well aware that C makes it relatively easy to create buffer overflows, and what buffer overflows are. You're still not responding to GP question.
I'm not involved in the initiative so I can't answer the question definitively? I provided one of the major reasons that projects get switched from C. I think it's likely to be a major part of the motivation.
I didn't know that C makes it easy.
Right, I never mentioned that I am a decently experienced C developer, so of course I got my fair share of buffer overflows and race conditions :)
I have also learned some Rust recently, I find a nice language and quite pleasant to work with. I understand its benefits.
But still, Git is already a mature tool (one may say "finished"). Lots of bugs have been found and fixed. And if more are found, sure it will be easier to fix them in the C code, rather than rewriting in Rust? Unless the end goal is to rewrite the whole thing in Rust piece by piece, solving hidden memory bugs along the way.
https://access.redhat.com/articles/2201201 and https://github.com/git/git/security/advisories/GHSA-4v56-3xv... are interesting examples to consider (though I'm curious whether Rust's integer overflow behavior in release builds would have definitely fared better?).
> Unless the end goal is to rewrite the whole thing in Rust piece by piece, solving hidden memory bugs along the way.
I would assume that's the case.
> though I'm curious whether Rust's integer overflow behavior in release builds would have definitely fared better?
Based on the descriptions it's not the integer overflows that are issues themselves, it's that the overflows can lead to later buffer overflows. Rust's default release behavior is indeed to wrap on overflow, but buffer overflow checks will remain by default, so barring the use of unsafe I don't think there would have been corresponding vulnerabilities in Rust.
This doesn't matter at all for programs like Git. Any non-free standing program running on a modern OS on modern hardware trying to access memory its not supposed to will be killed by the OS. This seams to be the more reasonable security-boundary then relying on the language implementation to just not issue code, that does illegal things.
Yeah sure, memory-safety is nice for debuggibility and being more confident in the programs correctness, but it is not more than that. It is neither security nor proven correctness.
Not quite the best example, since Git usually has unrestricted file access and network access through HTTP/SSH, any kind of RCE would be disastrous if used for data exfiltration, for instance.
If you want a better example, take distributed database software: behind DMZ, and the interesting code paths require auth.
Git already runs "foreign" code e.g. in filters. The ability to write code that reacts unexpectedly on crafted user input isn't restricted to languages providing unchecked array/pointer access.
Unintentional bugs that caused data destruction would also be disastrous for a tool like git
Which are more likely to be introduced by a full rewrite.
> Any non-free standing program running on a modern OS on modern hardware trying to access memory its not supposed to will be killed by the OS.
This seems like a rather strong statement to me. Do you mind elaborating further?
I think bugs in the MMU hardware or the kernel accidentally configuring the MMU to allow access across processes that isn't supposed to be are quite rare.
[dead]
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.
> 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.
I think it is often under appreciated by people who haven't worked in security how hard high quality C is in practice.
We might also have different priorities. I do not care too much that google and apple want to lock down their smartphone spyware and sales platforms. The supply chain risks and maintenance burden imposed onto me by the Rust ecosystem are much more of an concern.
I don't know what this has to do with locking down phones, but I do appreciate not getting compromised just for cloning a repo or opening my laptop at a coffee shop.
(There is a persistent idea that the lack of memory safety in C is good because it allows people to jailbreak their phones.)
This is not what I said, but memory safety is certainly not anything which is a high priority for my own security. I still think memory safety is important and I also think Rust is an interesting language, but... the hype is exaggerated and driven by certain industry interests.
Rust isn't popular just because of memory safety though. I think the memory safety message is maybe a little too loud.
It's also a modern language with fantastic tooling, very high quality library ecosystem and a strong type system that reduces the chance of all kinds of bugs.
It's obviously not perfect: compile time is ... ok, there aren't any mature GUI toolkits (though that's true of many languages), async Rust has way too many footguns. But it's still waaaaay better than C or C++. In a different league.
Rust is a nice language, but it pushed too aggressively with the argument of "memory safety" at all cost ignoring other considerations. And Cargo is certainly a disaster even though it may be considered "fantastic tooling" by some. In any case, I do not think it is funny that I now depend on packages without timely security update in my distribution. This makes me less secure.
Is there better tooling in C/C++? No snark intended?
I guess this depends on what you consider good tooling. I am relatively happy with C tooling. But if you want to quickly assemble something from existing libraries, then language-level package managers like npm, cargo, pip are certainly super convenient. But then, I think this convenience comes at a high cost. We now have worms again, I thought those times were long over... IMHO package management belongs into a distribution with quality control and dependencies should be minimized and carefully selected.
It can have supply chain attacks like npm... That high quality library system is also a liability.
I'm an industry interest, in the sense that I work in the software industry and I have an interest in Rust.
Fair enough. I just find it mind boggling how much money flows into completely new language ecosystems compared to improvements for C/C++ tooling which would clearly much more effective if you really cared about overall security of the free software world.
The issue with investing similar levels of effort into making C++ safer is the C++ standards committee doesn't want to adopt those kinds of improvements.
I am not interested in C++, it is also far too complex. In my opinion software needs to become simpler and not more complicated, and I fear Rust might be a step into the wrong direction.
Which is also the reason why we don't have #pragma once and many other extensions like it. Except we do. Compilers can add rust-like static analyzers without the standard committee mandating it.
In principle, the full lifetime system of Rust can be added to C++ without committee approval, but in reality the chances seem low.
Personally, I use Rust (and have been using it for close to 9 years) because I've been part of multiple teams that have delivered reliable, performant systems software in it, within a budget that would clearly be impossible in any other language. Rust acts as a step change in getting things done.
While I really really want devices I can own, I don't want to compromise security to do it. We need to do two things:
1. Lobby politicians to write laws that allow us to actually own the devices we bought.
2. Stop the FUD that a device that can be jailbroken is insecure. I heard this from our frigging CSO, of all people, and it's patently false, just FUD by Apple and Google who want you to be afraid of owning your device.
I want a device that's as secure as possible, but that I can own. I don't want to hack my own self just to get what I paid for.
It is a sad thing but I do root against secure boot initiatives because they almost entirely work to limit user's freedom instead of improving their security.
Thanks, that take is... Something. I'm all for user-controllable hardware but I think that's a regulatory problem not a technical one.
How often do you clone a repo and don't immediately run build commands that execute scripts provided by the repo.
Who says you do not? :)
Oh, I think it's a real problem, that's why I'm in favor of improved tools.
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.
> 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.
No one’s laying off COBOL programmers. Specialization has its upsides once the market isn’t saturated!
Well only because 99% of the world's COBOL developers were laid off decades ago (or switched to another language).
The more things change,
As someone with experience in this specific niche, yes they absolutely are. There are no longer ten thousand retail chains asking for COBOL-based counterpoint PoS mods on a yearly basis.
The COBOL market is basically tenured experts in existing systems or polyglots helping migrate the systems to VB or C# at this point. The market has plummeted and now it's in the final deflationary shrink before death.
Ah, damn, I’m sad to hear that. Always respected the language. :/
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?
[flagged]
Rust is over 10 years old now. It has a track record of delivering what it promises, and a very satisfied growing userbase.
OTOH static analyzers for C have been around for longer than Rust, and we're still waiting for them to disprove Rice's theorem.
AI tools so far are famous for generating low-quality code, and generating bogus vulnerability reports. They may eventually get better and end up being used to make C code secure - see DARPA's TRACTOR program.
The applicability of Rice's theorem with respect to static analysis or abstract interpretation is more complex than you implied. First, static analysis tools are largely pattern-oriented. Pattern matching is how they sidestep undecidability. These tools have their place, but they aren't trying to be the tooling you or the parent claim. Instead, they are more useful to enforce coding style. This can be used to help with secure software development practices, but only by enforcing idiomatic style.
Bounded model checkers, on the other hand, are this tooling. They don't have to disprove Rice's theorem to work. In fact, they work directly with this theorem. They transform code into state equations that are run through an SMT solver. They are looking for logic errors, use-after-free, buffer overruns, etc. But, they also fail code for unterminated execution within the constraints of the simulation. If abstract interpretation through SMT states does not complete in a certain number of steps, then this is also considered a failure. The function or subset of the program only passes if the SMT solver can't find a satisfactory state that triggers one of these issues, through any possible input or external state.
These model checkers also provide the ability for user-defined assertions, making it possible to build and verify function contracts. This allows proof engineers to tie in proofs about higher level properties of code without having to build constructive proofs of all of this code.
Rust has its own issues. For instance, its core library is unsafe, because it has to use unsafe operations to interface with the OS, or to build containers or memory management models that simply can't be described with the borrow checker. This has led to its own CVEs. To strengthen the core library, core Rust developers have started using Kani -- a bounded model checker like those available for C or other languages.
Bounded model checking works. This tooling can be used to make either C or Rust safer. It can be used to augment proofs of theorems built in a proof assistant to extend this to implementation. The overhead of model checking is about that of unit testing, once you understand how to use it.
It is significantly less expensive to teach C developers how to model check their software using CBMC than it is to teach them Rust and then have them port code to Rust. Using CBMC properly, one can get better security guarantees than using vanilla Rust. Overall, an Ada + Spark, CBMC + C, Kani + Rust strategy coupled with constructive theory and proofs regarding overall architectural guarantees will yield equivalent safety and security. I'd trust such pairings of process and tooling -- regardless of language choice -- over any LLM derived solutions.
Sure it's possible in theory, but how many C codebases actually use formal verification? I don't think I've seen a single one. Git certainly doesn't do anything like that.
I have occasionally used CBMC for isolated functions, but that must already put me in the top 0.1% of formal verification users.
It's not used more because it is unknown, not because it is difficult to use or that it is impractical.
I've written several libraries and several services now that have 100% coverage via CBMC. I'm quite experienced with C development and with secure development, and reaching this point always finds a handful of potentially exploitable errors I would have missed. The development overhead of reaching this point is about the same as the overhead of getting to 80% unit test coverage using traditional test automation.
You're describing cases in which static analyzers/model checkers give up, and can't provide a definitive answer. To me this isn't side-stepping the undecidability problem, this is hitting the problem.
C's semantics create dead-ends for non-local reasoning about programs, so you get inconclusive/best-effort results propped up by heuristics. This is of course better than nothing, and still very useful for C, but it's weak and limited compared to the guarantees that safe Rust gives.
The bar set for Rust's static analysis and checks is to detect and prevent every UB in safe Rust code. If there's a false positive, people file it as a soundness bug or a CVE. If you can make Rust's libstd crash from safe Rust code, even if it requires deliberately invalid inputs, it's still a CVE for Rust. There is no comparable expectation of having anything reliably checkable in C. You can crash stdlib by feeding it invalid inputs, and it's not a CVE, just don't do that. Static analyzers are allowed to have false negatives, and it's normal.
You can get better guarantees for C if you restrict semantics of the language, add annotations/contracts for gaps in its type system, add assertions for things it can't check, and replace all the C code that the checker fails on with alternative idioms that fit the restricted model. But at that point it's not a silver bullet of "keep your C codebase, and just use a static analyzer", but it starts looking like a rewrite of C in a more restrictive dialect, and the more guarantees you want, the more code you need to annotate and adapt to the checks.
And this is basically Rust's approach. The unsafe Rust is pretty close to the semantics of C (with UB and all), but by default the code is restricted to a subset designed to be easy for static analysis to be able to guarantee it can't cause UB. Rust has a model checker for pointer aliasing and sharing of data across threads. It has a built-in static analyzer for memory management. It makes programmers specify contracts necessary for the analysis, and verifies that the declarations are logically consistent. It injects assertions for things it can't check at compile time, and gives an option to selectively bypass the checkers for code that doesn't fit their model. It also has a bunch of less rigorous static analyzers detecting certain patterns of logic errors, missing error handling, and flagging suspicious and unidiomatic code.
It would be amazing if C had a static analyzer that could reliably assure with a high level of certainty, out of the box, that a heavily multi-threaded complex code doesn't contain any UB, doesn't corrupt memory, and won't have use-after-free, even if the code is full of dynamic memory (de)allocations, callbacks, thread-locals, on-stack data of one thread shared with another, objects moved between threads, while mixing objects and code from multiple 3rd party libraries. Rust does that across millions lines of code, and it's not even a separate static analyzer with specially-written proofs, it's just how it works.
Such analysis requires code with sufficient annotations and restricted to design patterns that obviously conform to the checkable model. Rust had a luxury of having this from the start, and already has a whole ecosystem built around it.
C doesn't have that. You start from a much worse position (with mutable aliasing, const that barely does anything, and a type system without ownership or any thread safety information) and need to add checks and refactor code just to catch up to the baseline. And in the end, with all that effort, you end up with a C dialect peppered with macros, and merely fix one problem in C, without getting additional benefits of a modern language.
CBMC+C has a higher ceiling than vanilla Rust, and SMT solvers are more powerful, but the choice isn't limited to C+analyzers vs only plain Rust. You still can run additional checkers/solvers on top of everything Rust has built-in, and further proofs are easier thanks to being on top of stronger baseline guarantees and a stricter type system.
If we mark any case that might be undecidable as a failure case, and require that code be written that can be verified, then this is very much sidestepping undecidability by definition. Rust's borrow checker does the same exact thing. Write code that the borrow checker can't verify, and you'll get an error, even if it might be perfectly valid. That's by design, and it's absolutely a design meant to sidestep undecidability.
Yes, CBMC + C provides a higher ceiling. Coupling Kani with Rust results in the exact same ceiling as CBMC + C. Not a higher one. Kani compiles Rust to the same goto-C that CBMC compiles C to. Not a better one. The abstract model and theory that Kani provides is far more strict that what Rust provides with its borrow checker and static analysis. It's also more universal, which is why Kani works on both safe and unsafe Rust.
If you like Rust, great. Use it. But, at the point of coupling Kani and Rust, it's reaching safety parity with model checked C, and not surpassing it. That's fine. Similar safety parity can be reached with Ada + Spark, C++ and ESBMC, Java and JBMC, etc. There are many ways of reaching the same goal.
There's no need to pepper C with macros or to require a stronger type system with C to use CBMC and to get similar guarantees. Strong type systems do provide some structure -- and there's nothing wrong with using one -- but unless we are talking about building a dependent type system, such as what is provided with Lean 4, Coq, Agda, etc., it's not enough to add equivalent safety. A dependent type system also adds undecidability, requiring proofs and tactics to verify the types. That's great, but it's also a much more involved proposition than using a model checker. Rust's H-M type system, while certainly nice for what it is, is limited in what safety guarantees it can make. At that point, choosing a language with a stronger type system or not is a style choice. Arguably, it lets you organize software in a better way that would require manual work in other languages. Maybe this makes sense for your team, and maybe it doesn't. Plenty of people write software in Lisp, Python, Ruby, or similar languages with dynamic and duck typing. They can build highly organized and safe software. In fact, such software can be made safe, much as C can be made safe with the appropriate application of process and tooling.
I'm not defending C or attacking Rust here. I'm pointing out that model checking makes both safer than either can be on their own. As with my original reply, model checking is something different than static analysis, and it's something greater than what either vanilla C or vanilla Rust can provide on their own. Does safe vanilla Rust have better memory safety than vanilla C? Of course. Is it automatically safe against the two dozen other classes of attacks by default and without careful software development? No. Is it automatically safe against these attacks with model checking? Also no. However, we can use model checking to demonstrate the absence of entire classes of bugs -- each of these classes of bugs -- whether we model check software written in C or in Rust.
If I had to choose between model checking an existing codebase (git or the Linux kernel), or slowly rewriting it in another language, I'd choose the former every time. It provides, by far, the largest gain for the least amount of work.
In my experience current AI is still far from reasoning about the kind of hard-to-spot bugs in C that lead to the worst exploits. Rust solves most of these by design. It isn't about adding a second language - it is about slowly phasing out a language that is being misused in areas it shouldn't be in.
C will at some point be relegated to being an educational language, incredibly valuable due to few but good abstractions over assembly. It will continue to exist for decades in most systems, but hopefully it won't be used outside of the maintenance of legacy systems.
> 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.
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.
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.
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.
Oh no, we need Rust all the way to the core. /s
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.
> The shell, perl and python are likely for scripting and not used during runtime.
Some git subcommands are implemented in these. git filter-branch is a shell script, git cvsimport is a Perl script, and git p4 (perforce interop) is a Python script. There are not too many left these days (git add -p/-i also used to call a Perl script), but they exist.
I'm sure you are aware, reading between the lines of what you said, why, but for some others who aren't aware of the history of git; it was originally about 50% C and 50% Perl, the performance critical parts were written in C and then various git commands were written in Perl. Over time almost all the Perl was removed because there were less Perl monks than C devs.
Now it would seem the logic is reversed; even though there are less Rust devs than C devs, Rust is going to replace C. Maybe now that git is large enough and entrenched enough such a move can be forced through.
> it was originally about 50% C and 50% Perl, the performance critical parts were written in C and then various git commands were written in Perl.
IIRC, it was mostly shell, not Perl, and looking at the proportion is misleading: the low-level commands (the "plumbing") like git-cat-file or git-commit-tree were all in C, while the more user-friendly commands (the "porcelain") like git-log or git-commit were all shell scripts calling the low-level commands. Yes, even things we consider fundamental today like "git commit" were shell scripts.
I believe gitk and git-gui are written in tcl. Those are definitely things that get shipped to the user, so (at least for those parts) you wouldn't need to have a toolchain on the build server.
A number of the git commands were implemented in perl and shell. Now I see only git-svn is perl here for me and there's still a few shell scripts in /usr/libexec/git.
> 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.
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...
Rust will, in fact, make it significantly easier to contribute.
In C, you have to remember lots of rules of when what is safe and what locks to hold when. In Rust, APIs are structured to make unsafe use impossible without explicitly saying `unsafe`.
Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped.
> Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped.
This is how it works in the kernel on the C side, too. Usually by using guard/scoped_guard which wrap the generic mutexes with some RAII.
Interestingly enough, this is the only mention of scoped_guard in Documentation/. I will definitely argue that (that part of) Rust is way more approachable.
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?
I'm guessing you aren't a software engineer based on this comment, but the difference between programming languages is tangible and meaningful. It isn't like human languages where they're mostly basically the same and achieve the same thing.
And code switching between languages is not hard at all.
It's hilarious that you can assume such a thing just by a couple of words on the internet. Or maybe I'm not a 'software engineer' by your standards because unlike your closed group of SWEs I'm a lot less focused on resume padding and keeping my codebase sane and not exploding in complexity.
I should specify - it's hard in that it's troublesome to have to code switch and do a bunch of recall before working on the thing.
Say you've not worked on this secondary language for a long time, which absolutely happens, and have spend hours of effort to recall it. This takes time that you need not spend on, it's how your memory works.
I didn’t make the assumption but it sounded like a reasonable assumption based on the pronouns you used. You said “could you software engineers stop making things harder for yourselves.” A reasonable interpretation of this is that you aren’t a software engineer.
Reinforced softly by the rest of your comment not being technically sound. Adding a second language that is meaningfully different in its strengths and weaknesses isn’t “bureaucracy”. Bureaucracy is more like “sign a CLA before you can contribute”.
Okay then how about another interpretation: I'm a software engineer questioning the boarder group of SWEs on what they're trying. (Somehow I have to show you another interpretation I can't believe how tunneled people can be).
Also bureaucracy is added friction, usually done by humans. It can be found everywhere where you're working with humans, from leetcode interviews and code styles and practices. It's not just a bunch of signed papers.
Sure you can add the second language if adds value, but let's not pretend that the added friction isn't there. If you could solve your problems without the friction of second language it would be better.
> I should specify - it's hard in that it's troublesome to have to code switch and do a bunch of recall before working on the thing.
You don't sound like you have any experience working on software projects. I can tell you it's not hard to switch between programming languages. If anything, the difficulty level is placed on onboarding onto projects you are not familiar with, but the programming language in use is far from being a relevant factor if you already are familiar with it.
you're completely missing the point.
Even if it's 'not hard' your brain has to compensate for switching to another realm/space and that takes energy and time especially if you haven't used that particular space for a long time.
This is backed by science. Go read up on short-term working memory and crystallized memory.
All this will add up the maintenance costs, so it had better be a good trade off.
Dude you said "Could you software engineers stop..."
In normal English that means you aren't a software engineer.
[flagged]
[flagged]
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?
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...
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.
I know that it is a "slippery slope" argument, but in the future, it will become more difficult to contribute without knowing Rust. That's the entire point of introducing it.
I guess in a certain sense, yes, the total number of lines of code in C will go down, so the difficulty of finding a place to contribute will go down by that metric. On the other hand, I'd argue that it seems rather unlikely that literally all of the C code will be gone from git at least over the next couple of decades (and that's assuming that there's even a desire to rewrite it entirely, which doesn't seem like it's anywhere close to even being possible to discuss seriously any time soon), so it seems like the amount of difficulty will be so small that it's a bit silly to worry about it. Keep in mind that there's still not anything stopping new code from being written in C just because new code might also be possible to write in Rust. Right now, it's literally impossible to contribute Rust code to git, so if it becomes infinitesimally harder to contribute C code to make contributing Rust code possible, that's still a arguably a much larger increase in the net "contributability" of the git codebase, for lack of a better term.
And also, a lot of people who hate C, or who never learned it well, will be able to contribute to more and more areas of the Linux kernel.
I understand that it's a minor change in its current state. However, it is a fact that the long term goal is to port everything to rust. Once that goal is accomplished, rust will be required. So it is not at all a gross exaggeration. It's a prediction of the future.
I don't even disagree with that goal, I think it's desirable that things be written in rust, it's a really good language that provides a lot of benefits. I think I've just been infected with the C virus too long. I can't even tolerate C++.
> I understand that it's a minor change in its current state. However, it is a fact that the long term goal is to port everything to rust. Once that goal is accomplished, rust will be required. So it is not at all a gross exaggeration. It's a prediction of the future.
Whose goal is this? I know that there's a perception of there being a loud, vocal contingent of people who have this goal in general, but is there anyone who actually is involved in git maintenance who has stated this intent? The proposal linked above states the following:
> As said, the entire goal is for us to have an easy playground that we can experiment on and develop the infrastructure incrementally without yet having to commit to anything.
> I'm mostly splitting out the topic of introducing Rust from the larger series that introduce it into xdiff so that we can focus more on the actual process of introducing Rust into Git and less on the potential features that we want to build on top of it.
My reading of this is that there are specific features that they at least want to consider using Rust for, and that having support for it in the build process is a prerequisite for that. That doesn't imply at all to me that they would want to rewrite all existing features in it, or to prevent new C code from being written for git after some point in the future. Even if there are some people involved with that goal, it hardly seems like that goal is shared by everyone who might be involved in that type of decision, and I'd argue that people wouldn't even have to be in agreement about that goal to be in favor of this step. I don't find it that hard to believe someone might want to allow using Rust for new features but generally be against the idea of rewriting all features in Rust.
Having written Rust professionally for six years and used it for around a decade, my experience is that there are surprisingly few prolific Rust programmers who seem to devote much time to thinking about trying to get existing projects to rewrite all of their codebase into Rust. It's much more likely that they'd just start an entirely new project that overlaps substantially with an existing one, although even then it's rare for the new project to ever get anywhere close to fully replacing the existing one (if that's even the goal); ripgrep might have wide adoption alongside grep, but grep isn't going anywhere, and I suspect that burntsushi would be one of the last people to suggest it would.
There's also a lot of significant work spent on improving Rust's ability to interoperate with other languages. Libraries made with bindgen (and cbindgen in the other direction) probably have done far more to ameliorate Rust programmers to using existing libraries in other languages than to expedite them being rewritten, and there are some popular wrappers that try to go beyond that and try to provide even more idiomatic wrappers for specific languages like pyo3 for Python, neon for NodeJS, and cxx for C++ (which was written by the same person who basically single-handedly created the current proc macro ecosystem in Rust alongside specific libraries utilizing it like serde and thiserror, so hardly someone who would have no motivation to try to have more code rewritten in Rust). If there are people making an effort being made to try to tell everyone to rewrite everything in Rust, there's just as much effort going on from people writing Rust to actively try to work with existing code in other languages, and their work is having far more impact than the first group.
I honestly can't help but wonder if the only reason the debate about rewriting stuff in Rust is still going on is that the people against it engage with it rather than just ignoring it as empty bluster. My hot take is that there's never been anywhere close to the critical mass of people with the skill and desire to put in the work that would be required to make it happen, and there likely never will be, so the debate been sustained on one side by a range from armchair quarterbacking to intentional ragebait, and on the other side by a range from misguided attempts to engage seriously with what's essentially always been just a meme to pearl-clutching at the idea that someone would dare question the status quo. Maybe there was an interesting philosophical debate to be had about the hypothetical merits of rewriting the world in Rust in the early days, but we're long past the point where there's anything useful left to say on the topic, so we'd all be better off by just collectively moving on and figuring out how things will play out in the real world. C and C++ are definitely not going anywhere in our lifetimes, and Rust has sufficiently proved that it can be used successfully in professional contexts, so the remaining questions are all going to be about tradeoffs between legitimate choices rather than jockeying to see who sticks around in a "winner-takes-all" ecosystem.
Yes, you're correct about me. :-)
I think it is really as simple as this: change is hard and a lot of people struggle with it to varying degrees for different reasons. Just look around at the people in your life and how they react to changes. It's really the same sort of pattern that plays out with Rust.
I distinctly remember reading the comments in the thread here about the initial release of ripgrep, and I remember coming away with a strong impression not just of your technical skill (which was apparent even before reading the thread), but just how pragmatic your viewpoint was. I didn't get the feeling you had any desire to displace anything, but just to solve a specific problem for people who wanted it, and if some people preferred not to use it, that was fine too! As someone who was fairly early on in my software career then, it was an extremely valuable lesson in humility from someone with a pedigree that I presumably wouldn't ever match.
Your reappearance here after my mention is probably another useful lesson for me to have a bit more empathy for those who are reacting more strongly to this announcement than I'd otherwise understand.
Thanks for the kind words! And I'm not perfect either. I find the resistance to change to be extremely frustrating at points. And especially so when it involves misinformation of some sort.
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.
Once the C evangelism strike force pushed C code into rust projects you might have an argument.
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...
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.
Removing Perl and adding Rust instead is probably reducing complexity rather than increasing it.
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.
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.
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.
> 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!
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.
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.
> Rust is a tire fire of complexity.
And C isn't?
It really isn't. C is very simple.
We are talking about two axis here:
- Complex by design
- Complex to use
C is complex to use because it is simple by design.
Though I would argue the absurd amount of undefined behavior makes it not even simple by design.
> Though I would argue the absurd amount of undefined behavior makes it not even simple by design.
What? UB is the simplest thing you can do when you just don't want to specify behavior. Any specified behavior can't be simpler that unspecified because it's just comparing nothing with something
Every part of rust is undefined because there is no spec. It’s whatever their compiler does.
Ferrocene has donated their specification to the project, so there absolutely is a specification now. What you can argue is that the memory model isn‘t fully defined, but it‘s almost certainly going to land somewhere around stacked borrows or tree borrows. Arguably C doesn‘t fare much better in that regard though as it doesn‘t even properly define its pointer provenance model either and Rust is much closer to defining its.
Oh something has changed in the last 6 months? glad they are making progress on the spec.
Note that, in compiler lingo, unspecified and undefined are two different things. C++ is specified to death, but full of undefined behavior (and also some unspecified behavior).
Rust is largely not specified, but aims to have no undefined behavior (outside of unsafe blocks).
I am aware but without a spec we don’t know which is which. You can’t say it has no undefined behavior because what happens is you try to specify it and find gaps or challenges.
In C undefined is used primarily when there is not a reliable and efficient mechanism for detecting a problem is happening. For example a C implementation may check every single invalid pointer deref, but more realistically it only detects only extreme out of range. So it’s undefined what happens.
> I am aware but without a spec we don’t know which is which.
I don't think I fully agree with this. A more accurate statement might be that "without a spec we don't always know which is which". You obviously don't need a spec to pin down at least some of a language's behavior, and even then the presence of a spec doesn't necessarily mean that you can answer arbitrary questions about what behavior is intended (c.f., various defect reports in the C/C++ spec asking clarifying questions, pointing out holes/deficiencies, or even admitting that certain behavior is not intended but being unsure about how to forbid it)
Good point.
That being said, at least in C++, undefined has been used largely as a joker for compiler optimizations. In Rust, if my memory serves, having the same code produce different results depending on the optimization level would be considered a pretty serious bug. In C++, it's par for the course.
Yep, love the simplicity of the strict aliasing rule.
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.
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.
The title is a bit of a misnomer. Rust will become mandatory in the build system, not mandatory for future patches.
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.
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.
> Introducing Rust is impossible for some platforms and hard for others.
Please could someone elaborate on this.
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.
How does this help me as a user of git?
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.
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?).
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?
"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.
Will they introduce Ada and announce that it will become mandatory
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
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.
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?
Curious what this means for libgit2.
Ideally upstream git would become better as a library as part of being rewritten in Rust.
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.
Maybe rewrite or create a new SCM called `grit`, etc
As long as binary sizes don't explode...
what's a 'test balloon'?
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
See also: https://github.com/GitoxideLabs/gitoxide which is a full rewrite of git in Rust.
mandatorty: best new word of 2025
[flagged]
bruh what is that goofy ass capcha protection??