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

101–110 of 144 posts

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

#101

Post by bryanrasmussen »

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…

I believe seeing people re-implement libraries or popular command line tools is a behavior so common in rising in popularity programming languages that we might almost describe it as the default.

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

#102

Post by pjmlp »

paavoova wrote: post #98
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…

> A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. Depends on who you ask. Hipp on Rust in 2016: Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt. https://blog.regehr.org/archives/1292#comment-18452 > drivers written in Rust If you have to write inline assembly, and generally bypass Rus…

Because it is a big difference to have 100% of the code unsafe or just a set of visible code regions marked as such.

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

#103

Post by renox »

paavoova wrote: post #98
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…

> A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. Depends on who you ask. Hipp on Rust in 2016: Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt. https://blog.regehr.org/archives/1292#comment-18452 > drivers written in Rust If you have to write inline assembly, and generally bypass Rus…

Because C has big flaws (signed/unsigned automatic conversion, arrays without length) that Rust doesn't have. That said, you're right that I find Rust "story" that you should wrap unsafe operation behind safe APIs as something easier said than done.

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

#104

Post by rwmj »

arcticbull wrote: post #74
weberc2 wrote: post #67

Earlier quoted context omitted.

> MO the big GC related issue is lack of determinism especially in the management of external resources. This isn't a property of GCs per se; it's just that most GCs are optimized for throughput. Go's GC's pause times are on the order of 1ms, which might not be appropriate for every application, but it's probably fine for soft-realtime systems. There are a lot of other levers one could imagine as well, like semantics…

Lack of determinism is absolutely a property of GCs, by definition. You’re never 100% sure when a resource is going to get deallocated/finalized with absolute certainty. This is a dealbreaker for kernel type applications. For instance think of a network socket wrapped in a structure, you can’t rely on a finalizer invocation to close your file descriptor, you don’t know when if ever it will happen so you have to wrap…

Sorry but this is nonsense. There's a whole field of study of hard realtime garbage collection, and several implementations. Also it's easy even in ordinary GCs to determine when a resource will be freed in the cases when you need that, eg by providing a socket.close() method.

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

#105

Post by jungler »

ansible wrote: post #73
_urga wrote: post #9

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

I took a brief look at Zig. The top slogan for Rust is "fearless concurrency", which ties back into the memory model, mutability and sharing references. This helps you prevent (at compile-time) data races and other interesting bugs. I didn't see any support for that in Zig at all.

Last I checked Zig is more concerned about overflow conditions than Rust(numeric overflow, stack overflow, OOM etc.) and boasts features in that vein - so it competes, but not in the same territory.

If you are writing a kernel it's highly likely that you'll end up in a lot of scenarios where you have to use unsafe Rust, in which case Zig would be the better language for the task. Admittedly, it would be nice to have some of both, and they both have room to get better. But I see Rust as more of a "libraries and applications" centric setup, where it's the right thing for a web browser and the wrong thing for a device driver.

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

#106

Post by telotortium »

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…

What is the state of documentation on QNX? Is there sufficient documentation that it would be possible to write a QNX-compatible kernel from the documentation (plus access to a QNX machine, which has to be available somehow outside of industry, right?)?

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

#107

Post by paavoova »

pjmlp wrote: post #102
paavoova wrote: post #98

Earlier quoted context omitted.

> A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. Depends on who you ask. Hipp on Rust in 2016: Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt. https://blog.regehr.org/archives/1292#comment-18452 > drivers written in Rust If you have to write inline assembly, and generally bypass Rus…

Because it is a big difference to have 100% of the code unsafe or just a set of visible code regions marked as such.

Hyperbole, or do really believe every line of C is unsafe, in the literal sense, by default? Pray tell me what is the difference between

  // safe, tested, C
  ...
  // potentially dangerous C deemed thus for whatever arbitrary reason
And

  // "safe" Rust
  ...
  // "unsafe" Rust

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

#108

Post by weberc2 »

arcticbull wrote: post #74
weberc2 wrote: post #67

Earlier quoted context omitted.

> MO the big GC related issue is lack of determinism especially in the management of external resources. This isn't a property of GCs per se; it's just that most GCs are optimized for throughput. Go's GC's pause times are on the order of 1ms, which might not be appropriate for every application, but it's probably fine for soft-realtime systems. There are a lot of other levers one could imagine as well, like semantics…

Lack of determinism is absolutely a property of GCs, by definition. You’re never 100% sure when a resource is going to get deallocated/finalized with absolute certainty. This is a dealbreaker for kernel type applications. For instance think of a network socket wrapped in a structure, you can’t rely on a finalizer invocation to close your file descriptor, you don’t know when if ever it will happen so you have to wrap…

> I’m not criticizing pause times, but rather that you can’t rely on code inspection to identify the point of resource deallocation, which is pretty much the flagship feature of a GC :)

This is completely wrong. The flagship feature of a GC is memory management, __not__ filehandle management or management of other resources. While many GCs support finalizer hooks, most languages with GCs (Go, Python, etc) explicitly discourage using these to close file handles for specifically the reasons you cite. Automatic resource management is useful and desirable, but it's out of scope for GCs.

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

#109

Post by burntsushi »

paulddraper wrote: post #93
burntsushi wrote: post #88

Earlier quoted context omitted.

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

> a distinction worth making, but certainly not in this context. It is a worthwhile distinction, because the "re-implementation" talked about is often materially different, to the point that it no longer adheres to what little standardization there is. So realistically we are talking about a new product, or a radical evolution of an existing one. It and everything above it also have to change.

I commented because ripgrep was specifically brought up as a counter-example to the notion "At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C." What specifically, about ripgrep, removes it from consideration as evidence that Rust programs can operate in the same domain as C?

Consider this. If instead of

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

they wrote

> 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 popular command line tools, albeit with different interfaces that lack POSIX compatibility. A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc.

Other that the words being more precise for pedants, does the central point of the statement change? No, it doesn't.

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

#110

Post by comex »

gammagoblin wrote: post #96
fredmorcos wrote: post #57

Earlier quoted context omitted.

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

>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? I am primarily a systems programmer and write software for the petroleum industry in my country. I work with C++ and in some (rare) cases C, and I've been doing that for the past 4 years. I have my own WIP hobby unix-like microkernel project written in C as well. >Rust…

Based on [1], also full support for s390x (IBM mainframes), as well as support for SPARC, WebAssembly, and asm.js as targets only (you can't run rustc itself on them, but can cross-compile to them). RISC-V support was recently merged into master (not sure why it's not on that page). AVR and m68k (seriously) both have actively developed ports which are living in forks until they're ready to be merged.

Anyway, most of the work of porting Rust to new platforms is not in rustc itself, but rather porting LLVM to target that platform. This is bad in a way and good in a way. It's true that LLVM doesn't have as extensive a list of supported targets as GCC. However, for people developing new architectures and OSes, LLVM is often the go-to choice as the first compiler to port. For example, WebAssembly, eBPF, and AMDGPU are all supported in upstream LLVM at present, but not in GCC. On the other hand, RISC-V got GCC support first – but lowRISC also actively developed an LLVM backend, which is now upstream. [2]

Of course, C benefits from having multiple implementations; even on platforms that only LLVM has a backend for, you can just use LLVM's C compiler (Clang), whereas there's (currently) no Rust compiler with a GCC backend. I'd love to see that change in the future. Still, I'd say Rust target support is already pretty strong when it comes to the (embedded) platforms most people are doing new development for, and rapidly getting stronger.

[1] https://forge.rust-lang.org/platform-support.html

[2] https://www.lowrisc.org/llvm/status/

Post reply on HN