Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

slideshare.net

Post reply on HN
Print view View original

81–90 of 144 posts

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

#81

Post by m0th87 »

discoball wrote: post #42

Nim is realtime garbage collected and compiles to optimized C and it can use the C ecosystem of libraries and tooling. It also produces smaller binaries than Rust and is faster for most tasks.

Despite what the Nim documentation says, realtime and garbage collection are mutually exclusive (unless you count non-deferred reference counting and give up on collecting cycles.) Setting maximum pause times doesn't change the fact that the garbage will be collected nondeterministically, which is a problem for kernels.

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

#82

Post by red75prime »

orbifold wrote: post #69
fredmorcos wrote: post #56

Earlier quoted context omitted.

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

Maybe just to elaborate: In contrast to rust, C++ is a standard defined language, with >3 mature and competitive implementations, two of which (clang / microsofts compiler) provide excellent tooling and support for refactoring (clang in particular) beyond any other language in existence (maybe except Java). Instead of looking at cppreference.com, maybe consider browsing https://github.com/isocpp/CppCoreGuidelines/blo…

> the lean theorem prover

Which has its share of segmentation faults (around 50 closed issues) and unknown number of corner cases with silent memory corruption/data races.

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

#83

Post by 4ad »

twtw wrote: post #36
exabrial wrote: post #29

Earlier quoted context omitted.

Hilarious example of why English is a terrible language: I meant for the the pronoun to refer to Joyent, not [necessarily] the CTO.

Operator errors do not indicate the quality of a language.

Funny, when it comes to programming languages like C, operator errors are very much blamed on the quality of the language.

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

#84

Post by jcranmer »

protomyth wrote: post #78
jcranmer wrote: post #45

Earlier quoted context omitted.

>> in-kernel C tends to be de facto safe > This is a bit of a stretch. Not "a bit;" quite a lot of a stretch. What makes C problematic is that the language is specified in terms of an abstract machine that looks absolutely nothing like real hardware, and executing instructions that make no sense in the abstract machine but are very well-defined in the real hardware is liable to cause problems for the optimizer in the…

What makes C problematic is that the language is specified in terms of an abstract machine that looks absolutely nothing like real hardware, and executing instructions that make no sense in the abstract machine but are very well-defined in the real hardware is liable to cause problems for the optimizer in the compiler. Is there a language (other than assembly) that would have a closer model to the hardware?

To my knowledge, there isn't any language that really tries to be the kind of "portable assembler" that people try to shoehorn C into. There just really isn't the demand for it, since trying to be a portable assembler requires trading off fidelity to hardware for optimization, and most people would rather have faster code than more accurate hardware representation.

The internal IRs of compilers (such as LLVM IR or GCC GIMPLE) is likely to be much more accurate to hardware (and the ones I called out are indeed so). It's debatable if you want to actually call these non-assembly languages, though.

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

#85

Post by [deleted] »

m0th87 wrote: post #81
discoball wrote: post #42

Nim is realtime garbage collected and compiles to optimized C and it can use the C ecosystem of libraries and tooling. It also produces smaller binaries than Rust and is faster for most tasks.

Despite what the Nim documentation says, realtime and garbage collection are mutually exclusive (unless you count non-deferred reference counting and give up on collecting cycles.) Setting maximum pause times doesn't change the fact that the garbage will be collected nondeterministically, which is a problem for kernels.

[deleted]

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

#86

Post by tom_mellior »

arcticbull wrote: post #58
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…

> Rust can be faster than C in the general case because of the optimizations permitted by, among other things, strict aliasing rules.

Sure. The same is true for Fortran, for example. It's just that the few benchmarks of Rust vs. C I have seen so far all seem rigged in one way or another.

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

#87

Post by jcranmer »

jonathanstrange wrote: post #77
arcticbull wrote: post #58

Earlier quoted context omitted.

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

