But that's exactly my point. The OP asks, why not a language "better" than C, full stop. That's the wrong question. There are many languages better than C according to someone, but terrible to write a kernel in. Better than C is a terrible metric. The momentum behind rust isn't because it is simply better than c in some unspecified way.
To actually answer your question, i think its both political and technical. Rust is on an upswing. In any political movement,momentum is important. Ada is old news, it doesn't have that excitement around it that is critical for a political movement to galvanize its supporters. From a technical perspective, it seems like support primary comes from people who hate memory safety vulns. That's the impetus but lots of languages prevent that. The aspects of c that make it popular are (syntactic) simplicity and full control. Rust has really good PR to suggest that it does the memory thing very well, well still valuing the other factors that make c popular. Other languages tend to try and improve a lot of things or stray further from the c path, which make it seem like bigger switch with higher costs.
So in conclusion, i think rust does just enough to have a benefit people consider "worth it" (relative to switching costs) well not straying too far from c values which makes switching costs low. It also came at the right time, has momentum and good propaganda, which is critical for any political "movement"
Not taking anything away from this specific project though as it's a hobby project. Just making a wider point about the calls for deprecating C and C++ in GNU/Linux.
I'm all in favour of a "rewrite it in $SAFE" but the risk adverse part of me feels like Rust is a combination of too young and lacking in formal guarantees to consider the massive undertaking we're asking here. Particularly when you consider this is going to be a multi-decade project and one that we can't trivially switch to another language if we regret that decision part way. To give context to that point: it's already been 30 years of C with Linux, longer if you count BSD or Unix. So the commitment we're asking from Rust is massive.
Maybe I'm being overly cautious. Unfortunately I've found the discussions on the topic are usually underwhelming in terms of people being prepared to honestly answer the hard questions about Rust's readiness for such a critical role. And that has left me feeling more nervous than reassured that the whole thing isn't just a fad.
But as bawolff said, the main issue is moving towards safer tech. If Ada had good enough momentum, we'd be discussing Ada in the kernel instead. C++ has been rejected from Linux, leaving Rust as the only kernel-capable language with enough momentum, so Rust it is.
That has nothing to do with memory safety though let alone Rust specifically. What we need is a smarter way to manage authentication (non-persistent session cookies and usage a password manager to handle the log in is a step in the right direction).
To some degree, it doesn't matter how Rust acquired the energy; if you want to hop the gap, gotta hitch a ride on the highest energy wave.
Also neither OCaml nor D make any attempts at stopping data races, which is sort of a selling point of Rust. Ada/SPARK, I suppose do, but I don't know at what cost; I'm sure though Rust syntax will feel more familiar to C developers than Ada, even if a lot of Rust syntax comes from ML. But it has {} :).
I think that is its differenciating property.
I cannot emphasize it enough: if people really wanted so much safety, they would have chosen Ada/SPARK. I also find Ada easier to read and write than Rust. I know C, OCaml, Erlang, Forth, and Factor, yet I have difficulties with Rust. Am I really that bad of a programmer? Welp, at least I know Ada and I can write actually super safe stuff. :P
> The goal is to allow a pattern of use of pointers that avoids dangling references as well as storage leaks, by providing safe, immediate, automatic reclamation of storage rather than relying on unchecked deallocation, while also not having to fall back on the time and space vagaries of garbage collection.
You might also want to read about how Ada/SPARK does safe pointers. An older article that may be of interest: https://blog.adacore.com/using-pointers-in-spark. Check out https://docs.adacore.com/spark2014-docs/html/ug/en/source/ac... as well, there is a section named "Deallocation". GNATprove guarantees the absence of memory leak (pretty good, right?) in the code shown under that section.
This is how the code looks like:
with Ada.Unchecked_Deallocation;
procedure Test is
type Int_Ptr is access Integer;
procedure Free is new Ada.Unchecked_Deallocation (Object => Integer, Name => Int_Ptr);
X : Int_Ptr := new Integer'(10);
Y : Int_Ptr;
begin
Y := X;
Free (Y);
end Test;
test.adb:8:04: info: absence of memory leak at end of scope proved
test.adb:9:04: info: initialization of "Y" proved
test.adb:9:04: info: absence of memory leak at end of scope proved
test.adb:11:06: info: absence of memory leak provedThat seems quite unlikely given the lack of syntax for lifetimes. It's still in theory possible to infer them, but that would result in API instability and hard to decipher error messages.
Can you for instance have a function that given a reference to an hash table and a reference to a key returns a reference to the value corresponding to a key equal to the given one? (this requires the return value lifetime to be the same as the hash table lifetime, while the search key lifetime is unrelated)
Can you refactor code that takes multiple parameters by reference to taking by value a single structure including those parameters as fields with independent lifetimes?
Ada never used GC, although Ada 83 allowed for optional implementation, that no compiler ever made use of, thus it was removed from Ada standard in the 2005 revision.
You have to structure the program in a way to make it happy, though. Which is not zero runtime overhead compared to a wild west program.
I think you're on to something here.
The OP's question might be unpopular on HN (who largely seem to be in love with Rust) but it's a valid question and not one that's at odds with Rust either.
To paraphrase his question: "Why is there more momentum behind Rust to replace C than there has been before?"
> So does perl, there's more to the debate than if a language has some "benefit".
It's pretty clear that Perl isn't a systems language nor performant enough to write a kernel even if it were a systems language. So bringing that up is rather silly. And you don't even answer the question of "what is more to the debate than "some benefit".
Zig, D and Ada might all be perfectly valid languages to rewrite Linux in. So might OCaml and countless others. But it is Rust that has the momentum. As someone who can program in > dozen different languages, I too have found the momentum behind Rust a little unusual and I can't really put my finger on why it has proven so popular when others have, relatively speaking, failed. There are aspects of Rust that I like but I don't find it an order of magnitude better than Ada, OCaml nor Zig.
So the question remains open, what has changed that all of a sudden the time is right to rewrite Linux?
I wonder if a large part of Rust's success isn't down to the language per se but rather down to it emerging just as C++ was finally reaching that critical mass point where developers are fed up with it's complexity and ready to jump ship. With the other languages either peaking too early or simply lacking enough corporate sponsorship for the mainstream to adopt. Maybe the syntax has a part to play too where Rust looks more familiar to new C/C++ developers in a way that Ada and OCaml do not.