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

271–280 of 433 posts

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

#271

Post by sunshowers »

riedel wrote: post #238
sunshowers wrote: post #227

Earlier quoted context omitted.

Right, but Rust makes it so you don't have to use Cygwin. It's one of the great portability advantages of Rust that you can write real Windows programs with it.

I am not really sure if I can follow here. How could a rust compiled program like git honor my cygwin emulated mount points in paths, which I need, when working with other posix compliant software.

I thought that if you invoke a native Windows binary with Cygwin, it translates Unix-looking paths into Windows ones. But it's been a long time since I used Cygwin so I could be wrong.

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

#272

Post by crote »

3036e4 wrote: post #138
bbor wrote: post #16

Earlier quoted context omitted.

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?

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

The problem is that "support" usually isn't quite the right word. In practice for obscure platforms it is often closer to "isn't known to be horribly broken". Rust at least states this explicitly with their Tier 1/2/3 system, but the same will apply to every project.

Platform support needs to be maintained. There is no way around that. Any change in the codebase has the possibility of introducing subtle platform-specific bugs. When platform support means that some teenager a decade ago got it to compile during the summer holiday and upstreamed her patches, that's not worth a lot. Proper platform support means having people actively contributing to the codebase, regularly running test suites, and making sure that the project stays functional on that platform.

On top of this, it's important to remember that platform support isn't free either. Those platform-specific patches and workarounds can and will hold back development for all the other platforms. And if a platform doesn't have a maintainer willing to contribute to keeping those up-to-date, it probably also doesn't have a developer who's doing the basic testing and bug fixing, so its support is broken anyways.

In the end, is it really such a big deal to scrap support for something which is already broken and unlikely to ever be fixed? At a certain point you're just lying to yourself about the platform being supported - isn't it better to accept reality and formally deprecate it?

In theory I agree with you, and code written in a platform-agnostic way is definitely something we should strive for, but in practice: can keeping broken code around really be called "good engineering culture"?

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

#273

Post by kazinator »

Yoric wrote: post #214
kazinator wrote: post #126

Earlier quoted context omitted.

Reverse that: "C can't support a platform when that platform's vendors just provide a proprietary Rust compiler and nothing else".

Seems to me that that is equally true and doesn't remove any validity from the argument.

[flagged]

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

#274

Post by bsder »

sebtron wrote: post #98

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

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

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

#275

Post by [deleted] »

crote wrote: post #268
kazinator wrote: post #115

Earlier quoted context omitted.

[flagged]

On the other hand: why should the entire open-source world screech to a halt just because some new development is incompatible with the ecosystem of a proprietary niche system developed by a billion-dollar freeloader? HPE NonStop doesn't need to do anything with Rust, and nobody is forcing them to. They have voluntarily chosen to use an obscure proprietary toolchain instead of contributing to GCC or LLVM like everyon…

[deleted]

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

#276

Post by nanolith »

IshKebab wrote: post #264
nanolith wrote: post #251

Earlier quoted context omitted.

The applicability of Rice's theorem with respect to static analysis or abstract interpretation is more complex than you implied. First, static analysis tools are largely pattern-oriented. Pattern matching is how they sidestep undecidability. These tools have their place, but they aren't trying to be the tooling you or the parent claim. Instead, they are more useful to enforce coding style. This can be used to help wi…

Sure it's possible in theory, but how many C codebases actually use formal verification? I don't think I've seen a single one. Git certainly doesn't do anything like that. I have occasionally used CBMC for isolated functions, but that must already put me in the top 0.1% of formal verification users.

It's not used more because it is unknown, not because it is difficult to use or that it is impractical.

I've written several libraries and several services now that have 100% coverage via CBMC. I'm quite experienced with C development and with secure development, and reaching this point always finds a handful of potentially exploitable errors I would have missed. The development overhead of reaching this point is about the same as the overhead of getting to 80% unit test coverage using traditional test automation.

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

#277

Post by aw1621107 »

rrdharan wrote: post #148
sebtron wrote: post #139

Earlier quoted context omitted.

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

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.

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

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

#278

Post by kazinator »

saghm wrote: post #261
kazinator wrote: post #122

Earlier quoted context omitted.

[flagged]

>> insisting on a closed C compiler in 2025. > Everything should use one compiler, one run-time and one package manager. If you think that calling out closed C compilers is somehow an argument for a single toolchain for all things, I doubt there's anything I can do to help educate you about why this isn't the case. If you do understand and are choosing to purposely misinterpret what I said, there are a lot of much st…

For various libs, you provide a way to build without it. If it's not auto-detected, or explicitly disabled via the configure command line, then don't try to use it. Then whatever depends on it just doesn't work. If for some insane reason git integrates XML and uses libxml for some feature, let it build without the feature for someone who doesn't want to provide libxml.

> At the end of the day, there's a finite amount of work people spend on a given project

Integrating Rust shows you have too much time on your hands; the people who are affected by that, not necessarily so.

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

#280

Post by daurentius523 »

politelemon wrote: post #2

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

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

Post reply on HN