Live data from Hacker News

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

slideshare.net

31–40 of 144 posts

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

#31

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…

> it will be a hybrid kernel effectively.

What do you mean by this exactly?

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

#33

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…

> wasm is also going that direction

Genuine question: why would WASM in the kernel make any sense at all?

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

#34
post #9

I think Zig would be better suited. See: https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Al...

This isn't quite what I was going to say, but it's close enough.

I think parts of an OS can and should be written in something rust like, however the whole thing should probably not be written in rust.

My personal thought is that C and C++ 98 era are bad, but they were what we needed at the time. Part of this badness was that you could do anything but exact facilities for specialized tasks had to be rolled from scratch. Libraries are possible, but not ideal (no namespaces for C and crazy header + recompile issues for both).

In order to replace C and C++ we need more than just one language, we need an entire family of languages that all have the specific features implemented to support their domain. Rust can probably be used in game programming, but Zig (or in theory eventually Jai) is being specifically made with that goal in mind so they will probably be better. Rust itself will be much more useful for applications that cant stomach managed languages (ie web browsers, etc) because that's what they are specifically building it to do. It's got high level features in a form factor that you would expect from C#/Java with low runtime and no GC.

We can probably write OSes in Rust or Zig, but ideally someone who really likes thinking about OSes will create a language specifically geared towards writing OSes that will be able to replace C.

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

#35

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…

> 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 cannot be re-implemented in Rust and maintain GNU and POSIX compliance? 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.

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

#36
post #21

Earlier quoted context omitted.

Among other things because he is also was part of the old Solaris team?

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.

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

#37
post #21

Earlier quoted context omitted.

Among other things because he is also was part of the old Solaris team?

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

use "which hired"

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

#38
post #20

These slides are quite high-level, so I've got to ask: what's the expected benefit of using Rust to implement a kernel? I somehow thought that nearly all interesting concurrency there would not fit into the paradigm of exclusive ownership. And if we are preaching for programming in unsafe Rust, then doesn't the message become less compelling?

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.

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

#39
post #21

Earlier quoted context omitted.

Among other things because he is also was part of the old Solaris team?

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

No, that's an example of someone not knowing the language very well. You should have written something like, "which is the company that...".

I can't think offhand of any language that's really better here in a sense of being more efficient, except probably Classical Latin which is horribly complicated and of course a dead language.

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

#40
post #35

Earlier quoted context omitted.

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

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

I think it's more that part od the attraction of rewriting the software is being able to upfate and improve the interface. If you want the old interface then the existing tools are usually perfecrly good.
Post reply on HN