Even if you don't want to write a small OS, or don't want to learn rust, this is still an excellent resource for people wanting to learn about low-level OS and hardware details.
While I have no interest (nor time!) in writing an OS, just skimming through this you can see the author put a significant amount of work and polish into this.
I only skimmed, but the reason listed for using the nightly compiler (inline asm) just went away - inline asm was stabilized in 1.59 yesterday. However, there might be other reasons nightly is used, but I just saw this at a glance and thought I'd mention. Always better to use stable if you can.
Not all of inline asm is stable yet. The OS I work on at work still has to stay on nightly due to the bits that weren’t (and naked fns, which are apparently also on their way to stable in the nearish future.)
That said those are the only nightly features we use, staying on stable when you can is good, and many projects will be able to go to stable due to this, which is awesome. Been waiting on this for years.
Another book I found very helpful is Programming Rust [1], it expands on many concepts in the Rust book, the chapters on closures, iterators, collections, concurrency and async have very good explanations on how things work.
I highly recommend this book. I like "the book", but I did not find it was enough to write code in the real world. This book is longer, but more thorough.
Is it adequate to learn systems programming concepts? I already know the concepts of Rust, so I'd rather learn the former. It's fine if the book teaches both, though.
First: sadly, as common practice in the Rust books world, the book devotes 1/4th of the content to an utterly useless Rust guide. This is a marketing device (it's scammy for me, but it's arguable) to illude readers that they can read a book on learning Rust _and_ apply it in a certain context - but it's not possible to meaningfully learn Rust in 100 pages (not even in 400...). Those 100 pages would have been much better spent on-topic.
Rust language sections are also added to various chapters, which again, are redundant. Chapter 10 is entirely dedicated to multithreaded Rust programming, which is not systems programming.
Ultimately, it depends on what one exactly wants to learn and what they intend to do with it:
- if one wants to learn O/S programming, this is definitely not an O/S programming book; just the last two chapters are.
- if one wants to learn interfacing with system components (e.g. the network stack), especially with the intention of just reading without actually applying, this can be a fun book.
I personally don't think that the latter is systems programming, and I find the book misleading.
Author here, I hope that you have fun along your journey of learning Rust and systems programming. I recommend reading the free chapter to get a feel for Rust in Action.
It's intentionally different than most other text books. That means that each book in the Rust ecosystem complements the others. It's full of large worked examples from different domains. For example, you implement an NTP client, a database and a CPU emulator. It sacrifices idiomatic Rust for ease of learning. For example, it largely avoids higher-order programming to be accessible to as many people as possible.
Its role is primarily intended to teach you Rust, and to bring you up to speed with the jargon and concepts used in systems programming so that you can tackle dedicated material.
Let me know if you have any follow-up questions :)
I bought it when there was a kind of 2-for-1 deal with Rust in Motion a while back. I haven't spent too much time reading it though. From what I've browsed it seems competently written. It seems to cover the topics of typical interest in systems programming.
The other resources I would point you towards are Rust by Example:
Though the cookbook is kind of out-of-date. I'm actually in the process of updating / expanding it, but that effort is far from ready for presentation.
Please ignore all the gatekeeping marketing on that front page - it's very counterproductive and not at all accurate. IMHO all of this material should just be included in the standard Rust book, especially the sections about ownership and implementing Vec.
The Nomicon is an extremely useful resource because it "desugars" all the magic that is happening when you write Rust, so you are left with a competent understanding of what the compiler is doing on any piece of code you are looking at or writing.
Valuable reading for people wanting to build real systems in Rust, IMHO.
eh. no different than looking at a physical copy in book store and putting it back on the shelf or purchasing it. Delete it if you don't like it, buy it if you do. Morality != Legal system, although there is a little overlap but not a whole lot
What are the completeness levels of the various editions (edition-1, edition-2, and edition-3)? In which editions, if any, is the OS anywhere close to feature-complete (i.e. close to meeting a base set of pedagogical goals as a "small OS" for teaching purposes).
It's not clear to me from either the top-level docs or a skim of the update posts whether this effort is essentially a loose collection of (useful!) blog posts, or whether they close the loop to form a coherent and complete whole.
I've been playing with OS development for 2 years while writing MOROS[1] thanks to this project, it's such a great resource when you don't know where to start! With this and the help of the OSDev Wiki[2] you can really build your own toy OS.
This looks like an awesome resource, thanks for sharing!
Question: at the point my impression is that Rust is the consensus best overall systems programming language (assuming you’re starting something new). Is that just me or so others share that perception?
I’ve mostly done high level programming in my career but have wanted to eventually move into some barebones hardware stuff for fun. So I’m curious if Rust really is the best way to go these days (versus my old assumption that I should try to master C).
The other commenters already mentioned it but Rust is an alternative to C++, with a similar approach to "zero-cost abstractions". Meaning it provides you with the means to do systems programming at a higher-level and ignore low level details.
If you're learning low-level/barebones hardware programming, this is both a blessing and a curse. If you already know the low-level stuff, then Rust/C++ abstractions let you organize your code in a much nicer way, but if you're learning the low-level stuff, then those abstractions are actually in the way.
C won't get in the way, for better or worse, so it's definitely worth learning, at least to appreciate the safety valves Rust and C++ give you after you've repeatedly shot your own foot (specially Rust which learned from most of the historic mistakes of C++).
If you don't want to deal with C-nonsense, then Zig is probably the best alternative for that sort of low-level programming, it even has freestanding (no operating system) as a first class target, stack-traces and all.
FWIW you can easily write Rust in a C-like style, using primarily free-standing functions and structs. You can opt-in to “advanced” features (traits, enums, generics) as you see fit.
Interfacing with other libraries, is ofc, a different matter, but you can usually wrap the library API in your own functions to minimize this mismatch.
All of Rust's functions are available as "free-standing functions" because of how types work in Rust, and Rust doesn't have classes, just structs. So, as a consumer nothing changes.
if std::collections::HashSet::is_empty(&basket) {
... is perfectly legal Rust, it would just be more idiomatic to write:
if basket.is_empty() {
The availability of all functions as "free functions" is convenient when you need, say, a filter predicate, since of course std::collections::HashSet::is_empty is exactly what you wanted if what you wanted to express was the predicate "is this HashSet empty?" and in languages that aren't allowed to do this you'd need to pointlessly shuffle chairs around to achieve the same thing instead.
Universal Function Call Syntax goes both ways, Rust only offers to treat all of the things that seem like "methods" as free functions but not the reverse.
Under UFCS I could extend your Rust type by simply writing a new free function which matches the type, and this is in fact deliberately forbidden. (I can write the free function, but, doing so does not extend the type and I can't call it using the "method" syntax).
If you think what we're talking about amounts to having a . or not then you have no idea what we're talking about.
Rust's stdlib assumes not only that there is malloc behind the scenes, but that it is ok to panic. Rust itself, including its stdlib, lacks a stable ABI. It also assumes that lots of little allocations and deallocations with a single owner is a valid memory pattern, and that writing directly to specific memory locations is something you never want to do. These are all wrong assumptions for someone writing baremetal. Look up abi_stable and no_std.
Obviously for embedded use cases you’d not want to use std. it’s why we have core. If you want a stable ABI, you can also easily offer a repr(C) interface. I don’t know what to tell you, plenty of people use Rust successfully for embedded programming.
Of course they do, I never claimed otherwise. People also successfully use C++.
If you're learning, however, you know have to understand why you can't use generics (monomorphisation means you're not getting a stable ABI), why you shouldn't use native tagged unions and instead should write your own with unsafe (for total control of how the tag is handled), why you can't use the standard library, why you need to tag most things with repr(C), why the standard ownership patterns the borrow checker beat into you are in the way when writing your own allocator (with plenty of unsafe). Do you see my point?
Both Rust and C++, when writing baremetal, ask you to ignore how to write idiomatic code in their respective languages. This is fine for experienced devs, who will make good use of the additional features for abstraction, but not for newbies IMO.
C and Zig, on the other hand, do not have this problem, as idiomatic C barely uses its standard library (which is garbage anyway) and idiomatic Zig is designed to work baremetal, including the standard library. I certainly don't recommend using C for new developments in most cases, but for learning, well, you need to learn it anyway, even if you're using Rust baremetal. It's effectively what you're writing, albeit with lots of repr and unsafe strewn around.
In addition to what other people have said, I do want to make this point: Rust (more specifically the unsafe core) probably works slightly better as a "portable assembler" than C does. For example:
* Rust doesn't have volatile variables, you use volatile intrinsics on the loads and stores.
* C declares that arithmetic on 'char' and 'short'-sized variables gets promoted to 'int'; Rust actually has proper u8/u16 arithmetic support.
* Rust supports something akin to multiple return values via tuples, which means you can actually get operations like checked-overflow arithmetic supported in the core language, unlike C.
Rust's Wrapping integer types even behave the way "integers" natively work in your CPU rather than, as most programmers want and most languages try somewhat to deliver, behaving like the integers you learned in school on that infinite number line.
Even though this looks like it must surely be some frightfully complicated object-oriented nightmare, Rust's types only exist at compile time, so at runtime (my illustration was constant, but with real variables) this would just to be a 32-bit register doing normal CPU stuff. The optimiser is like "Yeah, Wrapping is how the CPU works anyway" and gets on with it.
Now, on one hand, this seems like a very clumsy thing to write. But then on the other hand, did you actually want CPU-style wrapping integers? No? Then the ones you actually did want are easy to work with in Rust, but don't kid yourself you wanted a "high level assembler" if you can't even handle modulo arithmetic.
> at the point my impression is that Rust is the consensus best overall systems programming language (assuming you’re starting something new). Is that just me or so others share that perception?
I think I'd probably agree with that impression. It's the route I've taken into "systems programming", and I don't regret it at all. The big advantage of going Rust-first for me is that C and C++ have so many unspoken rules that you need to follow in order to avoid security issues and hard to debug errors, whereas Rust codifies most of those as compiler errors. That makes it a lot more accessible for the beginner to learn not just the basic syntax, but a best practices and good habits.
C and C++ are still the mainstream at the moment, but I think they've peaked and would expect their popularity to wane over the next 10-15 years. On the other hand, Rust has only just hit the mainstream in the last year or two, so there's still a few missing pieces and adoption is not yet that high, but I think it's by far the best intro low-level language overall.
> The big advantage of going Rust-first for me is that C and C++ have so many unspoken rules that you need to follow in order to avoid security issues and hard to debug errors, whereas Rust codifies most of those as compiler errors. That makes it a lot more accessible for the beginner to learn not just the basic syntax, but a best practices and good habits.
Yes, I agree this is the big advantage for me too. Rust allows mediocre devs to build more ambitious systems than they would have otherwise attempted in other languages. You can certainly build anything you want in C++, but from my experience due to the number of, as you put it "unspoken rules", novice developers will encounter a lot of foot guns. It leads to code that works but is very brittle; if you look at it the wrong way, it ends up segfaulting.
Rust says "You can't run this until we're sure it's not going to violate any of my assumptions of how a system is built" and it goes through your code with you to check off all the boxes. Is this thing mutable? Does it have more than one owner? Yes? Well then Rust says that's going to lead to pain in the future and prevents you from doing it. C++ will let you do it and hope that the learnings from the pain you encounter in the future due to your poor choices will prevent you from doing it again.
When I started learning Rust in 2015 the biggest thing in C++ I had built was a robot, and in that world you do most of your work as message passing. It's really more like a style that Erlang devs would find familiar. It's really not equivalent to doing systems programming in the OS/compiler sense. I found Rust very hard to use because I had poor habits in terms of object lifetime and ownership management. But over time the I figured out what the borrow checker wanted and in doing so, it made my code sounder, and therefore far more robust than what I would have put together in C++.
Going forward I apply these ideas to all languages I write in, so this is why I teach Rust in my PL course: even if students aren't going to write Rust in their future career, I've found it makes them think harder about variable lifetimes when they switch back to C and C++ in the OS course.
I don’t think “best” means anything objective, and “systems” is also pretty ambiguous (it describes a class, but that can be interpreted extremely broadly). Rust is still fresh, and people like new things. I think it has legs, but practically I think things need the test of time and many critical projects before you can really assert that it’s the “best”, if at all.
In terms of playing with hardware: did you want to learn rust, or understand low-level programming? I think rust will help you make a more robust, correct application (with a lot of time and effort understanding rust itself), while C won’t do much to help you but you’ll be able to be right next to the hardware. Personally, I think if your goal is to understand how hardware works, I’d use C. (But if you want to learn rust, use rust.)
C is valuable because you shoot yourself in the foot over and over. Once you’ve dealt with use-after-frees, segfaults, memory corruption, then you will really appreciate what Rust does for you. Sure, you can learn Rust up front, but I on,y appreciated it after I had spent some time acquainting myself firsthand with the problems it’s trying to solve. Just my opinion though—Rust is a ton of fun.
C is valuable because it puts an emphasis on ABI. In that sense, it’s a gentle introduction to assembly - functions map 1-to-1 with generated subroutines (modulo inlining), and no monomorphization/templating encourages code reuse at the instruction level. Those philosophies are important stepping stones to understanding concepts like dynamic linking, calling conventions, how registers behave, etc.
Of course, you could emulate this behavior with Rust using extern and unsafe and whatnot, but the affordances of Rust steer you away from those details in favor of the higher level abstractions it offers. Which is what you want for 99% of software development, but when you’re writing platform specific code (e.g. OS startup, context switching, optimized SIMD) that a compiler can’t reliably generate, it helps to be able to quickly prototype something with C and then tweak certain instructions in the generated assembly subroutine until you get what you want.
My perspective was kinda the opposite: I'd already heard of use-after-frees, segfaults, memory corruption, etc. And I was very glad that I didn't have to deal with these as a programmer in high-level languages (JS, etc). As such, learning C was pretty daunting, knowing that even expert-level C programmers tended to hit into these issues, and there seeming to be 1001 rules that one has to learn to avoid them.
Rust provided a way into low-level programming without having to deal with any of these things at all. All I had to do was learn a few concepts like allocation and ownership. Easy-peasy compared to the above! This was especially true as when I learnt Rust I had need of it in production at work. I would not have had the confidence to put C code into production as a novice C programmer with no oversight, but with Rust this wasn't a problem at all.
C++, Ada, and Rust would all be good choices if you want to use something other than C. The decision to me would come down more to the ecosystem.
C++ has in the last decade provided measures for memory safety. Online resources are plentiful and references are easy to get at a bookstore. There are many different compilers (a plus I'd say compared to the monocultures many languages have), but Clang and G++ are ones to look at in particular. They share many extensions to C++ which are useful in systems programming. Clang can be installed on Windows using MS Visual Studio, while G++ is Unix-like only. C++ has many different build systems to choose from, but CMake a common portable one.
Ada came from a similar time as C++. It focuses less on memory safety than Rust, but has more of a focus on overall program correctness. A subset of Ada, SPARK, can be formally verified. The language's culture has more of a focus on embedded systems than general systems programming, and has less of an online presence than the other two. You will have to use reference materials and books more than online guides compared to Rust or C++. The open-source compiler of note is GNAT, it supports both Windows and Unix-like systems. It comes with a build system.
Rust, as you probably know, has a huge focus on memory safety. Rust is in culture much more like newer languages such as Python. Forums are active, updates to the compiler are more frequent, and online resources are plentiful. The book describing the language is a living document available online, unlike the other languages listed. The compiler, build system, and package management system is the same for every supported platform. This to me is a big plus, though package management is not very important for kernel-level development.
“Best” is really subjective and depends on your goals. It’s certainly a nice language, but it’s really a modern take on C++ rather than C. Zig is worth a mention here: it’s a modern take on C, and it tries to avoid the complex features that Rust uses to prove safety at compile time. There’s a contingent of people who don’t like the complexity of Rust or C++ but want to move away from the C footguns, and they normally become Zig fans.
That said, C is still a perfectly fine, very mainstream choice. If you just want to learn systems programming (rather than simultaneously learning systems programming and a new language), it might be the right place to start.
I'd compare Rust more to C++ than C. It's a bit higher in terms of abstraction, though still relatively transparent about what happens. It avoids doing anything implicitly, so when a value is cast to another type or memory is allocated it's visible in the code.
It's not a fun language if you want to experiment or move quickly as the type checker might act as a brick wall in those cases. But as it prevents a whole class of bugs that are related to the majority of security exploits I think it's a pretty good choice if memory safety and performance are the main priority.
Coming from someone who is completely smitten with Rust, there are [edit: a few exceptional] "systems programming language" scenarios where Go is a much stronger candidate. e.g. minikube, lima, and $your_local_tool are probably better done with Go: the entire language is built around doing "shellscripty" things.
The concepts in Rust are a loose/spiritual superset of C; you'd be able to pick up C easily after learning Rust.
Also, I learned Rust with the linked series. It's extremely well though out and guides you into the mental model of "rustisms."
Do you possibly have a link to the series teaching Rust you mentioned. 'Rust linked series' doesn't bring up any results that look relevant, and I would be interested to take a look at it.
Long ago, I used to develop on systems where my program was the only code running. For example DOS, or TI calculators. Hard rebooting or yanking out batteries was a regular part of the process. I’m not sure, but I wonder if Rust could have greatly reduced the frequency of those activities.
There is no "best overall systems programming language", that is strictly an opinion. All you can really do is look at "by and large what do large minorities of users use as a systems programming language". Every language has its trade-offs.
I spent several years writing C code, then a few years writing C++ and now moving into Rust.
My take: Coding in C will teach you a two unique skills:
First, mastering working with pointers will inevitably lead you to debugging cache-miss related performance issues, virtual vs physical addresses when dealing with MMUs and a couple of other low level CPU details that are hard to learn about any other way (yes, this can also be done with C++).
Second, Because C is a barebones language, you’ll have to build everything yourself. Linked lists, hash tables, queues, binary search trees - all of it! And since you are working with pointers, a lot of the data structures and why they matter will make sense at a level that is impossible to grasp with say python (For example, any C programmer who picks up the usual university textbooks on algorithms and data structures looking for a reference to implement a hash table will end up disappointed- most books tell you how hash tables work, but very few tell you how to implement a hash function correctly - and with C, this matters a lot!)
C++ trades off some of C’s language simplicity in exchange for developer velocity. Hash tables, vectors etc are all taken care of for you. But this is actually a dangerous trade off: C++ gives you a language that will not fit in your head, and you can never be entirely certain about the behavior of code hidden from you by design.
Rust makes a ton of sense as a C++ replacement. It takes the same trade off that C++ did (give up language simplicity for developer velocity) but also adds guard rails around to help keep things sane.
I am convinced that rust is the future in every place where C++ makes sense today.
C is different. Yes, it suffers from many of the same bad things as C++. However, people who write C also work differently: they are used to building everything from scratch, they know their projects need more time to complete, they can look at almost every single line of code and tell you roughly what machine code it will compile down to. The language is small enough that it everyone knows all of it, most agree on the best way to do things and critical bugs are often spotted by just recognizing that some code doesn’t appear to follow well known patterns for implementing something (see how the OpenBSD community find bugs for example).
In short, it’s hard to recommend rust over C because they kind of come with different developer ethos. But Rust over C++ is a no brainer any day. And Rust over C makes sense any time C++ over C makes sense (which is the case for most C projects)
One interesting quote about rust in the context of OpenBSD [1]
> For instance, rust cannot
even compile itself on i386 at present time because it exhausts the address space.
I've followed this project from the beginning, but I would say in general this is only a good way to learn Rust if you already know how to write an OS. If you've never written an OS before, then following this will be an exercise in simultaneously learning Rust and operating systems, and that's a lot for anyone to expect of themself. This OS may be "small" but that should not be taken to mean "simple" (although the presentation is excellent and understandable).
I mostly agree but I don't think it's unreasonable for an experienced developer with a bunch of languages on their toolbelt to learn OS development while learning a new language.
This and the intermezzOS project linked below are both good, thanks for sharing those links.
Is there any similar OS project (or even book!) that uses the latest operating system principles and non-hypothetical (i.e., unlike MIX or MINIX) languages?
Wow, I really have no interest in OS development but that is one of the best resources I have ever seen for understanding Rust. Just read the section on async/await and it demystified everything I didn't understand.
I tried to learn Rust but found it very difficult and complicated to learn. I kept having to fight with the compiler to do even the simplest of memory/ lifetime management. I am a seasoned C developer and for me C was much easier. I think this will be the downfall of Rust as I hear it all the time from other developers who try it out.
Before anybody takes this specific prediction too seriously, this guy posted numerous misleading claims about Actix's use of `unsafe` in another thread before deleting them and seems to have a strange vendetta against Rust in general.
This looks great! It took me so long to figure out how to start writing bare metal code for my raspberry pi so I could make a toy OS. This information is pretty hard to come by for some reason. I'm going to follow along so I can learn some Rust.
I've been following the development of a Rust real-time OS for a while, and just got a RISC-V Longan Nano to run it on. It rare to cram so many interesting things to learn into a single side project.
How was RISC-V for setting up the toolchain? ESP32 was a bit confusing (I'm also a Rust newbie) and AVR/Arduino is stuck on an old version (2021-01-07) due to a bug.
Wow, it is obvious that the author put a lot of love and care into writing this. This makes me excited to go through the book and I will have to try and make the time to do so.
Someday I hope to get back to this. Temped to redo it for ARM this time though, given that I now have even more experience with it than x86 and it’s simpler in many ways. We’ll see.
It's not a tutorial series, but you may get something out of browsing the source for https://github.com/SerenityOS/serenity in the meantime. I'm also curious if there are any recent/relevant C++ OS development guides.
