25 ms·

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

335 points by WhyNotHugo 1y ago

politelemon 1y ago
> Introducing Rust is impossible for some platforms and hard for others. Please could someone elaborate on this.
- ahdanggit 1y ago
  Rust doesn't support as many CPU architectures as C does (SH4 for example, though there's likely many more better examples.) This might make a much more interesting case for GOT than before https://www.gameoftrees.org/ https://www.gameoftrees.org/
  - 1oooqooq 1y ago
    got is a waste of time, imo. they could just port the multiprocess pledge stuff to git (and benefit linux too with namespaces) then all the userfacing changes (i.e. work on git bare instrad of wc) I've been doing for the last decade with a couple lines on my gitconfig file.
    - ahdanggit 1y ago
      Rust doesn't run on all of their platforms so this is a good example of where git may not be viable for OpenBSD long-term (if they were to switch from CVS one day, which is a big IF)
- DarkNova6 1y ago
  My understanding: As Rust is built on LLVM and not GCC, it is also limited to operating systems supporting LLVM. GCC simply supports more platforms.
  - JoshTriplett 1y ago
    Rust has a GCC backend as well, rustc_codegen_gcc. However, the NonStop platform just has a proprietary C compiler.
    - okanat 1y ago
      MSVC is also proprietary. However LLVM is supported by Microsoft. The developer of Nonstop is apparently not doing that.
- arccy 1y ago
  because the rust compiler just doesn't support some platforms (os / architecture combination)? RESF members tend to say it the other way around as in the platform doesn't support rust, but the reality is that it's the compiler that needs to support a platform, not the other way around.
  - JoshTriplett 1y ago
    Rust can't support a platform when that platform's vendors just provide a proprietary C compiler and nothing else (no LLVM, no GCC). Perhaps someone could reverse-engineer it, but ultimately a platform with zero support from any FOSS toolchain is unlikely to get Rust support anytime soon.
    - jen20 1y ago
      Furthermore, how could it without the donation of hardware, licenses and so forth?! This is a problem entirely of the proprietary platforms making, and it should be their customers problem for having made a poor decision.
      - kmeisthax 1y ago
        HPE's customers are big-pocketed enough that they absolutely could manage a Rust port themselves, or pay HPE however much money they need to get them to do it if they're going to play games with ABI documentation. NonStop isn't some kind of weird hobbyist or retrocomputing platform. Actually, I'm surprised HPE doesn't already ship a Rust fork, given how NonStop is supposed to be a "reliable" OS...
    - kazinator 1y ago
      Reverse that: "C can't support a platform when that platform's vendors just provide a proprietary Rust compiler and nothing else".
      - Yoric 1y ago
        Seems to me that that is equally true and doesn't remove any validity from the argument.
- whalee 1y ago
  See this page [1], particularly the 'Tier 3' platforms. [1] https://doc.rust-lang.org/beta/rustc/platform-support.html https://doc.rust-lang.org/beta/rustc/platform-support.html
  - Alifatisk 1y ago
    More precise link https://doc.rust-lang.org/beta/rustc/platform-support.html#tier-3 https://doc.rust-lang.org/beta/rustc/platform-support.html#t...
  - bbor 1y ago
    Thanks for the specifics, really fascinating list! I'm sure I'm being a bit flippant, but it's pretty funny that a list including the Playstation 1, N64, and Apple Watches is in the same conversation as systems that need to compile git from source. Anyone know of anything on that list with more than a thousand SWE-coded users? Presumably there's at least one or two for those in the know?
    - whalee 1y ago
      I don't think the concern is whether a user can compile git from source on said platform, but rather whether the rust standard lib is well supported on said platform, which is required for cross compiling.
    - loeg 1y ago
      In practice, the only systems any significant number of people care about running Git on are arm64 and x86-64, and those are very well supported.
    - 3036e4 1y ago
      What I like about seeing a project support a long list of totally irrelevant old obscure platforms (like Free Pascal does, and probably GCC) is that it gives some hope that they will support some future obscure platform that I may care about. It shows a sign of good engineering culture. If a project supports only 64-bit arm+x86 on the three currently most popular operating systems that is a red flag for future compatibility risks.
- jmillikin 1y ago
  There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/ https://lwn.net/Articles/998115/
  - MangoToupe 1y ago
    How is this git's concern?
    - kazinator 1y ago
      Git's main concern should, of course, be getting Rust in, in some shape or form.
    - StopDisinfo910 1y ago
      They enjoy being portable and like things to stay that way so when they introduce a new toolchain dependency which will make it harder for some people to compile git, they point it out in their change log?
      - MangoToupe 1y ago
        I don't think "NonStop" is a good gauge of portability. But, I wasn't arguing against noting changes in a changelog, I'm arguing against putting portability to abstruse platforms before quality.
        StopDisinfo910 1y ago
        I don’t think staying portable means you have to do concession on quality. That merely limit your ability to introduce less portable dependancies. But even then Git doesn’t mind losing some plateformes when they want to move forward on something.
  - antihero 1y ago
    Shouldn't these platforms work on getting Rust to support it rather than have our tools limited by what they can consume? https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs
- doctorpangloss 1y ago
  You’re chasing after the meaning of “impossible.” Easy. There’s two categories of developers: > I like programming > I program to make money If you belong to the second category - I’m going to be super charitable, it sounds like I’m not going to be charitable and I am, so keep reading - such as by being paid by a giant bank to make applications on Nonstop, there might be some policy that’s like “You have to vet all open source code that runs on the computer.” So in order to have Rust, on Nonstop, to build git, which this guy likes, he’d need to port llvm, which isn’t impossible. What’s impossible is to get llvm code reviewed by legal, or whatever, which they’re not going to do, they’re going to say “No. No llvm. HP who makes Nonstop can do it, and it can be their legal problem.” I’m not saying it’s impossible. The other guy is saying it’s impossible, and I’m trying to show how, in a Rube Goldberg way, it looks impossible to him. You and I like programming, and I’m sure we’re both gainfully employed, though probably not making as much money at guy, but he doesn’t like programming. You are allowed to mock someone’s sincerity if they’re part of a system that’s sort of nakedly about making lots of money. But if you just like programming, you’d never work for a bank, it’s really fucking boring, so basically nobody who likes programming would ever say porting Rust or whatever is impossible. Do you see? It’s tough because, the Jane Street people and the Two Sigma people, they’re literally kids, they’re nice people, and they haven’t been there for very long, they still like programming! They feel like they need to mook for the bank, when they could just say that living in New York and having cocktails every night is fun and sincere. So this forum has the same problem as the mailing list, where it sounds like it’s about one thing - being able to use fucking hashmaps in git - and it’s really about another - bankers. Everywhere they turn, the bankers run into people who make their lifestyle possible, whether it’s the git developers who volunteer their time or the parents of the baristas at the bars they’re going to paying the baristas’ rent - and the bankers keep hating on these people. And then they go and say, well everyone is the problem but me. They don’t get it yet.
  - eklavya 1y ago
    What are you on about?
