| ▲ | sebtron 3 days 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? |
|
| ▲ | striking 3 days ago | parent | next [-] |
| Git is constantly gaining features, even if for the most part it seems like the core functionality is unchanged. If you'd like to review the changelog, the Git repo has RelNotes but I've found GitHub's blog's Git category to be a more digestible resource on the matter: https://github.blog/open-source/git/ |
|
| ▲ | mhh__ 3 days ago | parent | prev | next [-] |
| git feels complete until you use a tool like jj or git-branchless (latter of which has things like in-memory merges in rust) |
| |
| ▲ | feelamee 2 days ago | parent | next [-] | | 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 | |
| ▲ | eYrKEC2 3 days ago | parent | prev [-] | | Or if you use its predecessor, bitkeeper. |
|
|
| ▲ | altairprime 3 days ago | parent | prev | next [-] |
| 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.) |
|
| ▲ | surajrmal 2 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | bitwize 2 days ago | parent [-] | | 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 | | |
| ▲ | hoppp 2 days ago | parent | next [-] | | Why not zig tho.. keep the C, compile with zigcc and write new code in zig. Best of both worlds. | | |
| ▲ | bitwize 2 days ago | parent [-] | | uwu but zig doesn't give you memory and concurrency safety guarantees, oniichan! |
| |
| ▲ | RicoElectrico 2 days ago | parent | prev [-] | | Idk if it's funny or sad, cause it's true. |
|
|
|
| ▲ | bsder 3 days ago | parent | prev | next [-] |
| > I am curious, what is the reason behind introducing Rust in Git? More developers. Old C projects simply don't have enough incoming developers anymore. No one is clamoring to join the Git project and write C code. The Rewrite It In Rust(tm) brigade, on the other hand, will be happy, for now, to join and spread the gospel of Rust. |
| |
| ▲ | dangus 2 days ago | parent [-] | | 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. |
|
|
| ▲ | monkeyelite 2 days ago | parent | prev | next [-] |
| To capture existing status for Rust promoters. |
|
| ▲ | bitwize 2 days ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | stefantalpalaru 3 days ago | parent | prev | next [-] |
| [dead] |
|
| ▲ | jcrben 3 days ago | parent | prev [-] |
| C is unsafe. |
| |
| ▲ | conradev 3 days ago | parent | next [-] | | Changing well-tested code is unsafe. | | |
| ▲ | Groxx 3 days ago | parent | next [-] | | 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. | | |
| ▲ | feelamee 2 days ago | parent [-] | | 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. |
| |
| ▲ | striking 3 days ago | parent | prev | next [-] | | 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? | | |
| ▲ | 1718627440 3 days ago | parent [-] | | 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. | | |
| |
| ▲ | IshKebab 3 days ago | parent | prev [-] | | 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. | | |
| ▲ | conradev 3 days ago | parent [-] | | 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. | | |
| ▲ | metaltyphoon 3 days ago | parent | next [-] | | And it’s still a choice you can make regardless of Git moving to Rust or not, so what’s the problem? | |
| ▲ | akerl_ 2 days ago | parent | prev [-] | | 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. |
|
|
| |
| ▲ | gre 3 days ago | parent | prev | next [-] | | https://github.com/Speykious/cve-rs | | | |
| ▲ | sebtron 3 days ago | parent | prev | next [-] | | 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 3 days ago | parent [-] | | 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. | | |
| ▲ | msm_ 3 days ago | parent | next [-] | | 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. | | |
| ▲ | jcrben 3 days ago | parent | next [-] | | 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. | |
| ▲ | happytoexplain 3 days ago | parent | prev [-] | | I didn't know that C makes it easy. |
| |
| ▲ | sebtron 3 days ago | parent | prev | next [-] | | 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. | | |
| ▲ | rrdharan 3 days ago | parent [-] | | 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. | | |
| ▲ | aw1621107 3 days ago | parent [-] | | > 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. |
|
| |
| ▲ | 1718627440 3 days ago | parent | prev [-] | | 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. | | |
| ▲ | TuxSH 3 days ago | parent | next [-] | | 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. | | |
| ▲ | 1718627440 3 days ago | parent | next [-] | | 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. | |
| ▲ | nicoburns 3 days ago | parent | prev [-] | | Unintentional bugs that caused data destruction would also be disastrous for a tool like git | | |
| |
| ▲ | aw1621107 3 days ago | parent | prev [-] | | > 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? | | |
| ▲ | 1718627440 a day ago | parent [-] | | 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. |
|
|
|
| |
| ▲ | EverydayBalloon 3 days ago | parent | prev [-] | | [dead] |
|
