Hacker News Reader

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

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"

While I have no issue with people picking languages for personal reasons, if we are going to start presenting RIIR (Rewrite it in Rust) as a technical argument then we need to move past the "it has momentum" part of the argument because trends have a habit of changing (as you've acknowledged yourself).

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.

Well i did say that's a political reason not technical, and the question was why is RIIR a thing, not list some technical reasons why rust is great.

Fair enough. I just worry that this momentum is a little premature and we'll end up creating as many problems as we solve. Rust is still quite a young language and while it has already proven itself it has also already taken on a lot of complexity despite its age and gone through several iterations of breaking changes too. I'm not entirely convinced that in 10 years time Rust wont end up as painful to audit as C++ is now. While Rust does offer some memory safety guarantees out of the box, that still depends upon the abstractions not needing to fallback to `unsafe` -- which isn't going to be avoidable with kernel development. And as the complexity of the code base and language semantics grow, the developers ability to audit `unsafe` is going to be will diminish in competency. And that's without even addressing the risk of introducing new bugs as part of the rewrite. Taking those points into account, I can't help feeling there's a little bit of "the emperors new clothes" going on here were the promises being made are greater than the reality.

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.

Maybe to try to answer some of OP's question. Rust is past it's "1.0" release. Other alternatives are also plenty viable and I would love to see more technical conversation considering them, but I think Rust is viewed as more mature (not a 'Rust' user here). An example, I find Zig really interesting. However, I think even the main creator of Zig says it is not production ready yet (however it is getting closer to that '1.0' release). D may be the only one I know (besides Ada) that has that level of maturity.

Also, for people who hate memory safety issues, does it really matter which language? Rust is a solution with momentum. For the people motivated by that concern, fighting over language choice is a distraction.

Not necessarily. Language does matter as it is a construct that forms how problems are thought about. One thing I like about D is how it is much more multi-paradigm. I would like to see some more analysis of using D in Linux.

For user land it doesn't matter at all as people can mix and match whatever languages they want as long as there is an ELF entry point into the runtime. However rewriting the kernel, which is what this discussion is about, is a whole other matter.

Userland is worth fighting for too. https://imgs.xkcd.com/comics/authorization.png

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.

> Userland is worth fighting for too. https://imgs.xkcd.com/comics/authorization.png

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

We are stuck in a local minima with C and C++. Rust is a particle with high enough energy to tunnel through the barrier to a lower, safer energy level.

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.

I'm not sure that's fair because most of alternatives suggested, eg OCaml, D and Ada, are all a hell of a lot more mature than Rust.

As much as I like OCaml, I doubt we'll ever see a tracing garbage collected language in the Linux kernel.

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 don't know Zig, Ada and D very well, but isn't Rust the only language that can guarantee huge amounts of safety with zero runtime overhead due to the burrow checker?

I think that is its differenciating property.

> zero runtime overhead due to the burrow checker

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.

Nope, Rust still cannot provide formal proofs Ada/SPARK style, and using String, Vec, Rc, Arc, RefCell imposes just runtime checks as other type safe systems languages.

No, you can guarantee much more with regarding to safety using Ada/SPARK. I have a table somewhere. So if you want safety guarantees, it is Ada/SPARK all the way. Check out https://blog.adacore.com.

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

"I think Ada/SPARK needs to seriously be considered for a lot more projects. Maybe we need better tooling, but still".unwrap().unwrap().unwrap()

It has a package manager now! :D Anyways, there are some things that could make Ada/SPARK more desirable but it has nothing to do with the language itself. :(

No, Ada has no lifetimes and borrow checking and thus cannot possibly offer the same expressiveness as Rust while supporting safe memory deallocation without garbage collection.

That is why SPARK exists, and RAII offers safe memory deallocation.

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 may want to read https://www.adacore.com/uploads/techPapers/Safe-Dynamic-Memo.... It talks plenty about lifetimes and borrowing. It even mentions Rust (and ParaSail).

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

GNATprove output:

  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 proved

Does that proposal allow to express anything that can be expressed in Rust?

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

A lot of those guarantees are only available in the alloc-free subset of Ada, which make them much less attractive. The devil is in the details, making Ada guarantees not always better than Rust ones.

Hm, so can Ada/SPARK bring the same memory safety/data race guarantees to the table as Rust, yet not being more difficult to express and maintain those guarantees? I'm not familiar with the language.

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

I think you're on to something here.