- daurentius523 1y ago
  To put in simply. Linux systems: Any library is system library because otherwise there will be no real OS libraries or API. Rust: No ABI. = No (real) shared libraries. Debian: https://www.debian.org/releases/trixie/release-notes/issues.html#go-and-rust-based-packages https://www.debian.org/releases/trixie/release-notes/issues.... Me who wrote long, long comment and then accidentally pushed close tab shortcut. !!@@! I would recommend building some packages containing rust, especially on older hardware - and then realize that because of static linking you will need to rebuild it very very often - and don't forget that you are building clean. Because it is expected that you will use required shared libraries to make life easier. I think that rust people should maybe sometimes just consider - that rust if pushed in such way will be more hated than C. Maybe you should not try to deflect criticism about stable ABI and shared libraries - linux OSes REQUIRE IT - nobody will change OS architecture because you want it. And maybe we should be more conservative architecturally in especially most critical pieces of software architecture.
  - comex 1y ago
    Not especially relevant for Git which has never provided a shared library interface.
    - daurentius523 1y ago
      It gives rust hate from many people. And once someone hates language it sticks. Also add to that the rust zealots who behave like sometimes like political preachers. "We are future, you are backwards" - says every ideologue. But conveniently does not say "in direction I want". When rust started political fight instead of language one they should expect that every rust porting will become political quagmire. Also you are incorrect - because you are already making wrong assumption: > crates are not libraries "never provided a shared library interface" - it doesn't need to, it just need to USE library - distros will convert static one to shared one if that what is reasonable. Now we have to have C library connected by C headers to (in future) rust application. Sure this somehow works - at cost of memory safety. So someone WILL suggest using rust crate instead of C library, and the problem will inevitably pop up. You could only say it works correctly as platform stipulates if you did not use any rust crate, or used ones that only your app/lib uses, or trivial finished ones - and I do not see people use rust like that. Even then it is from most linux distributions perspective the distribution job to decide if it should be static or shared linked NOT app-developer. SSL is something that is prime example of would it best to be written in memory safe language, with safe headers, provided that language makes stable ABI connections, so we can update 0-day not waiting for app developer. Rust fails spectacularly at last point unless library uses C headers. But at least it seems that OpenSSL is dynamically loaded after start so they are not changing that too soon. When I decide to patch some library for my use case I may want to use such library in every instance in every program on the system. Rust crate makes this impossible - now I need to rebuild everything even if I could not reasonably touch ABI boundary in same C code. Ultimately I think many of linux rust critics see it correctly as company-first/app-centered/containerized/not developement-aware user language (i.e user who can patch software for their specific needs who actively want to inspect every dependency in ONE way), and they prefer the known pro-community/pro-distro/pro-user-developer C/C++ paradigm instead. (At least fact that many criticism start immediately when GPL project get BSD rust rewrite does point it to free-software/open-source i.e pro-community/pro-company schism) Many linux users especially developement-aware users just have enough of pip, cargo and every 'modern' stuff - they just want old good apt or pacman. Then you have people that think slow development and no revolutionary changes should be IT priority in modern times. Then you have people that do believe that any alternative should be better, easier and simpler than old stuff before it should be treated as even a alternative way. And then you have contrarians.
justinhj 1y ago
"Announce that Git 3.0 will make Rust a mandatory part of our build infrastructure." Sounds like it will be mandatory to use Rust to build all of Git. The title implies Rust itself will be mandatory.
- binary132 1y ago
  how is that not the same thing?
  - StopDisinfo910 1y ago
    One phrasing implies contributions will have to be in Rust, the other doesn’t. I was confused in the same way after reading the submission title. Mandating Rust would be a far more radical change.
    - binary132 1y ago
      I see. No, I understood it the way it is, as introducing it as a new hard dependency in git 3. I suppose it is a pilot for making it mandatory for contributions / incrementally replacing the existing code in the future, though.
      - ekidd 1y ago
        Git is pretty modular, and it already includes multiple languages. I guess that significant parts of it will remain in C for a long time, including incremental improvements to those parts. Though it wouldn't surprise me if some parts of git did become all-Rust over time.
  - wongarsu 1y ago
    You could read "Rust will become mandatory" as "all contributors will need to be able to code Rust" or even "all new code has to be written in Rust" or similar variations
    - 1y ago
ziml77 1y ago
Does anyone with insight into Git development know if we should care about this? Is this just a proposal out of nowhere from some rando or is this an idea that a good portion of Git contributors have wanted?
- ekidd 1y ago
  For whatever it might be worth... Looking at the comment thread, at least one person I recognize as a core maintainer seems to be acting as if this is an official plan that they've already agreed on the outline of, if not the exact timing. And they seem to acknowledge that this breaks some of the more obscure platforms out there.
  - ziml77 1y ago
    Interesting! I'd certainly say that's worth something. Definitely didn't expect it though given how poorly some people have reacted to Rust being introduced as an optional part of the Linux kernel.
    - JoshTriplett 1y ago
      It's a lot more understandable for developer tooling like Git to more quickly adopt newer system requirements. Something like the Linux kernel needs to be conservative because it's part of many people's bootstrapping process. rustc_codegen_gcc is close to becoming stable, and conversely the Linux kernel is dropping more esoteric architectures. Once the supported sets of architectures fully overlap, and once the Linux kernel no longer needs unstable (nightly-only) Rust features, it'd be more reasonable for Linux to depend on Rust for more than just optional drivers.
      - daft_pink 1y ago
        I would also say that it’s a lot easier to learn to write rust when you’re writing something that runs sequentially on a single core in userspace as opposed to something like the Linux kernel. Having dipped my toes in rust that seems very approachable. When you start doing async concurrency is when the learning curve becomes steep.
phkahler 1y ago
It's to a "test balloon" if you have a plan to mandate it and will be announcing that. Unless I suppose enough backlash will cause you to cancel the plan.
- saghm 1y ago
  It's literally a test of how people will react, so yes, finding out if people will react negatively would be exactly the point of doing the test in the first place. Would you prefer that they don't publicize what their follow-up plans would be to try to make it harder to criticize the plans? If you're against the plan, I'm pretty sure that's the exact type of feedback they're looking for, so it would make more sense to tell them that directly if it actually affects you rather than making a passive-aggressive comment they'll likely never read on an unrelated forum.
  - altairprime 1y ago
    If they’re running the project with a Linus-type approach, they won’t consider backlash to be interesting or relevant, unless it is accompanied by specific statements of impact. Generic examples for any language to explain why: > How dare you! I’m going to boycott git!! Self-identified as irrelevant (objector will not be using git); no reply necessary, expect a permaban. > I don’t want to install language X to build and run git. Most users do not build git from source. Since no case is made why this is relevant beyond personal preference, it will likely be ignored. > Adopting language X might inhibit community participation. This argument has almost certainly already been considered. Without a specific reason beyond the possibility, such unsupported objections will not lead to new considerations, especially if raised by someone who is not a regular contributor. > Language X isn’t fully-featured on platform Y. Response will depend on whether the Git project decides to support platform Y or not, whether the missing features are likely to affect Git uses, etc. Since no case is provided about platform Y’s usage, it’ll be up to the Git team to investigate (or not) before deciding > Language X will prevent Git from being deployed on platform Z, which affects W installations based on telemetry and recent package downloads, due to incompatibility Y. This would be guaranteed to be evaluated, but the outcome could be anywhere from “X will be dropped” to “Y will be patched” to “Z will not be supported”.
monkeyelite 1y ago
How does this help me as a user of git?
- cschep 1y ago
  My guess is that we (I am also a user of git) won't even notice.
  - johnisgood 1y ago
    I will leave this here for the future: $ ldd /usr/bin/git linux-vdso.so.1 (0x00007f69c2d64000) libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f69c2c81000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f69c2c67000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f69c2616000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f69c2d66000) $ ls -alh /usr/bin/git -rwxr-xr-x 1 root root 4.0M Aug 25 11:40 /usr/bin/git I did not measure but it does not take long on my old hardware to compile git from scratch either, for now.
    - cschep 1y ago
      Ok, I'll bite. While we are on Hacker News, this is still an enormously obtuse way to communicate. Are you saying that as users of git we will be negatively affected by deps being added and build times going up? Do you have evidence of that from past projects adding rust? Why not just say that??
      - johnisgood 1y ago
        No need to bite. :P We will see!
        AlexeyBelov 1y ago
        See what? Why are you vague-posting?
        1y ago
