| HN Mirror

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!