Live data from Hacker News

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

lore.kernel.org

381–390 of 433 posts

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

#381
post #342
post #326

Earlier quoted context omitted.

Fair enough. I just find it mind boggling how much money flows into completely new language ecosystems compared to improvements for C/C++ tooling which would clearly much more effective if you really cared about overall security of the free software world.

The issue with investing similar levels of effort into making C++ safer is the C++ standards committee doesn't want to adopt those kinds of improvements.

Which is also the reason why we don't have #pragma once and many other extensions like it. Except we do. Compilers can add rust-like static analyzers without the standard committee mandating it.

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

#382
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…

> I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git. And they will keep working because the repository format isn't affected by the language git is written in.

Believing that this will be the case forever is naive. At some point there will be extensions. Then those extensions will become all but mandatory for interacting with other git users.

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

#383

Earlier quoted context omitted.

I've also sent some patches git's way and I can't say I'm thrilled about being forced to (finally) learn Rust if I want to contribute again in the future. I guess I'm outdated...

I feel the same way about C code though. I don't think C gets the right to be the one true programming language that everyone must know forever .

Once the C evangelism strike force pushed C code into rust projects you might have an argument.

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

#384

Earlier quoted context omitted.

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

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.

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.

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

#385
post #82

Earlier quoted context omitted.

It's literally a test of how people will react, so yes, finding out if people will react negatively would be exactly the point of doing the test in the first place. Would you prefer that they don't publicize what their follow-up plans would be to try to make it harder to criticize the plans? If you're against the plan, I'm pretty sure that's the exact type of feedback they're looking for, so it would make more sense…

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.

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

#386

Earlier quoted context omitted.

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.

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.

Only one number communicates breaking shit, two do not.

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

#387

Earlier quoted context omitted.

how is that not the same thing?

You could read "Rust will become mandatory" as "all contributors will need to be able to code Rust" or even "all new code has to be written in Rust" or similar variations

It's still effectively the same thing. You don't take on a huge dependency like that without planning to use it extensively.

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

#388

Earlier quoted context omitted.

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…

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

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.

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

#389

Earlier quoted context omitted.

> your build environment doesn't support our codebase If that is due to the build environment deviating from the standard, then I agree with you. However, when its due to the codebase deviating from the standard, then why blame the build environment developers for expecting codebases to adhere to standards. That's the whole point of standards.

Had you been under the impression that any of these niche platforms conform to any common standard other than their own? Because they don’t. For instance, if they were fully POSIX compliant, they’d probably already have LLVM.

I expect them to conform to the C standard or to deal with the deviation. I don't think POSIX compliance is of much use on an embedded target.

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

#390
post #186

Earlier quoted context omitted.

> your build environment doesn't support our codebase If that is due to the build environment deviating from the standard, then I agree with you. However, when its due to the codebase deviating from the standard, then why blame the build environment developers for expecting codebases to adhere to standards. That's the whole point of standards.

Is there a standard that all software must be developed in ANSI C that I missed, or something? The git developers are saying - we want to use Rust because we think it will save us development effort. NonStop people are saying we can't run this on our platform. It seems to me someone at git made the calculus: the amount that NonStop is contributing is less than what we save going to Rust. Unless NonStop has a support…

An important point of using C is to write software that adheres to a decades old very widespread standard. Of course developers are free to not do that, but any tiny bit of Rust in the core or even in popular optional code amounts to the same as not using C at all, i.e. only using Rust, as far as portability is concerned.

If your codebase used to conform to a standard and the build environment relies on that standard, and now the your codebase doesn't anymore, then its not the build environment that deviates from the standard, its the codebase that brakes it.

Post reply on HN