jmull 1y ago
I'm wondering what's on the horizon with git 3.0? From my (very limited) perspective, I just kind of thought git had settled in to 2.x and there wasn't any reason to break compatibility.
- turkishdelight 1y ago
  SHA-256 will become the default hash.
- stebalien 1y ago
  See https://git-scm.com/docs/BreakingChanges#_git_3_0 https://git-scm.com/docs/BreakingChanges#_git_3_0
syngrog66 1y ago
mandatorty: best new word of 2025
- maxbond 1y ago
  mandatorty (adj.): Simultaneously required and a civil offense. I need you to fill out this TPS report. Unfortunately it's mandatorty to fudge section 15A.
delusional 1y ago
It seems unwise, to me, to tie the life of a project as fundamental, and conceptually simple, as git to a compiler and runtime as complicated as rust. The beauty of the unsafety of C is partially that it's pretty easy to spin up a compiler on a new platform. The same cannot be said of Rust.
- loeg 1y ago
  Do you think any new, Git-relevant platform is going to gain C compiler support via anything other than Clang/LLVM?
  - bArray 1y ago
    In theory you should be able to use TCC to build git currently [1] [2]. If you have a lightweight system or you're building something experimental, it's a lot easier to get TCC up and running over GCC. I note that it supports arm, arm64, i386, riscv64 and x86_64. [1] https://bellard.org/tcc/ https://bellard.org/tcc/ [2] https://github.com/TinyCC/tinycc https://github.com/TinyCC/tinycc
    - loeg 1y ago
      > I note that it supports arm, arm64, i386, riscv64 and x86_64. But like, so does LLVM.
  - delusional 1y ago
    The nature considering the future is that our actions _now_ affect the answer _then_. If we tie our foundational tools to LLVM, then it's very unlikely a new platform can exists without support for it. If we don't tie ourselves to it, then it's more likely we can exist without it. It's not a matter of if LLVM will be supported. We ensure that by making it impossible not to be the case. It's a self fulfilling prophecy. I prefer to ask another question: "Is this useful". Would it be useful, if we were to spin up a different platform in the future, to be able to do so without LLVM. I think the answer to that is a resounding yes. That doesn't leave rust stranded. A _useful_ path for rust to pursue would be to defined a minimal subset of the compiler that you'd need to implement to compile all valid programs. The type checker, borrow checker, unused variable tracker, and all other safety features should be optional extensions to a core of a minimal portable compiler. This way, the rust compiler could feasibly be as simple as the simplest C compiler while still supporting all the complicated validation on platforms with deep support.
addcn 1y ago
Feel like there’s a ton of interesting things ahead for SCM — want to see more of those proposals. For example…had to build my own tool to extend git blame and track the AI generated code in our repository and save prompts: https://github.com/acunniffe/git-ai https://github.com/acunniffe/git-ai
- deleted 1y ago
  [deleted]
bArray 1y ago
Maybe I'm just old and moany, and I need to step aside for bigger and better things such as Rust. But. Now rather than needing to understand just C to work on Git/kernel, you now need to also know Rust. The toolchain complexity is increasing, and the mix of these languages increases the barrier to entry. I'm highly invested into Git, having learned the tooling and having a significant number of projects constructed within it. I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git.
- GrayShade 1y ago
  > I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git. And they will keep working because the repository format isn't affected by the language git is written in.
  - account42 1y ago
    Believing that this will be the case forever is naive. At some point there will be extensions. Then those extensions will become all but mandatory for interacting with other git users.
- IshKebab 1y ago
  > I'm just old and moany, and I need to step aside for bigger and better things such as Rust. You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry. In any case Rust is usually easier than C (excluding buggy C which is very easy to write), and certainly easier than actually learning the Git or Linux codebases.
  - hedgehog 1y ago
    I think it is often under appreciated by people who haven't worked in security how hard high quality C is in practice.
    - 1y ago
gedy 1y ago
Maybe rewrite or create a new SCM called `grit`, etc
bgwalter 1y ago
[flagged]
- lucasoshiro 1y ago
  > Normal users who have to install the Rust toolchain to build a previously simple piece of software do not count. "Normal users" would just install the same way they already do today without bothering about the toolchain. "Normal users" who want to build by theirselves probably won't find it too difficult. Given the size of Git it's incredibly easy to build: just install the dependencies and run `make`.
OCTAGRAM 1y ago
Will they introduce Ada and announce that it will become mandatory
- johnisgood 1y ago
  Only if safety really is their concern... so no.
riedel 1y ago
Given that rust only works on e.g. cygwin recently (and still does not build many crates: i try to compile jujutsu and failed), this is a big blow to portability IMHO. While I try to like rust, I think making it mandatory for builds of essential tools like git is really too early.
- GoblinSlayer 1y ago
  Git works only on cygwin too?
  - Kwpolska 1y ago
    No, it doesn't. OP meant that the Rust support on Cygwin is bad; it is better with the native Windows API.
    - IshKebab 1y ago
      Cygwin is an ugly hack anyway.
    - sunshowers 1y ago
      I don't quite understand. Why use a janky, lossy Linux emulation layer when you can just target Windows natively?
      - GoblinSlayer 1y ago
        For some reason git for windows is a cygwin build.
        1718627440 1y ago
        Because git expects a POSIX API and POSIX tools and also POSIX behaviour like symlinks and line-endings to do its job.
        lazka 1y ago
        It's a native build. Only various tools it is shipped with are cygwin builds, like bash etc.
secondcoming 1y ago
what's a 'test balloon'?
- petiepooo 1y ago
  A viral commit
- oreally 1y ago
  Ironically it's original use was in political* parlance. From wiki it's "information sent out to the media in order to observe the reaction of an audience. It is used by companies sending out press releases to judge customer reaction, and by politicians who deliberately leak information on a policy change." Yup I have no doubt that there's a Rust 'evangelist' group somewhere aiming for inorganic growth of the language.
  - metaltyphoon 1y ago
    > Yup I have no doubt that there's a Rust 'evangelist' group somewhere aiming for inorganic growth of the language. So anything using Rust now must be the ‘evangelists’ work right?
sebtron 1y ago
I am curious, what is the reason behind introducing Rust in Git? I am not familiar with Git development, I am just a user. But my impression is that it is already a complete tool that won't require much new code to be written. Fixes and improvements here and there, sure, but that does not seem like a good reason to start using a new language. In contrast, I understand why adding it to e.g. Linux development makes sense, since new drivers will always need to be written. Can anyone explain what I might be missing?
- jcrben 1y ago
  C is unsafe.
  - sebtron 1y ago
    I honestly can't tell if this is meant as serious reply to my question (in that case: let's say I agree that Rust is 100% better than C; my question still stands) or as a way to mock Rust people's eagerness to rewrite everything in Rust (in that case: are you sure this is the reason behind this? They are not rewriting Git from scratch...)
    - jcrben 1y ago
      As a user, you may not be aware that C makes it relatively easy to create https://en.m.wikipedia.org/wiki/Buffer_overflow 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.
      - msm_ 1y ago
        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.
        happytoexplain 1y ago
Ericson2314 1y ago
Curious what this means for libgit2. Ideally upstream git would become better as a library as part of being rewritten in Rust.
- egorfine 1y ago
  [flagged]
