Is it time to rewrite the operating system in Rust? [slides] • Hacker News Board

Re: Is it time to rewrite the operating system in Rust? [slides]

#51

Post by throwaway_se099 » Thu, Nov 08, 2018, 3:50 PM UTC

gammagoblin wrote: post #43

spuz wrote: post #35

Earlier quoted context omitted.

> Yes, but some (e.g. ripgrep) don't actually do the same thing as the programs they are supposed to "re-implement". Most Rust "re-implementations" don't actually re-implement programs, they are new programs doing a similar-but-not-quite thing to the older C implementations. For example, ripgrep is neither GNU or POSIX compliant, and therefore it is not a re-implementation. Is there a reason that command line tools c…

>Is there a reason that command line tools cannot be re-implemented in Rust and maintain GNU and POSIX compliance? No, there isn't, but what "re-implementations" that I know of don't even try to do that. >If not then the fact that ripgrep is not compliant is irrelevant to the larger point that Rust command line tools could eventually replace existing C command line tools. Of course it's possible. You can go ahead and…

> C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that

It does, it's called "#[no_mangle]", and together with an extern "C" fn declaration you get a non-mangled function directly callable from C.

Re: Is it time to rewrite the operating system in Rust? [slides]

#52

Post by rwmj » Thu, Nov 08, 2018, 3:50 PM UTC

tom_mellior wrote: post #30

Bit of a mixed bag. Slide 12: > Go etc. are garbage collected, making interacting with C either impossible or excruciatingly slow. "Impossible" is, of course, a lie. "Excruciatingly slow" may be the case, though it depends on the kind of interaction you are looking at. Without any context, this statement is overly general. Slide 14 can be taken out of context and misrepresented as showing that "Rust can be faster tha…

We have tons of production OCaml code interacting with C and it's not "excruciatingly slow" at all, in fact it's very fast indeed.

Re: Is it time to rewrite the operating system in Rust? [slides]

#53

Post by taeric » Thu, Nov 08, 2018, 3:56 PM UTC

rwmj wrote: post #52

tom_mellior wrote: post #30

Bit of a mixed bag. Slide 12: > Go etc. are garbage collected, making interacting with C either impossible or excruciatingly slow. "Impossible" is, of course, a lie. "Excruciatingly slow" may be the case, though it depends on the kind of interaction you are looking at. Without any context, this statement is overly general. Slide 14 can be taken out of context and misrepresented as showing that "Rust can be faster tha…

We have tons of production OCaml code interacting with C and it's not "excruciatingly slow" at all, in fact it's very fast indeed.

The problem with many of these "very fast indeed" claims, is that they usually compare to not interfacing with C at all.

That is, how much is the overhead of the call from OCaml to C? Not just how much faster did the entire system get.

My hunch is that it is still quite favorable.

Re: Is it time to rewrite the operating system in Rust? [slides]

#54

Post by taeric » Thu, Nov 08, 2018, 3:57 PM UTC

skocznymroczny wrote: post #48

orbifold wrote: post #44

A bit surprising that he doesn't mention any other C++ based kernels such as https://github.com/l4ka/pistachio/ and most of the fuchsia code base except for the lk micro kernel. In my opinion fuchsia points towards where things are going multi-language implementations (mostly c++) with an interface description language for interfacing components. From a point of view of postmodern c++, rust has little to no advantage…

"can be very safe if used correctly" the same bit applies to C, and we all know how it's working out

What we don't know, is how it would have worked out if we didn't have C.

There is also a bit that most of the bad security failures are not as sophisticated as the ones we mostly talk about. (Ironically, of course, the widest vulnerability lately was at the CPU level...)

Re: Is it time to rewrite the operating system in Rust? [slides]

#55

Post by twtw » Thu, Nov 08, 2018, 4:00 PM UTC

nicoburns wrote: post #41

twtw wrote: post #33

Earlier quoted context omitted.

> wasm is also going that direction Genuine question: why would WASM in the kernel make any sense at all?

Security. WASM is sandboxed by design.

Many things are "sandboxed by design." Few things are true sandboxes.

I'm very skeptical of the idea of throwing out virtual memory and process isolation to depend instead only on software sandboxes.

Re: Is it time to rewrite the operating system in Rust? [slides]

#56

Post by fredmorcos » Thu, Nov 08, 2018, 4:01 PM UTC

orbifold wrote: post #44

A bit surprising that he doesn't mention any other C++ based kernels such as https://github.com/l4ka/pistachio/ and most of the fuchsia code base except for the lk micro kernel. In my opinion fuchsia points towards where things are going multi-language implementations (mostly c++) with an interface description language for interfacing components. From a point of view of postmodern c++, rust has little to no advantage…

> From a point of view of postmodern c++, rust has little to no advantages left.

My entire adult life I've been writing C, I resisted Rust for a while but took the plunge when a C++ project came along that was in dire need of being reworked. I liked it, the language and the compiler and tooling around it helped me tremendously.

I assume you're aware of all the things that Rust statically guarantees for you, and I'll also assume you know the difference between language complexity and language implementation complexity (eg, the compiler or some other tooling):

