I don't know what this has to do with locking down phones, but I do appreciate not getting compromised just for cloning a repo or opening my laptop at a coffee shop.

Well only because 99% of the world's COBOL developers were laid off decades ago (or switched to another language).

As someone with experience in this specific niche, yes they absolutely are. There are no longer ten thousand retail chains asking for COBOL-based counterpoint PoS mods on a yearly basis.

The COBOL market is basically tenured experts in existing systems or polyglots helping migrate the systems to VB or C# at this point. The market has plummeted and now it's in the final deflationary shrink before death.

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.

I'm sure you are aware, reading between the lines of what you said, why, but for some others who aren't aware of the history of git; it was originally about 50% C and 50% Perl, the performance critical parts were written in C and then various git commands were written in Perl. Over time almost all the Perl was removed because there were less Perl monks than C devs.

Now it would seem the logic is reversed; even though there are less Rust devs than C devs, Rust is going to replace C. Maybe now that git is large enough and entrenched enough such a move can be forced through.

> Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped.

This is how it works in the kernel on the C side, too. Usually by using guard/scoped_guard which wrap the generic mutexes with some RAII.

It's hilarious that you can assume such a thing just by a couple of words on the internet. Or maybe I'm not a 'software engineer' by your standards because unlike your closed group of SWEs I'm a lot less focused on resume padding and keeping my codebase sane and not exploding in complexity.

I should specify - it's hard in that it's troublesome to have to code switch and do a bunch of recall before working on the thing.

Say you've not worked on this secondary language for a long time, which absolutely happens, and have spend hours of effort to recall it. This takes time that you need not spend on, it's how your memory works.

I guess in a certain sense, yes, the total number of lines of code in C will go down, so the difficulty of finding a place to contribute will go down by that metric. On the other hand, I'd argue that it seems rather unlikely that literally all of the C code will be gone from git at least over the next couple of decades (and that's assuming that there's even a desire to rewrite it entirely, which doesn't seem like it's anywhere close to even being possible to discuss seriously any time soon), so it seems like the amount of difficulty will be so small that it's a bit silly to worry about it. Keep in mind that there's still not anything stopping new code from being written in C just because new code might also be possible to write in Rust. Right now, it's literally impossible to contribute Rust code to git, so if it becomes infinitesimally harder to contribute C code to make contributing Rust code possible, that's still a arguably a much larger increase in the net "contributability" of the git codebase, for lack of a better term.

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.

> I understand that it's a minor change in its current state. However, it is a fact that the long term goal is to port everything to rust. Once that goal is accomplished, rust will be required. So it is not at all a gross exaggeration. It's a prediction of the future.

Whose goal is this? I know that there's a perception of there being a loud, vocal contingent of people who have this goal in general, but is there anyone who actually is involved in git maintenance who has stated this intent? The proposal linked above states the following:

> As said, the entire goal is for us to have an easy playground that we can experiment on and develop the infrastructure incrementally without yet having to commit to anything.

> I'm mostly splitting out the topic of introducing Rust from the larger series that introduce it into xdiff so that we can focus more on the actual process of introducing Rust into Git and less on the potential features that we want to build on top of it.

My reading of this is that there are specific features that they at least want to consider using Rust for, and that having support for it in the build process is a prerequisite for that. That doesn't imply at all to me that they would want to rewrite all existing features in it, or to prevent new C code from being written for git after some point in the future. Even if there are some people involved with that goal, it hardly seems like that goal is shared by everyone who might be involved in that type of decision, and I'd argue that people wouldn't even have to be in agreement about that goal to be in favor of this step. I don't find it that hard to believe someone might want to allow using Rust for new features but generally be against the idea of rewriting all features in Rust.

Having written Rust professionally for six years and used it for around a decade, my experience is that there are surprisingly few prolific Rust programmers who seem to devote much time to thinking about trying to get existing projects to rewrite all of their codebase into Rust. It's much more likely that they'd just start an entirely new project that overlaps substantially with an existing one, although even then it's rare for the new project to ever get anywhere close to fully replacing the existing one (if that's even the goal); ripgrep might have wide adoption alongside grep, but grep isn't going anywhere, and I suspect that burntsushi would be one of the last people to suggest it would.

There's also a lot of significant work spent on improving Rust's ability to interoperate with other languages. Libraries made with bindgen (and cbindgen in the other direction) probably have done far more to ameliorate Rust programmers to using existing libraries in other languages than to expedite them being rewritten, and there are some popular wrappers that try to go beyond that and try to provide even more idiomatic wrappers for specific languages like pyo3 for Python, neon for NodeJS, and cxx for C++ (which was written by the same person who basically single-handedly created the current proc macro ecosystem in Rust alongside specific libraries utilizing it like serde and thiserror, so hardly someone who would have no motivation to try to have more code rewritten in Rust). If there are people making an effort being made to try to tell everyone to rewrite everything in Rust, there's just as much effort going on from people writing Rust to actively try to work with existing code in other languages, and their work is having far more impact than the first group.

I honestly can't help but wonder if the only reason the debate about rewriting stuff in Rust is still going on is that the people against it engage with it rather than just ignoring it as empty bluster. My hot take is that there's never been anywhere close to the critical mass of people with the skill and desire to put in the work that would be required to make it happen, and there likely never will be, so the debate been sustained on one side by a range from armchair quarterbacking to intentional ragebait, and on the other side by a range from misguided attempts to engage seriously with what's essentially always been just a meme to pearl-clutching at the idea that someone would dare question the status quo. Maybe there was an interesting philosophical debate to be had about the hypothetical merits of rewriting the world in Rust in the early days, but we're long past the point where there's anything useful left to say on the topic, so we'd all be better off by just collectively moving on and figuring out how things will play out in the real world. C and C++ are definitely not going anywhere in our lifetimes, and Rust has sufficiently proved that it can be used successfully in professional contexts, so the remaining questions are all going to be about tradeoffs between legitimate choices rather than jockeying to see who sticks around in a "winner-takes-all" ecosystem.