saltcured 1y ago
Is this a bit of chickens coming home to roost as far as developer culture forgetting how to work with cross-compiling toolchains? When I started my career, it was common understanding that the developer may be manipulating sourcecode on a different system and/or platform than where it will be executed. Our source control, editing, compilation, and execution was understood to happen in different computational spaces, with possible copy/staging steps in between. You were doing something very naive if you assumed you could execute the built program on the same system where the sourcecode files existed and the editor/IDE was running. This was a significant fraction of the build rules we used to manage. E.g. configuration steps had to understand that the target platform being measured/characterized is not the same as the platform executing the build tools. And to actually execute a built object may require remote file copies and remote program invocation.
- bloppe 1y ago
  Actually, the Rust toolchain makes cross-compiling way easier than any other fully-compiled language I've ever used. There are like 100 different platforms you can target by just setting the `--target` flag, and they all pretty much just work on any host platform. Sounds like the real issue is that some Git developers have ancient, rigid requirements for their own development machines.
  - cogman10 1y ago
    A good example of it is how easy it is to do WASM from rust. WASM is even one of the harder platforms to target with rust.
  - saltcured 1y ago
    Others have said Rust does not support NonStop. But, my point is you shouldn't even have to cross-compile Git to a platform like NonStop in order to develop NonStop apps. So the portability of Rust shouldn't even matter here. The app developer should be able to run their Git commands on a supported platform and cross-compile their own app to NonStop.
    - 1y ago
taminka 1y ago
bruh what is that goofy ass capcha protection??
- AnyTimeTraveler 1y ago
  That's Anubis. A proof-of-work based protection against AI-Crawlers. https://github.com/TecharoHQ/anubis https://github.com/TecharoHQ/anubis
nayak 1y ago
This series was in response to another thread [1] which wanted to make rust mandatory in an upcoming release. The authors proposal was to instead take the middle ground and use rust as an optional dependency until a later point of time where it becomes mandatory. The later point of time was decided based on when rust support lands in gcc, which would make things smoother, since platforms which support gcc would also be included. [1]: https://lore.kernel.org/git/pull.1980.git.git.1752784344.gitgitgadget@gmail.com/#t https://lore.kernel.org/git/pull.1980.git.git.1752784344.git...
- djha-skin 1y ago
  The GCC compiler collection has been hit and miss though. Nobody uses gcj for example. I sort of doubt that they'll be able to implement a good compiler for a language that doesn't even have a standard without that implementation going wildly out of date in the future, just like what happened with Java.
  - aw1621107 1y ago
    There's two different methods by which Rust support can be added to GCC: adding a Rust frontend to GCC and adding a GCC backend to the Rust compiler (rustc_codegen_gcc). The latter approach would not be (as?) susceptible to implementation divergence as an independent frontend.
    - nextaccountic 1y ago
      yep, if git is content with rustc_codegen_gcc, then it's very doable they can require rust in the next few years
    - 1718627440 1y ago
      I hope for the former since then the functionality might become available as attributes in C too.
      - aw1621107 1y ago
deleted 1y ago
[deleted]
cozzyd 1y ago
As long as binary sizes don't explode...
djha-skin 1y ago
Rust suffers from the same problems that functional programming languages suffer from: deep learning curve and high complexity. The high complexity is intended to push more runtime errors back to compile time, but boy does that mean the language pays for it. Rust is a tire fire of complexity. For these reasons I believe it is not a good idea. The kernel also sort of rejected Rust. The kernel is complex enough without adding a Haskell type system and a lisp-level macro system capable of obfuscating what code calls what code. serde code is so hard to spelunk for this reason. Contrast this with Go's Unmarshall, much easier to follow.
- nixosbestos 1y ago
  I was going to roll my eyes at "Rust is a tire fire of complexity". Because it's not. Especially compared to C++. But then you just go on to outright lie in your second paragraph.
  - nixosbestos 1y ago
    Dear Rust haters, lying about Rust in the Linux kernel is not effective for your cause, and in fact just makes it further look like you're throwing a tantrum. Downvoting me doesn't change the fact that more and more Rust is merged into the kernel, new, serious drivers are being written in Rust. It also doesn't change Firefox, Chrome, Microsoft, the US Government and others are recommending and writing new code in Rust. It's over, qq. It's absurd. I really wish I could find the Lobsters comment the other day from someone that broke down the incredible list of nuanced, spec-level detail you needed to know about C++ to actually use it at scale in large projects. It's laughably, absurdly complex compared to Rust in huge code bases.
- righthand 1y ago
  I actually think Rust is pretty easy to pick up for anyone that’s written Typescript and can use their linter to understand references and unwrapping a Result and catching an error. Beyond that, Rust has pretty forgiving syntax. No Linux did not reject Rust from the kernel.
- Yoric 1y ago
djha-skin 1y ago
The title is a bit of a misnomer. Rust will become mandatory in the build system, not mandatory for future patches.
- dang 1y ago
  Thanks! I've added that to the title above. If it's somehow inaccurate, we can change it again.
- gbnbv 1y ago
  What does that mean? Is it mandatory for building the build system or also for building the application?
  - heavyset_go 1y ago
    If you want to build the project, you will need a Rust compiler in your toolchain.
drnick1 1y ago
What's the point of trying to introduce Rust everywhere? Git is a mature piece of software and I doubt a lot of new code needs to be written. Also, Rust is very complex relative to C. If you really need classes, templates, etc, you can stick to C++ 98 and get something that is still clean and understandable relative to recent C++ standards and Rust.
- Too 1y ago
  > I doubt a lot of new code needs to be written I bet someone could have easily said the same thing a year ago or even 5 years ago. It's easy to forget the progress and there are a lot of things happening under the hood that are not obvious to casual users. Just take a look at the git log of the git repository itself. It has a steady rate of close to 100 commits per week for the past year. That says nothing of potential new features either. There is so much more to unlock in the VCS space, look at new tools like jj for example. Additionally, security landscape is getting more aggressive every day, keeping up with and being proactive against vulnerabilities will be needed more than today.
- School-Cotton 1y ago
  Rust has neither classes nor templates.
mimd 1y ago
I suggest waiting till the gcc side matures, with the minimum of a working gcc frontend for a non optional dependency. Optional dependencies with gcc_codegen might be okay. Git is pretty core to a lot of projects, and this change is risky, it's on a fairly short time frame to make it a core dep (6 months?).
nicoburns 1y ago
See also: https://github.com/GitoxideLabs/gitoxide https://github.com/GitoxideLabs/gitoxide which is a full rewrite of git in Rust.
- johnisgood 1y ago
  So, I have been complaining about how Rust projects have over hundreds and often thousands of dependencies. I gave this random Rust project a try. The results: Building [ ] 5/338: libc(build), proc-macro2(build) No thank you. Can you Rust people stop doing this? Hundreds of dependencies is the norm in Rust culture. I swear humans will never learn.
  - nicoburns 1y ago
    You can't really count "dependencies" in the Rust ecosystem by counting the number of crates. Gix itself has 65 crates but if you depended on it that would only really be one dependency. Your average Rust project will have more dependencies than your average C project, but it's not as dramatic as you might think.
    - johnisgood 1y ago
      Okay, but when I compile a Rust project and I see "0/2000" that gets pulled and built, I panic. > You can't really count "dependencies" in the Rust ecosystem by counting the number of crates. Can you elaborate as to why? I have much less packages (many of them are not even C libraries) installed by my operating system than what a typical Rust project pulls and builds.
      - nicoburns 1y ago
        > Can you elaborate as to why? Because Rust crates are the "compilation unit" as well as the "publishing unit". So if you are a largish library then you'll likely want to split your library across several crates (to enable things like parallelism in the build process). Then you'll end up with several crates from the same git repo, same developers, that will show up individually in the raw crate count. It's not a perfect analogy (because crates are generally multiple files), but imagine if in a C project you counted each header file as a separate dependency, it's kinda like that. --- There is a culture in the Rust ecosystem of preferring shared crates for functionality rather than writing custom versions of data structures or putting too much in the standard library (although it's not nearly so extreme as in the JavaScript ecosystem). And I do think the concern around supply-chain attacks is not entirely unwarranted. But at the same time, the quality standards for these crates are excellent, and in practice many of them are maintained by a relatively small group of people that as a Rust developer I know and trust.
leoh 1y ago
Would anyone know how to view the patch in question (as opposed to the `--stat`-like view in the thread) without pulling down source or Googling around?
hoppp 1y ago
So they are adding technical debt to everything? Its either in the form of C code that will need to be rewritten in rust Or rust code that the C devs now will need to learn to understand the entire system Doesn't matter which way you look at it

335 points by WhyNotHugo 1y ago

politelemon 1y ago

> Introducing Rust is impossible for some platforms and hard for others. Please could someone elaborate on this.

ahdanggit 1y ago
Rust doesn't support as many CPU architectures as C does (SH4 for example, though there's likely many more better examples.) This might make a much more interesting case for GOT than before https://www.gameoftrees.org/ https://www.gameoftrees.org/
- 1oooqooq 1y ago
  got is a waste of time, imo. they could just port the multiprocess pledge stuff to git (and benefit linux too with namespaces) then all the userfacing changes (i.e. work on git bare instrad of wc) I've been doing for the last decade with a couple lines on my gitconfig file.
  - ahdanggit 1y ago
    Rust doesn't run on all of their platforms so this is a good example of where git may not be viable for OpenBSD long-term (if they were to switch from CVS one day, which is a big IF)
