Live data from Hacker News

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

lore.kernel.org

251–260 of 433 posts

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

#251
post #236

Earlier quoted context omitted.

[flagged]

Rust is over 10 years old now. It has a track record of delivering what it promises, and a very satisfied growing userbase. OTOH static analyzers for C have been around for longer than Rust, and we're still waiting for them to disprove Rice's theorem. AI tools so far are famous for generating low-quality code, and generating bogus vulnerability reports. They may eventually get better and end up being used to make C c…

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 with secure software development practices, but only by enforcing idiomatic style.

Bounded model checkers, on the other hand, are this tooling. They don't have to disprove Rice's theorem to work. In fact, they work directly with this theorem. They transform code into state equations that are run through an SMT solver. They are looking for logic errors, use-after-free, buffer overruns, etc. But, they also fail code for unterminated execution within the constraints of the simulation. If abstract interpretation through SMT states does not complete in a certain number of steps, then this is also considered a failure. The function or subset of the program only passes if the SMT solver can't find a satisfactory state that triggers one of these issues, through any possible input or external state.

These model checkers also provide the ability for user-defined assertions, making it possible to build and verify function contracts. This allows proof engineers to tie in proofs about higher level properties of code without having to build constructive proofs of all of this code.

Rust has its own issues. For instance, its core library is unsafe, because it has to use unsafe operations to interface with the OS, or to build containers or memory management models that simply can't be described with the borrow checker. This has led to its own CVEs. To strengthen the core library, core Rust developers have started using Kani -- a bounded model checker like those available for C or other languages.

Bounded model checking works. This tooling can be used to make either C or Rust safer. It can be used to augment proofs of theorems built in a proof assistant to extend this to implementation. The overhead of model checking is about that of unit testing, once you understand how to use it.

It is significantly less expensive to teach C developers how to model check their software using CBMC than it is to teach them Rust and then have them port code to Rust. Using CBMC properly, one can get better security guarantees than using vanilla Rust. Overall, an Ada + Spark, CBMC + C, Kani + Rust strategy coupled with constructive theory and proofs regarding overall architectural guarantees will yield equivalent safety and security. I'd trust such pairings of process and tooling -- regardless of language choice -- over any LLM derived solutions.

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

#252

Rust suffers from the same problems that functional programming languages suffer from: deep learning curve and high complexity. The high complexity is intended to push more runtime errors back to compile time, but boy does that mean the language pays for it. Rust is a tire fire of complexity. For these reasons I believe it is not a good idea. The kernel also sort of rejected Rust. The kernel is complex enough without…

I was going to roll my eyes at "Rust is a tire fire of complexity". Because it's not. Especially compared to C++. But then you just go on to outright lie in your second paragraph.

Dear Rust haters, lying about Rust in the Linux kernel is not effective for your cause, and in fact just makes it further look like you're throwing a tantrum. Downvoting me doesn't change the fact that more and more Rust is merged into the kernel, new, serious drivers are being written in Rust. It also doesn't change Firefox, Chrome, Microsoft, the US Government and others are recommending and writing new code in Rust. It's over, qq. It's absurd.

I really wish I could find the Lobsters comment the other day from someone that broke down the incredible list of nuanced, spec-level detail you needed to know about C++ to actually use it at scale in large projects. It's laughably, absurdly complex compared to Rust in huge code bases.

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

#253
post #250
post #211

Earlier quoted context omitted.

Git is already an uncomfortably large binary for embedded applications. Rust binaries tend to be even more bloated.

Why would you want to run a VCS in an embedded application? Any halfway usable development platform (even VIM) will be much bigger anyways.

It is sure convenient to be able to use git (and vim!) on embedded Linux. You can get by without them of course...

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

#254
post #88

Earlier quoted context omitted.

By not getting timely security updates: https://www.debian.org/releases/trixie/release-notes/issues....

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.

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

#255
post #74
post #66

Earlier quoted context omitted.

