331–340 of 433 posts
Earlier quoted context omitted.
I know that it is a "slippery slope" argument, but in the future, it will become more difficult to contribute without knowing Rust. That's the entire point of introducing it.
And also, a lot of people who hate C, or who never learned it well, will be able to contribute to more and more areas of the Linux kernel.
How does this help me as a user of git?
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).
Will they introduce Ada and announce that it will become mandatory
See also: https://github.com/GitoxideLabs/gitoxide which is a full rewrite of git in Rust.
The results:
Building [ ] 5/338: libc(build), proc-macro2(build)
Can you Rust people stop doing this? Hundreds of dependencies is the norm in Rust culture. I swear humans will never learn.
Earlier quoted context omitted.
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.... 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…
Not especially relevant for Git which has never provided a shared library interface.
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.
Earlier quoted context omitted.
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.)
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.
See also: https://github.com/GitoxideLabs/gitoxide which is a full rewrite of git in Rust.
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.
Your average Rust project will have more dependencies than your average C project, but it's not as dramatic as you might think.
Earlier quoted context omitted.
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.
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.
> 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.
Earlier quoted context omitted.
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.
No, I'm implying that it would make Git's implementation of submodules less buggy. That is likely the case.
Earlier quoted context omitted.
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.
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.
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.