DarkNova6 1y ago
My understanding: As Rust is built on LLVM and not GCC, it is also limited to operating systems supporting LLVM. GCC simply supports more platforms.
- JoshTriplett 1y ago
  Rust has a GCC backend as well, rustc_codegen_gcc. However, the NonStop platform just has a proprietary C compiler.
  - okanat 1y ago
    MSVC is also proprietary. However LLVM is supported by Microsoft. The developer of Nonstop is apparently not doing that.
arccy 1y ago
because the rust compiler just doesn't support some platforms (os / architecture combination)? RESF members tend to say it the other way around as in the platform doesn't support rust, but the reality is that it's the compiler that needs to support a platform, not the other way around.
- JoshTriplett 1y ago
  Rust can't support a platform when that platform's vendors just provide a proprietary C compiler and nothing else (no LLVM, no GCC). Perhaps someone could reverse-engineer it, but ultimately a platform with zero support from any FOSS toolchain is unlikely to get Rust support anytime soon.
  - jen20 1y ago
    Furthermore, how could it without the donation of hardware, licenses and so forth?! This is a problem entirely of the proprietary platforms making, and it should be their customers problem for having made a poor decision.
    - kmeisthax 1y ago
      HPE's customers are big-pocketed enough that they absolutely could manage a Rust port themselves, or pay HPE however much money they need to get them to do it if they're going to play games with ABI documentation. NonStop isn't some kind of weird hobbyist or retrocomputing platform. Actually, I'm surprised HPE doesn't already ship a Rust fork, given how NonStop is supposed to be a "reliable" OS...
  - kazinator 1y ago
    Reverse that: "C can't support a platform when that platform's vendors just provide a proprietary Rust compiler and nothing else".
    - Yoric 1y ago
      Seems to me that that is equally true and doesn't remove any validity from the argument.
whalee 1y ago
See this page [1], particularly the 'Tier 3' platforms. [1] https://doc.rust-lang.org/beta/rustc/platform-support.html https://doc.rust-lang.org/beta/rustc/platform-support.html
- Alifatisk 1y ago
  More precise link https://doc.rust-lang.org/beta/rustc/platform-support.html#tier-3 https://doc.rust-lang.org/beta/rustc/platform-support.html#t...
- bbor 1y ago
  Thanks for the specifics, really fascinating list! I'm sure I'm being a bit flippant, but it's pretty funny that a list including the Playstation 1, N64, and Apple Watches is in the same conversation as systems that need to compile git from source. Anyone know of anything on that list with more than a thousand SWE-coded users? Presumably there's at least one or two for those in the know?
  - whalee 1y ago
    I don't think the concern is whether a user can compile git from source on said platform, but rather whether the rust standard lib is well supported on said platform, which is required for cross compiling.
  - loeg 1y ago
    In practice, the only systems any significant number of people care about running Git on are arm64 and x86-64, and those are very well supported.
  - 3036e4 1y ago
    What I like about seeing a project support a long list of totally irrelevant old obscure platforms (like Free Pascal does, and probably GCC) is that it gives some hope that they will support some future obscure platform that I may care about. It shows a sign of good engineering culture. If a project supports only 64-bit arm+x86 on the three currently most popular operating systems that is a red flag for future compatibility risks.
jmillikin 1y ago
There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/ https://lwn.net/Articles/998115/
- MangoToupe 1y ago
  How is this git's concern?
  - kazinator 1y ago
    Git's main concern should, of course, be getting Rust in, in some shape or form.
  - StopDisinfo910 1y ago
    They enjoy being portable and like things to stay that way so when they introduce a new toolchain dependency which will make it harder for some people to compile git, they point it out in their change log?
    - MangoToupe 1y ago
      I don't think "NonStop" is a good gauge of portability. But, I wasn't arguing against noting changes in a changelog, I'm arguing against putting portability to abstruse platforms before quality.
      - StopDisinfo910 1y ago
        I don’t think staying portable means you have to do concession on quality. That merely limit your ability to introduce less portable dependancies. But even then Git doesn’t mind losing some plateformes when they want to move forward on something.
- antihero 1y ago
  Shouldn't these platforms work on getting Rust to support it rather than have our tools limited by what they can consume? https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs
doctorpangloss 1y ago
You’re chasing after the meaning of “impossible.” Easy. There’s two categories of developers: > I like programming > I program to make money If you belong to the second category - I’m going to be super charitable, it sounds like I’m not going to be charitable and I am, so keep reading - such as by being paid by a giant bank to make applications on Nonstop, there might be some policy that’s like “You have to vet all open source code that runs on the computer.” So in order to have Rust, on Nonstop, to build git, which this guy likes, he’d need to port llvm, which isn’t impossible. What’s impossible is to get llvm code reviewed by legal, or whatever, which they’re not going to do, they’re going to say “No. No llvm. HP who makes Nonstop can do it, and it can be their legal problem.” I’m not saying it’s impossible. The other guy is saying it’s impossible, and I’m trying to show how, in a Rube Goldberg way, it looks impossible to him. You and I like programming, and I’m sure we’re both gainfully employed, though probably not making as much money at guy, but he doesn’t like programming. You are allowed to mock someone’s sincerity if they’re part of a system that’s sort of nakedly about making lots of money. But if you just like programming, you’d never work for a bank, it’s really fucking boring, so basically nobody who likes programming would ever say porting Rust or whatever is impossible. Do you see? It’s tough because, the Jane Street people and the Two Sigma people, they’re literally kids, they’re nice people, and they haven’t been there for very long, they still like programming! They feel like they need to mook for the bank, when they could just say that living in New York and having cocktails every night is fun and sincere. So this forum has the same problem as the mailing list, where it sounds like it’s about one thing - being able to use fucking hashmaps in git - and it’s really about another - bankers. Everywhere they turn, the bankers run into people who make their lifestyle possible, whether it’s the git developers who volunteer their time or the parents of the baristas at the bars they’re going to paying the baristas’ rent - and the bankers keep hating on these people. And then they go and say, well everyone is the problem but me. They don’t get it yet.
- eklavya 1y ago
  What are you on about?
