Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lore.kernel.org

Post reply on HN
Print view View original

401–410 of 433 posts

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

#401

Post by 1718627440 »

Borg3 wrote: post #232
bArray wrote: post #54

Maybe I'm just old and moany, and I need to step aside for bigger and better things such as Rust. But. Now rather than needing to understand just C to work on Git/kernel, you now need to also know Rust. The toolchain complexity is increasing, and the mix of these languages increases the barrier to entry. I'm highly invested into Git, having learned the tooling and having a significant number of projects constructed w…

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.

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

#402

Post by MarsIronPI »

yencabulator wrote: post #292
MarsIronPI wrote: post #215

Earlier quoted context omitted.

Which Rust still does not have. If serious projects like Git and Linux are adopting Rust, the Rust team might want to consider writing a spec.

https://blog.rust-lang.org/2025/03/26/adopting-the-fls/

A specification is not a standard. It's a good first start, but what makes a standard more valuable is that it requires more than one entity to approve a change to it. This does look like a step in the right direction though.

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

#403

Post by hoppp »

bitwize wrote: post #372
hoppp wrote: post #365

Earlier quoted context omitted.

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!

Adding rust to C is like adding a katana to a shovel; it doesn't make the shovel any more effective at digging, senpai!

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

#404

Post by 1718627440 »

cozzyd wrote: post #211
cschep wrote: post #85

Earlier quoted context omitted.

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??

Git is already an uncomfortably large binary for embedded applications. Rust binaries tend to be even more bloated.

Yes, Hello World is 10MB in Rust even when optimizing for size. Hello World in C is 16kB, even after static linking everything including GNU libc, it's only 810kB. I really wonder what that large program does.

This program is still dynamically linked:

     linux-vdso.so.1 (0x00007ffe6d8fd000)
     libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb0a62c6000)
     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb0a60f2000)
     /lib64/ld-linux-x86-64.so.2 (0x00007fb0a636d000)
     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb0a60d0000)
     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb0a60ca000)
Not sure, why it needs all these dependencies, this is C Hello World:

    linux-vdso.so.1 (0x00007fffea181000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faebae6a000)
    /lib64/ld-linux-x86-64.so.2 (0x00007faebb087000)
And I think the C binary is already bloated.

To stress it again: The Rust Hello World program is 2.5-times larger then the whole Git executable with functionality of 20 years!

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

#405

Post by 1718627440 »

IshKebab wrote: post #201
veber-alex wrote: post #153

Earlier quoted context omitted.

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

Well it would probably take at least 5 years to rewrite all of Git in Rust (git-oxide is 5 years old and far from finished). Then another few years to see novel features, then a year or two to actually get the release. Btw 10 lines of code per day is a typical velocity for full time work, given it's volunteers 1 line per day might not be as crazy as you think.

Wait, why do we need to convert C Git to Rust, when a Rust fork is already existing?

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

#406

Post by nicoburns »

johnisgood wrote: post #343
nicoburns wrote: post #340

Earlier quoted context omitted.

> 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 perf…

And are these dependencies that get pulled and built general-purpose? I presume it is since it is published, but I have no idea if it is indeed general-purpose, or something like "internal/*/*" in Go where the code is not supposed to be used by any other codebase.

Usually they are reasonably general purpose, but somewhat less so than the top-level crate. Sometimes sub-crates are interface-only (as a lightweight alternative if you want to bring your own implementation), or a sub-crate may expose a lower-level API that works without the std library.

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

#407

Post by altairprime »

account42 wrote: post #385
altairprime wrote: post #120

Earlier quoted context omitted.

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…

If you're looking for reasons to ignore criticism like this then you were never interested in anything other than an affirmative nod and pat on the back in the first place.

> then you were never interested in anything other than an affirmative

I disagree. Perhaps these roguelike examples will clarify.

You can Raise Concerns towards the project. The project is mired in your concerns! The project loses 5 HP extricating itself from the muck! The project moves forward. --more--

This indicates that the project considered the concern raised and chose not to halt work over it; those 5 HP who might be impacted should continue planning for that impact. Most likely, in Git's case, that's either 'the good of the project outweighed the impact to the few' and/or 'no one is willing to commit developer/maintainer hours to us for that platform so we're bailing on it'. I haven't uncovered any evidence that they tend to lie about project motivations, and certainly I would not classify the project founder as 'uncomfortable sharing unpalatable views', so I have no evidence supporting the accusation that the Git project might refuse to consider a supported claim that has not already been evaluated.

You cast Unsupported Claims towards the project. The project's shield reflects them! You take 5 HP of Reasoning damage! The project moves forward. --more--

A politely-phrased objection is meaningless if it isn't backed by reasoning that can be considered and either accepted or rejected by a project. People do try, but disappointingly, human beings are sometimes vulnerable to politeness attacks of this sort. I can assert with near-perfect certainty that Git is not vulnerable to polite but unsupported objections.

