The Case for Rust (in the base system)

[hpnothp]

If code generator into Rust (or any other language) from, i.e., LLVM IR just like generating native binary codes is possible, rewrite would be realistic.

And by prohibiting UNSAFE blocks, errored out source codes can be considered mutually unsafe, means, Rust is not for the code or real rewrite (refactor) is mandatory to switch to Rust.

According to Amazon research - from: https://aws.amazon.com/blogs/opensource/verify-the-safety-of-the-rust-standard-library/

Today, the Rust standard library comprises roughly 35K functions, with approximately 7.5K unsafe functions, and 3K safe abstractions. The core library has 21K functions, with 7K unsafe functions and 1.7K safe abstractions.

So prohibiting "unsafe" blocks is not possible without banning Rust Core library and Rust Standard library - which is obviously impossible. Same applies to Rust in Linux kernel - all interfaces are plagued by "unsafe" blocks where only comment explains (or rather believes) that it is "actually safe" - but that's not proof.

Just look yourself into latest string source and count all "unsafe" blocks there: https://doc.rust-lang.org/src/alloc/string.rs.html#360

So Rust is no way safer than Perl, Python, Java, Go or any other language with managed memory.

 

[msplsh]

Not to pick this nit too much but if you compartmentalize where the unsafe memory management is located, you can then focus on eliminating it vs throwing up your hands and being like "it's impossible, why bother."

 

[kpedersen]

Not to pick this nit too much but if you compartmentalize where the unsafe memory management is located, you can then focus on eliminating it vs throwing up your hands and being like "it's impossible, why bother."

In many ways yes, but there are so many ways this mechanism falls apart. It would be like putting some unsafe blocks inside malloc and free. Sure, the unsafe code is localized to free but the actual error is in the more complex logic that calls the free. The dangling pointers held by Rust's RAII mechanisms due to the underlying data being stripped are propagated through the entire codebase.

 

[msplsh]

I think that's an overgeneralization, considering malloc and free contain the entire set of memory management in C

 

[kpedersen]

I think that's an overgeneralization, considering malloc and free contain the entire set of memory management in C

Absolutely. It was an extreme example. You can go finer grain, but the issue is still there. Memory errors are rarely contained to single sections of code.

Arguably, for C++ you could make it flag up any C function as "unsafe" and you will have achieved similar to what Rust has.

 

[msplsh]

Not really. What's "new"?

 

[kpedersen]

Not really. What's "new"?

As per the creator. "operator new and operator delete shouldn’t be in application code"

Just like you don't use new and delete equivalents like std::alloc::alloc() in Rust.

They are there if needed, to interface with legacy codebases (Just like Rust can). But new and delete were never exception safe and even the oldest static analyzers would flag them up as such.

This is different to Java where new is commonly used (and where this mistaken idea probably comes from). Check out a C++ codebase like this and you will see there are no deletes and the only new is placement new (equivalent to Rust's ptr::write). Even in an allocation heavy environment like that JSON library, operator new is correctly avoided. (Though they do use malloc to avoid C++/Rust style construction performance overhead).

This is actually my favorite interview question to candidates. It tells me if they are actually a C++ developer or if they are a .NET/Java developer "trying their hand" at C++. They won't fail the interview just for this... we have loads of Java projects too!

 

[msplsh]

Ok, I haven't written C++ using the autopointer or whatever they replaced it with because I thought that was just as deranged (I was right! They got rid of it!) as the people complaining about Java verbosity and decided at least C didn't hide everything in a runtime, but placement new? Nothing on the heap, hunh? Did we toss out RAII while I wasn't paying attention? TBH, this is why I don't take C++ seriously: Never get a new tool, just hold the old tool differently and maybe tack something on to it. I have way more respect for "ok, those ideas were bad and we're breaking from them by making something new."

 

[kpedersen]

Ok, I haven't written C++ using the autopointer or whatever they replaced it with because I thought that was just as deranged (I was right! They got rid of it!).

It lives on a unique_ptr. Basically auto_ptr with move semantics. You can even typedef/using it. It was a design that was actually pretty good, but now its fixed to be usable in standard containers. std::vector<std::auto_ptr<T> > is invalid due to its simplistic ownership semantics. Of course a std::list<T> is better but can't work with inheritance due to slicing. All of this is solved by Java by putting *everything* on the heap.

as the people complaining about Java verbosity and decided at least C didn't hide everything in a runtime, but placement new? Nothing on the heap, hunh? Did we toss out RAII while I wasn't paying attention?

Placement new allows you to construct into raw memory (both stack or heap). It is mainly for container writers and again, is rarely seen in application code. The equivalent Java (or Rust) to allocate into existing memory is not elegant to say the least.

TBH, this is why I don't take C++ seriously: Never get a new tool, just hold the old tool differently and maybe tack something on to it.

I agree that tacking stuff onto old tools is a good approach. This is precisely why I like C++, Objective-C and Objective-C++. Though C++ isn't really a new tool. It was almost released to consumers at the same time as C.

I have way more respect for "ok, those ideas were bad and we're breaking from them by making something new."

Sometimes a clean break is good. I don't think Rust's approach of binding against C libraries for allmost all of its functionality is sustainable. RedoxOS is where I think it might stand a chance.