The conclusion slide appears at about 1:02:00 so you can skip there if you just want a four-sentence answer to the question posed in the title.
The first five minutes or so lead up to a rough definition of what he means by "Operating System" for the purposes of this talk, essentially systems software that abstracts some physical or virtual model of hardware and runs programs that use those abstractions. However, in addition to the privileged mode OS kernel he includes things like system libraries and services in the scope of the subject.
This is followed by a historical overview of various operating systems and programming languages — particularly systems languages — and how they shaped each other.
Finally, Rust is compared and contrasted with historical and incumbent languages and the systems developed in those languages.
Despite his enthusiasm about Rust, Bryan finds that rewriting extant OS kernels in Rust should not be the top priority. The Operating System as defined in the introduction includes firmware and user mode services that can benefit from Rust's memory safety even if the system core remains in C or C++. Since Rust interoperates well with other systems programming languages, there is no need for an all-or-nothing approach.
I don't think my summary does justice to the talk. Bryan's talks very often look at things from a historical perspective, which I and others quite enjoy. The rambly tangents are actually my favourite parts of a Cantrill presentation and the conclusions may feel rather mundane if taken on their own. If you don't enjoy the first minutes, you may need to adjust your expectations or simply decide this style is not for you.
I'll give it a watch and will summarize, because while i'm not always on board with the Rust hype (and therefore want to know more, to help eliminate my biases, one way or the other).
That said, i rather enjoyed Bryan Cantrill's talk from 2017, "Debugging Under Fire: Keep your Head when Systems have Lost their Mind • Bryan Cantrill • GOTO 2017": https://youtu.be/30jNsCVLpAE
So i wouldn't necessarily turn away from any of his videos just because of the sometimes humorous or not awfully serious tone.
Okay, so here's a slightly delayed summary (had to fix some prod issues):
- a discussion that the parent commenter took an issue with: "What's software? What's hardware? It's hard to answer that."
- essentially, an OS is a program that abstracts away hardware
- kernel: a piece of the OS that runs with the highest level of privileges, but only a part of the OS
- the OS as a whole includes libraries, daemons etc.
- expansion on the history of OSes and how we got to where we are now
- developing OSes isn't always lucrative, you don't hear about the innovative companies that didn't survive
- mentions of https://en.wikipedia.org/wiki/Second-system_effect
- a brief story about how trying to outsource the PL/I compiler wasn't a good idea
- the Unix approach was way more organic in comparison to PL/I, less of a waterfall
- a little bit about programming languages
- a little bit about the history of C and how it wasn't created the exact time as Unix
- some words about languages that now seem esoteric, like https://en.wikipedia.org/wiki/Language_H
- thoughts on the imporance of macros and the C preprocessor
- more about OSes in the 1990s
- languages like C++ and Java got more popular
- many of the OSes of the time suffered from the aforementioned second system effort, were overcomplicated
- oftentimes overcomplication also lead to great resource usage with little tangible benefit
- with the arrival of Linux, the C based OSes became more entrenched
- at the same time, the actual languages that focused on the ease of development (Java, Python, Ruby) also gained popularity, though in a different context
- software systems in 2010s
- without a doubt, it's nice to be able to use higher level abstractions
- Node.js got surprisingly popular due to a high-performance runtime with the aforementioned benefits
- Go was also developed, though its garbage collector is mentioned as a problem here, because it makes C interop harder
- a bit of elaboration about GC and the problems with it, how easy it is to have a reference into a huge graph
- essentially, it has its use cases, but at the same time there are problems it's just not suited for (a certain class of software)
- how Bryan got started with Rust and a bit about it
- initially he didn't want to go back to C++, because of a variety of past issues
- he got increasingly interested in Rust and its potential benefits
- curiously, there is a category of people who are curious about Rust, but haven't actually written any
- it's nice to have a language that's built around safety, parallelism and speed
- more about Rust
- its ownership system allows for the power of garbage collection, but the performance of manual memory management
- being able to determine when a memory object is no longer in use and being able to do so statically is like a super power
- the compiler itself just feels really *friendly* by pointing you to directly where the problems are
- composing software becomes easier all of the sudden, when compared to C, since it's hard to get it right there
- going back to C or porting C software can actually be somewhat difficult because of unclear ownership
- some of the Rust performance gains are actually from good implementation of language internals, like them using b-trees
- algebraic types are also nice to have and the FFI in Rust is really well thought out
- there's also the "unsafe" keyword which allows loosening the security guarantees when necessary
- about OS development and Rust
- no-one cares about how easy OS components were to develop or how long they took to develop, everyone just wants things to work
- a bit of information about having to deal with failed memory allocations, design discussions, language features etc.
- lots of OS projects out there in Rust
- however, writing your own OS essentially forsakes Linux binary compatibility, so a lot of software won't run anymore
- you have to consider what is the actual advantage of rewriting existing software in Rust, safety alone might not be enough
- a callback to the fact that an OS is more than just the kernel! you could rewrite systemd in Rust and other pieces of software, however not all software is a good candidate for being rewritten
- firmware in user space (e.g. OpenBMC) could probably benefit greatly from Rust as well, in addition to just having open software in the first place
tl;dr - Rust is promising, yet isn't a silver bullet. That said, there are certainly domains and perhaps particular OS components which could benefit from the safety that Rust provides, especially because its performance is also good!
Haven't watched the video, but I recently watched Timothy Roscoe's OSDI keynote on operating systems and hardware [0], where he argues for the operating system to include all of the kernel, device drivers and blobs that manage the SOC. He points out that the system emerging from the interaction of these components is complex and essentially unarchitected.
After watching his talk, I wanted to figure out how a computer, say a Raspberry PI, _really_ works. And build an operating system for it. Maybe in Rust?
I highly recommend to take the time. First, I find Bryan's presentation style very engaging and fun to watch. The short recap on language history is also quite fun.
I also would not consider myself to be part of any Rust hype, but the language has sparked my interest once again.
My TLDR: Rust is a great systems language, however in-kernel C code in itself is very safe, its the ecosystem (drivers, firmware etc) around it that could benefit greatly from being rewritten in a safer language.
Any citation on that? Obviously it went through numerous people hours where many bugs were reported/fixed, but afaik it still contains plenty of race conditions, and whole other areas of bugs that are just being discovered through better static analysis programs, and any future code can easily introduce new problems.
It's around 0:56:12, AFAIK kernel dev has relatively strict guidelines regarding memory management. Cantrill also says that he considers the borrow checker less important if you only write code for a system that does not interact with other libraries, however as soon as you interact with others, things get messy on who owns what and when stuff should be free'd. Since the kernel is a sense a sealed system (ignoring kernel modules), the memory argument probably isn't that important anyway.
I totally agree regarding race conditions though, however I don't think Rust does anything to solve this.