daurentius523 1y ago
To put in simply. Linux systems: Any library is system library because otherwise there will be no real OS libraries or API. Rust: No ABI. = No (real) shared libraries. Debian: https://www.debian.org/releases/trixie/release-notes/issues.html#go-and-rust-based-packages https://www.debian.org/releases/trixie/release-notes/issues.... Me who wrote long, long comment and then accidentally pushed close tab shortcut. !!@@! I would recommend building some packages containing rust, especially on older hardware - and then realize that because of static linking you will need to rebuild it very very often - and don't forget that you are building clean. Because it is expected that you will use required shared libraries to make life easier. I think that rust people should maybe sometimes just consider - that rust if pushed in such way will be more hated than C. Maybe you should not try to deflect criticism about stable ABI and shared libraries - linux OSes REQUIRE IT - nobody will change OS architecture because you want it. And maybe we should be more conservative architecturally in especially most critical pieces of software architecture.
- comex 1y ago
  Not especially relevant for Git which has never provided a shared library interface.
  - daurentius523 1y ago
    It gives rust hate from many people. And once someone hates language it sticks. Also add to that the rust zealots who behave like sometimes like political preachers. "We are future, you are backwards" - says every ideologue. But conveniently does not say "in direction I want". When rust started political fight instead of language one they should expect that every rust porting will become political quagmire. Also you are incorrect - because you are already making wrong assumption: > crates are not libraries "never provided a shared library interface" - it doesn't need to, it just need to USE library - distros will convert static one to shared one if that what is reasonable. Now we have to have C library connected by C headers to (in future) rust application. Sure this somehow works - at cost of memory safety. So someone WILL suggest using rust crate instead of C library, and the problem will inevitably pop up. You could only say it works correctly as platform stipulates if you did not use any rust crate, or used ones that only your app/lib uses, or trivial finished ones - and I do not see people use rust like that. Even then it is from most linux distributions perspective the distribution job to decide if it should be static or shared linked NOT app-developer. SSL is something that is prime example of would it best to be written in memory safe language, with safe headers, provided that language makes stable ABI connections, so we can update 0-day not waiting for app developer. Rust fails spectacularly at last point unless library uses C headers. But at least it seems that OpenSSL is dynamically loaded after start so they are not changing that too soon. When I decide to patch some library for my use case I may want to use such library in every instance in every program on the system. Rust crate makes this impossible - now I need to rebuild everything even if I could not reasonably touch ABI boundary in same C code. Ultimately I think many of linux rust critics see it correctly as company-first/app-centered/containerized/not developement-aware user language (i.e user who can patch software for their specific needs who actively want to inspect every dependency in ONE way), and they prefer the known pro-community/pro-distro/pro-user-developer C/C++ paradigm instead. (At least fact that many criticism start immediately when GPL project get BSD rust rewrite does point it to free-software/open-source i.e pro-community/pro-company schism) Many linux users especially developement-aware users just have enough of pip, cargo and every 'modern' stuff - they just want old good apt or pacman. Then you have people that think slow development and no revolutionary changes should be IT priority in modern times. Then you have people that do believe that any alternative should be better, easier and simpler than old stuff before it should be treated as even a alternative way. And then you have contrarians.

justinhj 1y ago

"Announce that Git 3.0 will make Rust a mandatory part of our build infrastructure." Sounds like it will be mandatory to use Rust to build all of Git. The title implies Rust itself will be mandatory.

binary132 1y ago
how is that not the same thing?
- StopDisinfo910 1y ago
  One phrasing implies contributions will have to be in Rust, the other doesn’t. I was confused in the same way after reading the submission title. Mandating Rust would be a far more radical change.
  - binary132 1y ago
    I see. No, I understood it the way it is, as introducing it as a new hard dependency in git 3. I suppose it is a pilot for making it mandatory for contributions / incrementally replacing the existing code in the future, though.
    - ekidd 1y ago
      Git is pretty modular, and it already includes multiple languages. I guess that significant parts of it will remain in C for a long time, including incremental improvements to those parts. Though it wouldn't surprise me if some parts of git did become all-Rust over time.
- wongarsu 1y ago
  You could read "Rust will become mandatory" as "all contributors will need to be able to code Rust" or even "all new code has to be written in Rust" or similar variations
  - 1y ago

ziml77 1y ago

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

ekidd 1y ago
For whatever it might be worth... Looking at the comment thread, at least one person I recognize as a core maintainer seems to be acting as if this is an official plan that they've already agreed on the outline of, if not the exact timing. And they seem to acknowledge that this breaks some of the more obscure platforms out there.
- ziml77 1y ago
  Interesting! I'd certainly say that's worth something. Definitely didn't expect it though given how poorly some people have reacted to Rust being introduced as an optional part of the Linux kernel.
  - JoshTriplett 1y ago
    It's a lot more understandable for developer tooling like Git to more quickly adopt newer system requirements. Something like the Linux kernel needs to be conservative because it's part of many people's bootstrapping process. rustc_codegen_gcc is close to becoming stable, and conversely the Linux kernel is dropping more esoteric architectures. Once the supported sets of architectures fully overlap, and once the Linux kernel no longer needs unstable (nightly-only) Rust features, it'd be more reasonable for Linux to depend on Rust for more than just optional drivers.
    - daft_pink 1y ago
      I would also say that it’s a lot easier to learn to write rust when you’re writing something that runs sequentially on a single core in userspace as opposed to something like the Linux kernel. Having dipped my toes in rust that seems very approachable. When you start doing async concurrency is when the learning curve becomes steep.

phkahler 1y ago

It's to a "test balloon" if you have a plan to mandate it and will be announcing that. Unless I suppose enough backlash will cause you to cancel the plan.

saghm 1y ago
It's literally a test of how people will react, so yes, finding out if people will react negatively would be exactly the point of doing the test in the first place. Would you prefer that they don't publicize what their follow-up plans would be to try to make it harder to criticize the plans? If you're against the plan, I'm pretty sure that's the exact type of feedback they're looking for, so it would make more sense to tell them that directly if it actually affects you rather than making a passive-aggressive comment they'll likely never read on an unrelated forum.
- altairprime 1y ago
  If they’re running the project with a Linus-type approach, they won’t consider backlash to be interesting or relevant, unless it is accompanied by specific statements of impact. Generic examples for any language to explain why: > How dare you! I’m going to boycott git!! Self-identified as irrelevant (objector will not be using git); no reply necessary, expect a permaban. > I don’t want to install language X to build and run git. Most users do not build git from source. Since no case is made why this is relevant beyond personal preference, it will likely be ignored. > Adopting language X might inhibit community participation. This argument has almost certainly already been considered. Without a specific reason beyond the possibility, such unsupported objections will not lead to new considerations, especially if raised by someone who is not a regular contributor. > Language X isn’t fully-featured on platform Y. Response will depend on whether the Git project decides to support platform Y or not, whether the missing features are likely to affect Git uses, etc. Since no case is provided about platform Y’s usage, it’ll be up to the Git team to investigate (or not) before deciding > Language X will prevent Git from being deployed on platform Z, which affects W installations based on telemetry and recent package downloads, due to incompatibility Y. This would be guaranteed to be evaluated, but the outcome could be anywhere from “X will be dropped” to “Y will be patched” to “Z will not be supported”.

monkeyelite 1y ago

How does this help me as a user of git?

