Live data from Hacker News

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

slideshare.net

61–70 of 144 posts

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

#61
post #39

Earlier quoted context omitted.

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.

Czech allows you to specify that with a change of one letter depending on who you mean (the CTO - který, the company - která) - this depends on different genders of the two words, but is commonly used.

Yea, but the desirable language feature is a differentiation of Joyent and its CTO, based on Joyent being an adjective and CTO a noun, not on noun gender. (Did I set up the problem correctly?)

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

#62
Another important and related question to ask is what role Lua should play in writing drivers and applications on top of a new kernel. NetBSD started on this direction, but exactly what an operating system looks like when it leverages both systems-level and scripting-level programmability waits to be seen.

https://www.netbsd.org/~lneto/dls14.pdf

https://www.lua.org/wshop13/Cormack.pdf

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

#63

http://www.erights.org/elang/intro/index.html

Hadn't heard about this before, and it does look interesting. But not sure why you're linking to it in this context without comment? Especially since it seems to be a moribund project.

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

#64
post #53
post #52

Earlier quoted context omitted.

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.

There are two ways to call into C code from OCaml depending on whether the C code needs to allocate on the OCaml heap or not. If not (the so-called "noalloc" method) then it's just a call instruction. Otherwise it goes through a trampoline which IIRC uses a computed branch which probably kills branch prediction.

One other problem is that you cannot inline C into OCaml functions (which is generally true when mixing languages) so there's always some overhead even in the noalloc case, although it will be fairly small on modern CPUs.

Edit: https://camltastic.blogspot.com/2008/08/tip-calling-c-functi...

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

#65

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…

Primarily because it's written in C, the Linux kernel is currently in a full-blown security crisis. Nobody has credibly challenged the facts that Dmitry has laid bare, but at the same time, few people are motivated to fix the problem.

https://www.youtube.com/watch?v=qrBVXxZDVQY

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

#66
post #11

It'll be interesting to see how much use Rust gets within Fuchsia atop the Zircon microkernel.

The current state is, a few hundred thousands of lines, and Google hiring more Rust engineers quite aggressively.

I'm also excited to see how it turns out :)

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

#67

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…

> 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 for demarcating critical sections.

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

#68

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?

Exclusive ownership is only half of Rust's ownership story. The other half is borrows. Borrows actually fit very well with concurrency.

For example, if you have some data structure synchronized with a mutex, the mutex would be the owner of that data structure. Everything else would just get borrowed access to the data structure when it locks the mutex. Rust's borrow checker can make sure that you don't keep any references to that data structure after you have released the mutex so you can't access the data structure again without locking the mutex again. The mutex itself would need unsafe code, but everything using the mutex wouldn't.

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

#69

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…

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/blob/master/CppC... the Cpp Core Guidelines, this outlines a forward looking vision of how good c++ code should look like.

A lot of the static guarantees that rust provides can be modelled in C++ as well, see for example "https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidel.... Eventually someone will write a rust-style borrow checker as a clang analysis pass. Already now it is possible to express a lot of compile time properties cleanly in c++, with features such as constexpr lambdas, static_assert etc. Additional features such as Concepts / meta-classes / modules will improve C++ expressivity even further.

In short, yes C++ has a lot of stuff and everyone knows that it is hard to get a grip on all its features and misfeatures. But there has been a continuous effort to rectify and improve on its short comings. See for example https://clang.llvm.org/extra/clang-tidy/checks/list.html for a list of clang based code transformations that are able to automatically improve your c++ code.

The way I see it, just because of legacy reasons (I can interface with the majority of commercial software developed in the last 30 years (CAD, EDA software, Houdini, Abelton, ...)), tooling reasons (the rust compiler is a slow hot mess, compared to the state of the art c++ compilers) and momentum (there is a large incentive to continuously improve c++, because it is the foundation of a large fraction of commercial software out there) it is unlikely that rust will outcompete c++ in a significant way in the long run.

To close of with an example the lean theorem prover https://github.com/leanprover/lean, implemented in C++ handily beats the 20+ year old Coq prover. One of its key features is multicore support. If you look into its implementation details, the equivalent rust code would have to work around a lot of rust "safety" features, essentially because in many cases it is hard to convince a hardcoded heuristic like a borrow checker that whatever you are doing is safe. The static guarantees that rust gives wouldn't help you at all in correctly implementing some of the very involved algorithms a theorem prover kernel has to implement, while standing in the way of the implementation being straightforward. This leaves aside the obvious tooling (you can use Visual Studio, good profilers and debuggers) and integration (SAT checkers like Z3, LLVM backend) advantages.

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

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

That and performance. System calls have a lot of overhead when running in user space. You can dodge that when running as part of the kernel.
Post reply on HN