I've been skimming through the C++ section of cppreference.com, and oh boy, there's heaps and heaps of... stuff... just stuff. The interplay between all that stuff is complex and it's hard to keep everything in mind. Keeping things in mind is important for correctness, or at least for having a reasonable amount of confidence in what you're writing. Information locality is also important for correctness, and C++ lacks both of those. I'll even go further and say that C++ is a write-only language, like a garbage bin of features and exceptions to each of those features. Rust has many many many clear advantages (and some disadvantages) compared to postmodern C++.

Re: Is it time to rewrite the operating system in Rust? [slides]

#57

Post by fredmorcos » Thu, Nov 08, 2018, 4:14 PM UTC

gammagoblin wrote: post #43

spuz wrote: post #35

Earlier quoted context omitted.

> Yes, but some (e.g. ripgrep) don't actually do the same thing as the programs they are supposed to "re-implement". Most Rust "re-implementations" don't actually re-implement programs, they are new programs doing a similar-but-not-quite thing to the older C implementations. For example, ripgrep is neither GNU or POSIX compliant, and therefore it is not a re-implementation. Is there a reason that command line tools c…

>Is there a reason that command line tools cannot be re-implemented in Rust and maintain GNU and POSIX compliance? No, there isn't, but what "re-implementations" that I know of don't even try to do that. >If not then the fact that ripgrep is not compliant is irrelevant to the larger point that Rust command line tools could eventually replace existing C command line tools. Of course it's possible. You can go ahead and…

I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is?

> C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that, nor does it have a stable ABI.

Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for.

> Then furthermore, a vast amount of effort has been put into these tools over the last years to ensure that they run on any *nix and any architecture, and even so they can be ported with relative ease.

That's actually a breeze in Rust, including cross-compilation (which is relatively painful in C/C++).

> For example, how do you suggest implementing glibc in Rust? You might argue "why would we need the C standard library when we're porting things to Rust", and the answer is that if you want to make a move towards rust, having a C library (particularly the GNU one, a lot of software depends on GNU extensions) is of utmost importance until that goal has been achieved.

There's work towards that: https://gitlab.redox-os.org/redox-os/relibc

Re: Is it time to rewrite the operating system in Rust? [slides]

#58

Post by arcticbull » Thu, Nov 08, 2018, 4:16 PM UTC

tom_mellior wrote: post #30

Bit of a mixed bag. Slide 12: > Go etc. are garbage collected, making interacting with C either impossible or excruciatingly slow. "Impossible" is, of course, a lie. "Excruciatingly slow" may be the case, though it depends on the kind of interaction you are looking at. Without any context, this statement is overly general. Slide 14 can be taken out of context and misrepresented as showing that "Rust can be faster tha…

> Slide 12:

IMO the big GC related issue is lack of determinism especially in the management of external resources. If you need that in a managed language you're forced into grafting reference counting on top which is particularly error-prone and unpleasant. Interacting with other languages can be slow, and bridging uncomfortable.

> Slide 14:

Rust can be faster than C in the general case because of the optimizations permitted by, among other things, strict aliasing rules. [1] The Rust language invariants are stronger and therefore the compiler can be more aggressive.

> Slide 16:

IMO you can do all that stuff in C with a combination of volatile pointer I/O and if necessary compiler intrinsics. I've done a lot of AVR programming and never dropped down to assembler because something wasn't available in C. I'd imagine the answer is really neither, just that some people are set in their ways and view ASM as 'faster' even though in reality LLVM would probably generate faster code by better taking into account instruction issue and data dependencies.

> Slide 19:

Unsafe Rust is unsafe because you can't express what you want in safe Rust. To your point, you can absolutely break things. The implicit contract is when writing unsafe sections that you are to maintain the invariants of the safe language at entry and exit of the block.

What makes safe Rust safer than C, though, is all the flagship features. You can detect data races across threads (and interrupts) statically. You can't write to and read from data at the same time. You have fully deterministic dynamic collection of resources. etc.

[1] https://robert.ocallahan.org/2017/04/rust-optimizations-that...

Re: Is it time to rewrite the operating system in Rust? [slides]

#59

Post by shmerl » Thu, Nov 08, 2018, 4:24 PM UTC

jbb67 wrote: post #5

no.

The reason for "no" given: "why completely replace what works already" paired with "fighting second system syndrome". It's not a real "no", but reasons why it's challenging. Aren't those always the case? It shouldn't stop something new from appearing.

Re: Is it time to rewrite the operating system in Rust? [slides]

#60

Post by cyphar » Thu, Nov 08, 2018, 4:29 PM UTC

OoooooooO wrote: post #38

eximius wrote: post #20

Earlier quoted context omitted.

The purported benefit would be to wrap all of the unsafe bits in safe wrappers and then have a less bug prone, more secure OS, I suppose. This would be, to put it mildly, quite difficult. Even then, unsafe code is sometimes not written correctly which brings the whole thing down. I, personally, still think it's worth it. I think efforts like Redox OS can teach us a lot about what we're doing and offer a chance to col…

Having only a small part of the code with unsafe means you only have to check only a small % of the code for UB/security holes and not the whole code base like in C. It just limits the places shit can happen and which need to be closely reviewed which alone is a big help.

It should be noted that you can have correctness bugs can occur in safe code if a Rust guarantee was violated in an unsafe block. This might seem obvious, but it does mean that when you hit one of these bugs you might start with debugging safe code and thus it's not as clean a separation as some Rust evangelists might imply.