cschep 1y ago
My guess is that we (I am also a user of git) won't even notice.
- johnisgood 1y ago
  I will leave this here for the future: $ ldd /usr/bin/git linux-vdso.so.1 (0x00007f69c2d64000) libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f69c2c81000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f69c2c67000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f69c2616000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f69c2d66000) $ ls -alh /usr/bin/git -rwxr-xr-x 1 root root 4.0M Aug 25 11:40 /usr/bin/git I did not measure but it does not take long on my old hardware to compile git from scratch either, for now.
  - cschep 1y ago
    Ok, I'll bite. While we are on Hacker News, this is still an enormously obtuse way to communicate. Are you saying that as users of git we will be negatively affected by deps being added and build times going up? Do you have evidence of that from past projects adding rust? Why not just say that??
    - johnisgood 1y ago
      No need to bite. :P We will see!
      - AlexeyBelov 1y ago
        See what? Why are you vague-posting?
        1y ago

jmull 1y ago

I'm wondering what's on the horizon with git 3.0? From my (very limited) perspective, I just kind of thought git had settled in to 2.x and there wasn't any reason to break compatibility.

turkishdelight 1y ago
SHA-256 will become the default hash.
stebalien 1y ago
See https://git-scm.com/docs/BreakingChanges#_git_3_0 https://git-scm.com/docs/BreakingChanges#_git_3_0

syngrog66 1y ago

mandatorty: best new word of 2025

maxbond 1y ago
mandatorty (adj.): Simultaneously required and a civil offense. I need you to fill out this TPS report. Unfortunately it's mandatorty to fudge section 15A.

delusional 1y ago

It seems unwise, to me, to tie the life of a project as fundamental, and conceptually simple, as git to a compiler and runtime as complicated as rust. The beauty of the unsafety of C is partially that it's pretty easy to spin up a compiler on a new platform. The same cannot be said of Rust.

loeg 1y ago
Do you think any new, Git-relevant platform is going to gain C compiler support via anything other than Clang/LLVM?
- bArray 1y ago
  In theory you should be able to use TCC to build git currently [1] [2]. If you have a lightweight system or you're building something experimental, it's a lot easier to get TCC up and running over GCC. I note that it supports arm, arm64, i386, riscv64 and x86_64. [1] https://bellard.org/tcc/ https://bellard.org/tcc/ [2] https://github.com/TinyCC/tinycc https://github.com/TinyCC/tinycc
  - loeg 1y ago
    > I note that it supports arm, arm64, i386, riscv64 and x86_64. But like, so does LLVM.
- delusional 1y ago
  The nature considering the future is that our actions _now_ affect the answer _then_. If we tie our foundational tools to LLVM, then it's very unlikely a new platform can exists without support for it. If we don't tie ourselves to it, then it's more likely we can exist without it. It's not a matter of if LLVM will be supported. We ensure that by making it impossible not to be the case. It's a self fulfilling prophecy. I prefer to ask another question: "Is this useful". Would it be useful, if we were to spin up a different platform in the future, to be able to do so without LLVM. I think the answer to that is a resounding yes. That doesn't leave rust stranded. A _useful_ path for rust to pursue would be to defined a minimal subset of the compiler that you'd need to implement to compile all valid programs. The type checker, borrow checker, unused variable tracker, and all other safety features should be optional extensions to a core of a minimal portable compiler. This way, the rust compiler could feasibly be as simple as the simplest C compiler while still supporting all the complicated validation on platforms with deep support.

addcn 1y ago

Feel like there’s a ton of interesting things ahead for SCM — want to see more of those proposals. For example…had to build my own tool to extend git blame and track the AI generated code in our repository and save prompts: https://github.com/acunniffe/git-ai https://github.com/acunniffe/git-ai

deleted 1y ago
[deleted]

bArray 1y ago

Maybe I'm just old and moany, and I need to step aside for bigger and better things such as Rust. But. Now rather than needing to understand just C to work on Git/kernel, you now need to also know Rust. The toolchain complexity is increasing, and the mix of these languages increases the barrier to entry. I'm highly invested into Git, having learned the tooling and having a significant number of projects constructed within it. I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git.

GrayShade 1y ago
> I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git. And they will keep working because the repository format isn't affected by the language git is written in.
- account42 1y ago
  Believing that this will be the case forever is naive. At some point there will be extensions. Then those extensions will become all but mandatory for interacting with other git users.
IshKebab 1y ago
> I'm just old and moany, and I need to step aside for bigger and better things such as Rust. You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry. In any case Rust is usually easier than C (excluding buggy C which is very easy to write), and certainly easier than actually learning the Git or Linux codebases.
- hedgehog 1y ago
  I think it is often under appreciated by people who haven't worked in security how hard high quality C is in practice.
  - 1y ago

gedy 1y ago

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

bgwalter 1y ago

[flagged]

lucasoshiro 1y ago
> Normal users who have to install the Rust toolchain to build a previously simple piece of software do not count. "Normal users" would just install the same way they already do today without bothering about the toolchain. "Normal users" who want to build by theirselves probably won't find it too difficult. Given the size of Git it's incredibly easy to build: just install the dependencies and run `make`.

OCTAGRAM 1y ago

Will they introduce Ada and announce that it will become mandatory

johnisgood 1y ago
Only if safety really is their concern... so no.

riedel 1y ago

Given that rust only works on e.g. cygwin recently (and still does not build many crates: i try to compile jujutsu and failed), this is a big blow to portability IMHO. While I try to like rust, I think making it mandatory for builds of essential tools like git is really too early.

GoblinSlayer 1y ago
Git works only on cygwin too?
- Kwpolska 1y ago
  No, it doesn't. OP meant that the Rust support on Cygwin is bad; it is better with the native Windows API.
  - IshKebab 1y ago
    Cygwin is an ugly hack anyway.
  - sunshowers 1y ago
    I don't quite understand. Why use a janky, lossy Linux emulation layer when you can just target Windows natively?
    - GoblinSlayer 1y ago
      For some reason git for windows is a cygwin build.
      - 1718627440 1y ago
        Because git expects a POSIX API and POSIX tools and also POSIX behaviour like symlinks and line-endings to do its job.
      - lazka 1y ago
        It's a native build. Only various tools it is shipped with are cygwin builds, like bash etc.

secondcoming 1y ago

what's a 'test balloon'?

petiepooo 1y ago
A viral commit
oreally 1y ago
Ironically it's original use was in political* parlance. From wiki it's "information sent out to the media in order to observe the reaction of an audience. It is used by companies sending out press releases to judge customer reaction, and by politicians who deliberately leak information on a policy change." Yup I have no doubt that there's a Rust 'evangelist' group somewhere aiming for inorganic growth of the language.
- metaltyphoon 1y ago
  > Yup I have no doubt that there's a Rust 'evangelist' group somewhere aiming for inorganic growth of the language. So anything using Rust now must be the ‘evangelists’ work right?

sebtron 1y ago

I am curious, what is the reason behind introducing Rust in Git? I am not familiar with Git development, I am just a user. But my impression is that it is already a complete tool that won't require much new code to be written. Fixes and improvements here and there, sure, but that does not seem like a good reason to start using a new language. In contrast, I understand why adding it to e.g. Linux development makes sense, since new drivers will always need to be written. Can anyone explain what I might be missing?

jcrben 1y ago
C is unsafe.
- sebtron 1y ago
  I honestly can't tell if this is meant as serious reply to my question (in that case: let's say I agree that Rust is 100% better than C; my question still stands) or as a way to mock Rust people's eagerness to rewrite everything in Rust (in that case: are you sure this is the reason behind this? They are not rewriting Git from scratch...)
  - jcrben 1y ago
    As a user, you may not be aware that C makes it relatively easy to create https://en.m.wikipedia.org/wiki/Buffer_overflow 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.
    - msm_ 1y ago
      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.
      - happytoexplain 1y ago

Ericson2314 1y ago

Curious what this means for libgit2. Ideally upstream git would become better as a library as part of being rewritten in Rust.

egorfine 1y ago
[flagged]

saltcured 1y ago

