[HN Gopher] Learn Rust by writing a small OS
___________________________________________________________________
Learn Rust by writing a small OS
Author : elamje
Score : 460 points
Date : 2022-02-25 14:22 UTC (8 hours ago)
(HTM) web link (os.phil-opp.com)
(TXT) w3m dump (os.phil-opp.com)
| lambda_dn wrote:
| 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.
| rackjack wrote:
| 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.
| [deleted]
| globular-toast wrote:
| 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.
| Foe wrote:
| Anyone know of anything like this for (modern) C++?
| jonpalmisc wrote:
| 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.
| ModernMech wrote:
| 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).
|
| Good on you if you can pull it off though!
| toomanydoubts wrote:
| 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.
| jovial_cavalier wrote:
| A similar project: https://intermezzos.github.io/
| johndoe0815 wrote:
| Stephen Marz' blog article series about writing an OS for
| RISC-V in Rust is also worth mentioning:
| https://osblog.stephenmarz.com
| steveklabnik wrote:
| 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.
| Pooge wrote:
| Slightly off-topic: has anyone here read Rust in Action[1]? How
| does it compare to other resources?
|
| I'm mostly a back-end engineer, but I've read the Rust Book[2]
| and I'd like to learn more about systems programming.
|
| [1]: https://www.manning.com/books/rust-in-action
|
| [2]: https://doc.rust-lang.org/book/
| vincenv wrote:
| 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.
|
| [1]: https://www.oreilly.com/library/view/programming-
| rust-2nd/97...
| Pooge wrote:
| 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.
| egnehots wrote:
| not really, it's an excellent book but focused on Rust. I
| liked the fact that it explains the memory layout of common
| Rust data structures.
| stjohnswarts wrote:
| That's why this OS project would help you more than most
| books I would think.
| nu11ptr wrote:
| 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.
| Serow225 wrote:
| I really like it. It's half language intro, and half learn-via-
| projects. It worked well for my learning style :)
| ansible wrote:
| 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:
|
| https://doc.rust-lang.org/rust-by-example/
|
| And the Rust Cookbook:
|
| https://rust-lang-nursery.github.io/rust-cookbook/
|
| 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.
| 0xJRS wrote:
| You could find it on b-ok to check it out, then purchase a copy
| of you like it.
| UncleOxidant wrote:
| Oh, that's the new name for z-library?
| sedeki wrote:
| That's unfortunately illegal.
| Rompect wrote:
| Literally my entire kindle library is from there and
| surprise surprise, I haven't been visited by the police
| (yet).
| rNULLED wrote:
| Why would you do something so illegal?
| Rompect wrote:
| Why would I pay for something that I can get for free?
| leshow wrote:
| I recommend Jon Gjengset's book "rust for rustaceans"
| https://nostarch.com/rust-rustaceans
|
| If you're comfortable in Rust, it is the next step up for
| intermediate developers.
| bogeholm wrote:
| I am reading Rust for Rustaceans these days, and I highly
| recommend the book.
|
| It contains a good amount of low level details, but is still
| pretty fast paced.
| Pooge wrote:
| Seems good! Perhaps I'll read them both so I have a better
| understanding of Rust as a programming language _and_ of
| systems programming in general.
| caffeine wrote:
| For your second Rust book, I'd highly recommend the Nomicon!
|
| https://doc.rust-lang.org/nomicon/
|
| 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.
| sm_ts wrote:
| > has anyone here read Rust in Action[1]?
|
| I did, and I didn't like it much, but YMMV.
|
| 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.
| rch wrote:
| 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.
| Steltek wrote:
| 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.
| asicsp wrote:
| Previous discussions (2+ years old):
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
| pdevr wrote:
| 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?
| faitswulff wrote:
| Note that this guide is in the middle of a big rewrite to include
| a UEFI compatible bootloader. The author posts updates here:
| https://rust-osdev.com/
| ModernMech wrote:
| Yes, while it may seem on the surface like the blog hasn't been
| updated in a while, the whole rust x86 project is under active
| development:
|
| https://github.com/rust-osdev/x86_64
| rectang wrote:
| 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.
| vinc wrote:
| 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.
|
| [1]: https://github.com/vinc/moros
|
| [2]: https://wiki.osdev.org
| thinkharderdev wrote:
| 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.
| zomglings wrote:
| 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.
|
| Kudos.
| burlesona wrote:
| 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).
| ashton314 wrote:
| 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.
| 10000truths wrote:
| 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.
| Ar-Curunir wrote:
| You can write Rust in a C-like style, without generics and
| without traits. The output assembly will likely match the C
| output too.
| nicoburns wrote:
| 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.
| jcranmer wrote:
| 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.
| tialaramex wrote:
| 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. Wrapping::<i32>(i32::MAX) +
| Wrapping::<i32>(1) == Wrapping::<i32>(i32::MIN)
|
| 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.
| shadowofneptune wrote:
| 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.
| jkarneges wrote:
| 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.
| ddulaney wrote:
| "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.
| jrimbault wrote:
| Just to add to this comment, sometimes (often) the Rust's
| documentation(s) will point out footguns in C which is a
| valuable resources in & of itself.
| amscanne wrote:
| 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.)
| dilippkumar wrote:
| 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.
|
| C is not going away anytime soon.
|
| [1] https://marc.info/?l=openbsd-misc&m=151233345723889&w=2
| alpaca128 wrote:
| 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.
| stjohnswarts wrote:
| 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.
| nicoburns wrote:
| > 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.
| ModernMech wrote:
| > 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.
| smaddox wrote:
| I would say Rust is currently the best overall programming
| language, period. It is also a great systems programming
| language.
| zamalek wrote:
| 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."
| DerArzt wrote:
| 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.
| bogeholm wrote:
| Probably "Learn Rust With Entirely Too Many Linked Lists":
| https://rust-unofficial.github.io/too-many-lists/
| sirwhinesalot wrote:
| 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.
| Ar-Curunir wrote:
| 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.
| tialaramex wrote:
| 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.
| sirwhinesalot wrote:
| You can, but it's not like the Rust std-lib is in that
| style, nor does it play well with the ownership semantics,
| so my point stands.
|
| You can also write literal C and use the C std-lib in C++
| but it is the same problem. You're not using C++ at that
| point
| eminence32 wrote:
| 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.
| MR4D wrote:
| I'm here to second this.
|
| 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.
| dang wrote:
| Related:
|
| _Writing an OS in Rust: Async /Await_ -
| https://news.ycombinator.com/item?id=22727985 - March 2020 (103
| comments)
|
| _Writing an OS in Rust: Advanced Paging_ -
| https://news.ycombinator.com/item?id=19017108 - Jan 2019 (141
| comments)
|
| _Writing an OS in Rust: Introduction to Paging_ -
| https://news.ycombinator.com/item?id=18903235 - Jan 2019 (79
| comments)
|
| _Writing an OS in Rust: Hardware Interrupts_ -
| https://news.ycombinator.com/item?id=18274235 - Oct 2018 (63
| comments)
|
| _Writing an OS in Rust, Second Edition_ -
| https://news.ycombinator.com/item?id=16556481 - March 2018 (40
| comments)
|
| _Writing an OS in Rust: Handling Exceptions_ -
| https://news.ycombinator.com/item?id=13961020 - March 2017 (41
| comments)
|
| _Writing an OS in Rust: Returning from Exceptions_ -
| https://news.ycombinator.com/item?id=12548066 - Sept 2016 (54
| comments)
|
| _Writing an OS in Rust: Better Exception Messages_ -
| https://news.ycombinator.com/item?id=12218867 - Aug 2016 (31
| comments)
|
| _Writing an OS in Rust: Catching CPU Exceptions_ -
| https://news.ycombinator.com/item?id=11791694 - May 2016 (41
| comments)
|
| _Writing an OS in Rust: Remap the Kernel_ -
| https://news.ycombinator.com/item?id=10822479 - Jan 2016 (25
| comments)
|
| _Writing an OS in Rust_ -
| https://news.ycombinator.com/item?id=10807816 - Dec 2015 (34
| comments)
|
| _Writing an OS in Rust: Allocating Frames_ -
| https://news.ycombinator.com/item?id=10569463 - Nov 2015 (14
| comments)
|
| _Writing an OS in Rust_ -
| https://news.ycombinator.com/item?id=10448136 - Oct 2015 (34
| comments)
| FranchuFranchu wrote:
| I really like this website's design. It's an elegant way to group
| topics.
| nu11ptr wrote:
| 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.
| steveklabnik wrote:
| 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.
___________________________________________________________________
(page generated 2022-02-25 23:01 UTC)