Any dynamic memory allocation lacks determinism, which is why in high integrity systems it often forbidden to dynamically allocate memory. As for Rust can be faster than C, well, people said the same about Ada but it rarely is the case so I wouldn't hold my breath for Rust either. After all, those languages use the same backends - GCC in the case of C & Ada, LLVM in the case of C & Rust. But it's enough to as fast as…

> After all, those languages use the same backends - GCC in the case of C & Ada, LLVM in the case of C & Rust.

The killer flaw of C for performance is the pointer aliasing problem. C only has the very coarse-grained tools of strict aliasing (often disabled in large applications because it breaks code!) and restrict (which relies heavily on manual programmer annotation) to control these aliasing issues. Since Rust has the rule that you can only have one mutable reference to an object at once (and read-read aliasing issues don't matter), it can effectively automatically add in these annotations without relying on programmer annotation.

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

#88

Post by burntsushi »

gammagoblin wrote: post #28
jillesvangurp wrote: post #18

I think the question is wrong. People are already writing new operating systems in Rust just because they can. The question is whether we will end up using their efforts or whether we keep on going back to the same monolith kernels we have been using for the last thirty years or so. Whether it is NT, Linux, or any of the BSD kernels, they each have decades of history behind them. These will of course still be around…

>The question is whether we will end up using their efforts or whether we keep on going back to the same monolith kernels we have been using for the last thirty years or so. Whether it is NT, Linux, or any of the BSD kernels, they each have decades of history behind them. Please just... stop. You are using terms that you clearly don't understand the meaning of. What is a "monolith" from your point of view? Because I…

>> At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools,

> 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-the-same thing to the older C implementations. For example, ripgrep is neither GNU or POSIX compliant, and therefore it is not a re-implementation.

That ripgrep isn't GNU or POSIX compliant is indeed a distinction worth making, but certainly not in this context. You're taking on a very pedantic interpretation of "re-implementation" here that doesn't really matter to the general point. Specifically:

> At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, etc. A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc.

None of this requires any of the "re-implementations" to be 100% strict bug-for-bug compatible tools.

This general confusion comes up so often that I have a FAQ item for it: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

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

#89

Post by AnIdiotOnTheNet »

Animats wrote: post #76

I'd really like to see an open-source QNX-type microkernel in Rust. Everybody is re-implementing early Unix in Rust, but that's not a good model. The great thing about the QNX model is that the tiny kernel barely changes from year to year, because everything is outside it and not very trusted. So it approaches being totally debugged. L4 is too low-level - you have to run another OS on top of it, usually Linux. QNX of…

> QNX offers a POSIX interface.

You say that like its valuable. POSIX has a lot of problems, if you're going to go through the trouble of throwing away a mature kernel like Linux with all the hardware support that brings, you may as well also ditch your POSIX baggage.

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

#90

Post by lucozade »

m0th87 wrote: post #81
discoball wrote: post #42

Nim is realtime garbage collected and compiles to optimized C and it can use the C ecosystem of libraries and tooling. It also produces smaller binaries than Rust and is faster for most tasks.

Despite what the Nim documentation says, realtime and garbage collection are mutually exclusive (unless you count non-deferred reference counting and give up on collecting cycles.) Setting maximum pause times doesn't change the fact that the garbage will be collected nondeterministically, which is a problem for kernels.

Those are 3 orthogonal(ish) things.

Realtime just means that actions triggered by event occur in an explicitly bounded time. It doesn't usually mean that they occur in the same time. So a GC with bounded pause could be used in a realtime system assuming you could guarantee the explicit bounds.

I can't comment on whether or not this is true of Nim and pause time probably isn't sufficient (depends on how it's defined) but they're not mutually exclusive.

And most kernels don't need to be realtime unless they are realtime kernels.

Having said that, of course, the vast majority of GC systems are most definitely not realtime, or anywhere close. But that's just actually true, not theoretically true.

Post reply on HN