| ▲ | monkeyelite 3 days ago |
| How does this help me as a user of git? |
|
| ▲ | jaas 3 days ago | parent | next [-] |
| Rust is generally a much better tool for building software than C. When your software is built with better tools, you will most likely get better software (at least eventually / long term, sometimes a transition period can be temporarily worse or at least not better). |
| |
| ▲ | monkeyelite 3 days ago | parent | next [-] | | That would be a stronger argument if people were facing implementation deficiencies in git | | |
| ▲ | IshKebab 3 days ago | parent [-] | | I'm not sure exactly what you mean but of course people are facing implementation deficiencies in Git. Last I checked submodules were still "experimental" and extremely buggy, and don't work at all with worktrees. (And yeah submodules suck but sometimes I don't have a choice.) | | |
| ▲ | mariusor 2 days ago | parent | next [-] | | Your reply seems to imply that using rust would make submodules better. Since that's not the case, maybe you can provide an alternative where rust would address an actual issue git users have. | | |
| ▲ | IshKebab 2 days ago | parent [-] | | No, I'm implying that it would make Git's implementation of submodules less buggy. That is likely the case. | | |
| ▲ | mariusor 2 days ago | parent [-] | | If we're talking about feelings, I find it "not likely" unless, perhaps as a side-effect of rethinking the whole feature all together. Or do you have some actual indicators that the issues with how modules are likely to break your work directory are related to problems that rust avoids? | | |
| ▲ | IshKebab 2 days ago | parent [-] | | Yes I do. Rust's strong type system makes logic bugs less likely, because you can encode more invariants into the type system. This also makes it easier to refactor and add features without risk of breaking things. The borrow checker also encourages ownership structures that are less error-prone. Finally the more modern tooling makes it easier to write tests. If you're thinking "where is the peer reviewed study that proves this?" then there isn't one, because it's virtually impossible to prove even simple things like that comments are useful. I doubt there's even a study showing that e.g. it's easier to write Python than assembly (although that one probably isn't too hard to prove). That doesn't mean you get to dismiss everything you disagree with simply because it hasn't been scientifically proven. The things I'm talking about have been noted many times by many people. | | |
| ▲ | mariusor 2 days ago | parent [-] | | OK, but I'm not convinced for this specific case. And it wouldn't take a peer reviewed study to convince me. Issues in the git submodules handling that you could link to C's lack of safety would suffice. However what you're doing is to reply with the same platitudes and generalities that all rust aficionados seem to have ready on demand. Sure, rust is better at those things, but I don't see how that would make a rewrite of an existing feature better by default. I don't doubt that new features of git that would be written in rust will be safer and more ergonomic, but for existing code to be rewritten, which is what I understand to be your stance, I remain skeptical. |
|
|
|
| |
| ▲ | monkeyelite 3 days ago | parent | prev [-] | | I mean I don’t encounter bugs when I use the program. So telling me rust is going to fix bugs is meh. A web browser is more interesting. |
|
| |
| ▲ | egorfine 2 days ago | parent | prev | next [-] | | > Rust is generally a much better tool for building software than C. This is an extremely strong statement. And factually incorrect. | |
| ▲ | 3 days ago | parent | prev | next [-] | | [deleted] | |
| ▲ | johnisgood 2 days ago | parent | prev [-] | | You missed "IMO". We get it, you love Rust and/or hate C, and if so, I wonder why. Try Ada + SPARK though if you really want REAL safety. Its track record speaks for itself. |
|
|
| ▲ | alexchamberlain 3 days ago | parent | prev | next [-] |
| The developers of git will continue to be motivated to contribute to it. (This isn’t specific to Rust, but rather the technical choices of OSS probably aren’t generally putting the user at the top of the priority list.) |
| |
| ▲ | veber-alex 3 days ago | parent [-] | | I am pretty sure that developers motivated to contribute code benefits end users plenty. |
|
|
| ▲ | uecker 3 days ago | parent | prev | next [-] |
| By not getting timely security updates: https://www.debian.org/releases/trixie/release-notes/issues.... |
| |
| ▲ | MarsIronPI 3 days ago | parent [-] | | And the reason this is a problem is because of the me-first attitude of language developers these days. It feels like every language nowadays feels the need to implement its own package manager. These package managers then encourage pinning dependencies, which encourages library authors to be a less careful about API stability (though obviously this varies from library to library) and makes it hard on distro maintainers to make all the packages work together. It also encourages program authors to use more libraries, as we see in the Javascript world with NPM, but also in the Rust world. Now, Rust in Git and Linux probably won't head in these directions, so Debian might actually be able to support these two in particular, but the general attitude of Rustacians toward libraries is really off-putting to me. | | |
| ▲ | uecker 3 days ago | parent | next [-] | | IMHO the reason is that these languages are industry-funded efforts. And they are not funded to help the free software community. Step-by-step this reshapes the open-source world to serve other interests. | |
| ▲ | neobrain 3 days ago | parent | prev [-] | | Semantic versioning is culturally widespread in Rust, so the problem of library authors being "less careful about API stability" rarely happens in practice. If pinned packages were the problem, I'd imagine they would have been called out as such in the Debian page linked by parent. | | |
| ▲ | account42 a day ago | parent [-] | | Semantic versioning is a way to communicate how much a new version breaks new shit not a way to encourage not breaking shit. If anything, having a standardized way to communicate that you are breaking shit kind of implies that you are already planning to break shit often enough for that to make sense. | | |
|
|
|
|
| ▲ | Mikhail_K 3 days ago | parent | prev | next [-] |
| It doesn't, it hurts you by limiting the number of platforms Git is available on. |
| |
|
| ▲ | cschep 3 days ago | parent | prev | next [-] |
| My guess is that we (I am also a user of git) won't even notice. |
| |
| ▲ | johnisgood 3 days ago | parent [-] | | 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 3 days ago | parent [-] | | 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?? | | |
| ▲ | cozzyd 3 days ago | parent | next [-] | | Git is already an uncomfortably large binary for embedded applications. Rust binaries tend to be even more bloated. | | |
| ▲ | fsh 3 days ago | parent [-] | | Why would you want to run a VCS in an embedded application? Any halfway usable development platform (even VIM) will be much bigger anyways. | | |
| ▲ | cozzyd 3 days ago | parent [-] | | It is sure convenient to be able to use git (and vim!) on embedded Linux. You can get by without them of course... |
|
| |
| ▲ | johnisgood 3 days ago | parent | prev [-] | | No need to bite. :P We will see! | | |
| ▲ | AlexeyBelov a day ago | parent [-] | | See what? Why are you vague-posting? | | |
| ▲ | johnisgood a day ago | parent [-] | | We will see how larger the binary will become, we will see how many more (if any) shared libraries it will depend on, and we will see how long it will take to compile. Clear enough for you? It is a note to myself, and for others who care. You might not care, I do, and some other people do, too. |
|
|
|
|
|
|
| ▲ | IshKebab 3 days ago | parent | prev | next [-] |
| In future it might be more reliable and faster, maybe with more features. But we probably won't see any effect for 10 years or so. |
| |
| ▲ | tankenmate 3 days ago | parent | next [-] | | Except there are far less Rust developers than C developers, so contributions will start to drop as Rust usage expands in git. | | |
| ▲ | Philpax 3 days ago | parent [-] | | I would safely bet that the pool of C developers willing to work on a C Git going forward is much closer to exhaustion than the pool of Rust developers willing to work on a Rust(-ish) Git. |
| |
| ▲ | veber-alex 3 days ago | parent | prev [-] | | 10 years? are they going to contribute 1 line of a code a day or something? | | |
| ▲ | IshKebab 3 days ago | parent [-] | | 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. |
|
|
|
| ▲ | gitaarik 2 days ago | parent | prev [-] |
| That git development will be modern, secure and fast? |