They're proposing porting over one small piece that has no dependencies and exposing it to the rest of git via a C interface. Yes, they'll presumably port more over in the future if it goes well, but it's a gross exaggeration to characterize this as somehow making it impossible to contribute without knowing Rust.

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.

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

#256
post #109

Earlier quoted context omitted.

Rust can't support a platform when that platform's vendors just provide a proprietary C compiler and nothing else (no LLVM, no GCC). Perhaps someone could reverse-engineer it, but ultimately a platform with zero support from any FOSS toolchain is unlikely to get Rust support anytime soon.

Furthermore, how could it without the donation of hardware, licenses and so forth?! This is a problem entirely of the proprietary platforms making, and it should be their customers problem for having made a poor decision.

HPE's customers are big-pocketed enough that they absolutely could manage a Rust port themselves, or pay HPE however much money they need to get them to do it if they're going to play games with ABI documentation. NonStop isn't some kind of weird hobbyist or retrocomputing platform.

Actually, I'm surprised HPE doesn't already ship a Rust fork, given how NonStop is supposed to be a "reliable" OS...

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

#257

Earlier quoted context omitted.

It's a lot more understandable for developer tooling like Git to more quickly adopt newer system requirements. Something like the Linux kernel needs to be conservative because it's part of many people's bootstrapping process. rustc_codegen_gcc is close to becoming stable, and conversely the Linux kernel is dropping more esoteric architectures. Once the supported sets of architectures fully overlap, and once the Linux…

I would also say that it’s a lot easier to learn to write rust when you’re writing something that runs sequentially on a single core in userspace as opposed to something like the Linux kernel. Having dipped my toes in rust that seems very approachable. When you start doing async concurrency is when the learning curve becomes steep.

Those footguns still exist in C, they’re just invisible bugs in your code. The Rust compiler is correct to point them out as bad architecture, even if it’s annoying to keep fighting the compiler.

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

#258
post #242

Earlier quoted context omitted.

(There is a persistent idea that the lack of memory safety in C is good because it allows people to jailbreak their phones.)

This is not what I said, but memory safety is certainly not anything which is a high priority for my own security. I still think memory safety is important and I also think Rust is an interesting language, but... the hype is exaggerated and driven by certain industry interests.

Rust isn't popular just because of memory safety though. I think the memory safety message is maybe a little too loud.

It's also a modern language with fantastic tooling, very high quality library ecosystem and a strong type system that reduces the chance of all kinds of bugs.

It's obviously not perfect: compile time is ... ok, there aren't any mature GUI toolkits (though that's true of many languages), async Rust has way too many footguns. But it's still waaaaay better than C or C++. In a different league.

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

#259
post #242

Earlier quoted context omitted.

(There is a persistent idea that the lack of memory safety in C is good because it allows people to jailbreak their phones.)

This is not what I said, but memory safety is certainly not anything which is a high priority for my own security. I still think memory safety is important and I also think Rust is an interesting language, but... the hype is exaggerated and driven by certain industry interests.

While I really really want devices I can own, I don't want to compromise security to do it. We need to do two things:

1. Lobby politicians to write laws that allow us to actually own the devices we bought.

2. Stop the FUD that a device that can be jailbroken is insecure. I heard this from our frigging CSO, of all people, and it's patently false, just FUD by Apple and Google who want you to be afraid of owning your device.

I want a device that's as secure as possible, but that I can own. I don't want to hack my own self just to get what I paid for.

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

#260
post #94

Earlier quoted context omitted.

Shouldn't these platforms work on getting Rust to support it rather than have our tools limited by what they can consume? https://github.com/Rust-GCC/gccrs

A maintainer for that specific platform was more into the line of thinking that Git should bend over backwards to support them because "loss of support could have societal impact [...] Leaving debit or credit card authorizers without a supported git would be, let's say, "bad"." To me it looks like big corps enjoying the idea of having free service so they can avoid maintaining their own stuff, and trying the "too big…

> Leaving debit or credit card authorizers without a supported git would be, let's say, "bad".

Oh no, if only these massive companies that print money could do something as unthinkable as pay for a support contract!

Post reply on HN