You cast Hostile Tirade towards the project. The project casts Protection from Hostility! Your tirade has no effect. You blink away! --more--

Everyone is looking to ignore this kind of criticism. The roguelike joke makes it especially clear that the criticism was not considered solely due to how it was presented, rather than by whatever merits it may have. Doesn't matter how substantive the claims, being mean typically guarantees both disregard and eviction from the chosen battlefield.

ps. Note that in some cases, the project will abandon the requested outcome. Human beings have a certain percentage chance of sacrificing personal gain to 'reward' hostility with an outcome that is maximally undesirable to those being hostile. This can result in ending support for platforms that might otherwise have remained support, or even outright shutdown of an entire project. See also: Fez 2, libxslt, et al.

pps. None of these outcomes guarantee that they will change course, even if a perfectly-supported and politely-presented argument is made and considered. None of these outcomes guarantee that one will receive a considered rejection rather than a blind rejection, either. There is no Konami code, but one thing is certain: one cannot win an boss fight by throwing the controller at the TV.

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

#408

Post by aw1621107 »

1718627440 wrote: post #400
aw1621107 wrote: post #208

Earlier quoted context omitted.

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.

Might depend on the specific feature. If Clang is any indication I wouldn't hold out hope that (frontend?) features like lifetimes/borrow checking are easily transferable.

In any case, there is work on a Rust frontend for GCC (gccrs), but I haven't seen any discussion on whether any of the Rust-specific features can benefit other GCC frontends. Might be a bit premature for those discussions anyways since the frontend has yet to reach production readiness.

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

#409

Post by 1718627440 »

aw1621107 wrote: post #408
1718627440 wrote: post #400

Earlier quoted context omitted.

I hope for the former since then the functionality might become available as attributes in C too.

Might depend on the specific feature. If Clang is any indication I wouldn't hold out hope that (frontend?) features like lifetimes/borrow checking are easily transferable. In any case, there is work on a Rust frontend for GCC (gccrs), but I haven't seen any discussion on whether any of the Rust-specific features can benefit other GCC frontends. Might be a bit premature for those discussions anyways since the frontend…

The compiler has already the concept of scope and variables existing at least in the optimizer. Ownership tracking programs for C have been existing for 20 years, so it can't be too hard to integrate it in the compiler, once it has been implemented for one language.

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

#410

Post by aw1621107 »

1718627440 wrote: post #409
aw1621107 wrote: post #408

Earlier quoted context omitted.

Might depend on the specific feature. If Clang is any indication I wouldn't hold out hope that (frontend?) features like lifetimes/borrow checking are easily transferable. In any case, there is work on a Rust frontend for GCC (gccrs), but I haven't seen any discussion on whether any of the Rust-specific features can benefit other GCC frontends. Might be a bit premature for those discussions anyways since the frontend…

The compiler has already the concept of scope and variables existing at least in the optimizer. Ownership tracking programs for C have been existing for 20 years, so it can't be too hard to integrate it in the compiler, once it has been implemented for one language.

> The compiler has already the concept of scope and variables existing at least in the optimizer.

My gut feeling is that while the high-level concepts might share a name I'm not actually sure if they're similar enough for useful transfer? The optimizer is working on a very different representation at a later stage of the compilation process, so I'm a bit skeptical about the level of similarity and/or transferability when you get down to details. I guess a more concrete example might be like comparing type inference with optimizer value range analysis - both will analyze a CFG, but beyond that they're working on different-enough representations that transforming work on the latter to useful work on the former seems unlikely to me (though I'm a nobody, so take that with an appropriate grain of salt).

For example, consider work on improved lifetime analysis in Clang [0], which seems to be discussing a from-scratch implementation based on concepts from Polonius and doesn't seem to reference anything from LLVM. And more generally, the fact that neither GCC nor Clang appear to have discussed reusing concepts from their optimizer passes to recreate the borrow checker or borrow checker-like functionality makes it seem more likely to me that there's some fundamental distinction and/or additional considerations that make such a project difficult.

> Ownership tracking programs for C have been existing for 20 years

Could you give some examples? Not sure I've heard of anything that would fill the same niche as the borrow checker.

> so it can't be too hard to integrate it in the compiler, once it has been implemented for one language.

Sorry, I'm getting a bit confused here. When you say "integrate it in the compiler", by "it" do you mean the above mentioned "ownership tracking programs for C", or do you mean features implemented in the GCC Rust frontend?

In any case, as far as the borrow checker goes gccrs is currently planning on reusing rustc's borrowck implementation so that's going to be a bit of a hurdle to integrating similar functionality into other frontends. I don't know whether they plan on eventually writing an independent borrow checking implementation. Not sure if you had other features in mind, either.

[0]: https://discourse.llvm.org/t/rfc-intra-procedural-lifetime-a...

Post reply on HN