Is this a bit of chickens coming home to roost as far as developer culture forgetting how to work with cross-compiling toolchains? When I started my career, it was common understanding that the developer may be manipulating sourcecode on a different system and/or platform than where it will be executed. Our source control, editing, compilation, and execution was understood to happen in different computational spaces, with possible copy/staging steps in between. You were doing something very naive if you assumed you could execute the built program on the same system where the sourcecode files existed and the editor/IDE was running. This was a significant fraction of the build rules we used to manage. E.g. configuration steps had to understand that the target platform being measured/characterized is not the same as the platform executing the build tools. And to actually execute a built object may require remote file copies and remote program invocation.

bloppe 1y ago
Actually, the Rust toolchain makes cross-compiling way easier than any other fully-compiled language I've ever used. There are like 100 different platforms you can target by just setting the `--target` flag, and they all pretty much just work on any host platform. Sounds like the real issue is that some Git developers have ancient, rigid requirements for their own development machines.
- cogman10 1y ago
  A good example of it is how easy it is to do WASM from rust. WASM is even one of the harder platforms to target with rust.
- saltcured 1y ago
  Others have said Rust does not support NonStop. But, my point is you shouldn't even have to cross-compile Git to a platform like NonStop in order to develop NonStop apps. So the portability of Rust shouldn't even matter here. The app developer should be able to run their Git commands on a supported platform and cross-compile their own app to NonStop.
  - 1y ago

taminka 1y ago

bruh what is that goofy ass capcha protection??

AnyTimeTraveler 1y ago
That's Anubis. A proof-of-work based protection against AI-Crawlers. https://github.com/TecharoHQ/anubis https://github.com/TecharoHQ/anubis

nayak 1y ago

This series was in response to another thread [1] which wanted to make rust mandatory in an upcoming release. The authors proposal was to instead take the middle ground and use rust as an optional dependency until a later point of time where it becomes mandatory. The later point of time was decided based on when rust support lands in gcc, which would make things smoother, since platforms which support gcc would also be included. [1]: https://lore.kernel.org/git/pull.1980.git.git.1752784344.gitgitgadget@gmail.com/#t https://lore.kernel.org/git/pull.1980.git.git.1752784344.git...

djha-skin 1y ago
The GCC compiler collection has been hit and miss though. Nobody uses gcj for example. I sort of doubt that they'll be able to implement a good compiler for a language that doesn't even have a standard without that implementation going wildly out of date in the future, just like what happened with Java.
- aw1621107 1y ago
  There's two different methods by which Rust support can be added to GCC: adding a Rust frontend to GCC and adding a GCC backend to the Rust compiler (rustc_codegen_gcc). The latter approach would not be (as?) susceptible to implementation divergence as an independent frontend.
  - nextaccountic 1y ago
    yep, if git is content with rustc_codegen_gcc, then it's very doable they can require rust in the next few years
  - 1718627440 1y ago
    I hope for the former since then the functionality might become available as attributes in C too.
    - aw1621107 1y ago

deleted 1y ago

[deleted]

cozzyd 1y ago

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

djha-skin 1y ago

Rust suffers from the same problems that functional programming languages suffer from: deep learning curve and high complexity. The high complexity is intended to push more runtime errors back to compile time, but boy does that mean the language pays for it. Rust is a tire fire of complexity. For these reasons I believe it is not a good idea. The kernel also sort of rejected Rust. The kernel is complex enough without adding a Haskell type system and a lisp-level macro system capable of obfuscating what code calls what code. serde code is so hard to spelunk for this reason. Contrast this with Go's Unmarshall, much easier to follow.

nixosbestos 1y ago
I was going to roll my eyes at "Rust is a tire fire of complexity". Because it's not. Especially compared to C++. But then you just go on to outright lie in your second paragraph.
- nixosbestos 1y ago
  Dear Rust haters, lying about Rust in the Linux kernel is not effective for your cause, and in fact just makes it further look like you're throwing a tantrum. Downvoting me doesn't change the fact that more and more Rust is merged into the kernel, new, serious drivers are being written in Rust. It also doesn't change Firefox, Chrome, Microsoft, the US Government and others are recommending and writing new code in Rust. It's over, qq. It's absurd. I really wish I could find the Lobsters comment the other day from someone that broke down the incredible list of nuanced, spec-level detail you needed to know about C++ to actually use it at scale in large projects. It's laughably, absurdly complex compared to Rust in huge code bases.
righthand 1y ago
I actually think Rust is pretty easy to pick up for anyone that’s written Typescript and can use their linter to understand references and unwrapping a Result and catching an error. Beyond that, Rust has pretty forgiving syntax. No Linux did not reject Rust from the kernel.
Yoric 1y ago

djha-skin 1y ago

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

dang 1y ago
Thanks! I've added that to the title above. If it's somehow inaccurate, we can change it again.
gbnbv 1y ago
What does that mean? Is it mandatory for building the build system or also for building the application?
- heavyset_go 1y ago
  If you want to build the project, you will need a Rust compiler in your toolchain.

drnick1 1y ago

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

Too 1y ago
> I doubt a lot of new code needs to be written I bet someone could have easily said the same thing a year ago or even 5 years ago. It's easy to forget the progress and there are a lot of things happening under the hood that are not obvious to casual users. Just take a look at the git log of the git repository itself. It has a steady rate of close to 100 commits per week for the past year. That says nothing of potential new features either. There is so much more to unlock in the VCS space, look at new tools like jj for example. Additionally, security landscape is getting more aggressive every day, keeping up with and being proactive against vulnerabilities will be needed more than today.
School-Cotton 1y ago
Rust has neither classes nor templates.

mimd 1y ago

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

nicoburns 1y ago

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

johnisgood 1y ago
So, I have been complaining about how Rust projects have over hundreds and often thousands of dependencies. I gave this random Rust project a try. The results: Building [ ] 5/338: libc(build), proc-macro2(build) No thank you. Can you Rust people stop doing this? Hundreds of dependencies is the norm in Rust culture. I swear humans will never learn.
- nicoburns 1y ago
  You can't really count "dependencies" in the Rust ecosystem by counting the number of crates. Gix itself has 65 crates but if you depended on it that would only really be one dependency. Your average Rust project will have more dependencies than your average C project, but it's not as dramatic as you might think.
  - johnisgood 1y ago
    Okay, but when I compile a Rust project and I see "0/2000" that gets pulled and built, I panic. > You can't really count "dependencies" in the Rust ecosystem by counting the number of crates. Can you elaborate as to why? I have much less packages (many of them are not even C libraries) installed by my operating system than what a typical Rust project pulls and builds.
    - nicoburns 1y ago
      > Can you elaborate as to why? Because Rust crates are the "compilation unit" as well as the "publishing unit". So if you are a largish library then you'll likely want to split your library across several crates (to enable things like parallelism in the build process). Then you'll end up with several crates from the same git repo, same developers, that will show up individually in the raw crate count. It's not a perfect analogy (because crates are generally multiple files), but imagine if in a C project you counted each header file as a separate dependency, it's kinda like that. --- There is a culture in the Rust ecosystem of preferring shared crates for functionality rather than writing custom versions of data structures or putting too much in the standard library (although it's not nearly so extreme as in the JavaScript ecosystem). And I do think the concern around supply-chain attacks is not entirely unwarranted. But at the same time, the quality standards for these crates are excellent, and in practice many of them are maintained by a relatively small group of people that as a Rust developer I know and trust.

leoh 1y ago

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

hoppp 1y ago

So they are adding technical debt to everything? Its either in the form of C code that will need to be rewritten in rust Or rust code that the C devs now will need to learn to understand the entire system Doesn't matter which way you look at it