20 ms·

Why Rust for Low-Level Linux Programming?

200 points by pieceofpeace 10y ago

ktamura 10y ago
As a long-time developer marketing person, I must say Rust is kicking ass, not just as a language but as a community. They are deeply strategic. 1. Clear audience target: They aren't going after C++ gurus or C magicians but people who are new to systems programming. From Klabnik to Katz to literally everyone in the community, they are consistent with this messaging. 2. As part of 1, they have invested a lot in teaching systems programming 101 (heap v. stack, etc.), i.e., stuff that you learn in the first course in systems programming in college, but many self-taught, higher-level programmers might not know. This is a great example of authentic content marketing based on a clear strategy working out. 3. Their community is very inclusive. My experience (as a marketing guy who barely remembers how to code) is that people are very helpful when you ask questions, submit a patch, etc. This has been the case for me not just with Rust itself but a couple of Rust projects that I've interacted with.
- Bromskloss 10y ago
  > developer marketing person What is that? > They aren't going after C++ gurus or C magicians Don't they have anything to gain from using Rust?
  - glibgil 10y ago
    Someone who markets to developers. The language and context should clear up the ambiguity that they don't mean they are merely a developer that works in marketing for something like, say selling potato chips
    - mkawia 10y ago
      So like a lite developer advocate
      - glibgil 10y ago
        It used to be called advertising, then marketing, then evengelizing and now advocacy, yes
  - ktamura 10y ago
    Developer marketing: marketing to developers. Marketing gets a bad reputation among developers, but it's vital for any technology to be marketed: keeping documentation up to date, answering questions for newcomers, explaining strengths/weaknesses, etc. >Don't they have anything to gain from using Rust? Who's "they"?
    - tiglionabbit 10y ago
      The magicians.
      - njknsdf 10y ago
        We don't need your muggle tools.
      - oblio 10y ago
        They might have something to gain, but they're probably deeply invested in the tech already. People are very hard to dislodge from such positions, unless the new positions have overwhelming benefits such as: a new environment does not support the old tools/programming language; a radical paradigm shift has happened that risks to make completely obsolete their previous knowledge, etc. Rust is more of an incremental improvement over C++, than a radical leap forward. So C++ magicians are less likely to want to switch over.
        ArkyBeagle 10y ago
        I still use 'C'. I do this primarily because the legacy code base is staggeringly large. I'd jump on a gig doing Rust in a heartbeat, all other factors to the good.
  - pjmlp 10y ago
    A developer evangelist. Think someone doing a talk about new Java 9 features at a Java conference. C++ gurus and C magicians already have invested too deep into their languages to throw everything away and start from zero. For example I love Rust and play occasionally with it, but for the time being C++ is my native language on the job when I need to use a native language outside .NET or JVM. I know it since the C++ARM "standard" and we depend on standard OS tooling that Rust is still catching up with. The day will come when our customers will be able to do mixed debugging between JVM/.NET and Rust. Or produce COM as easy as C++ compilers do. But these are things that beginners in systems programming aren't usually doing.
    - jdeeny 10y ago
      As a C magician, rust provides too many clear improvements over C to ignore it. I certainly don't feel like I am 'throwing everything away and starting from zero,' as much of my C (and other language) knowledge transfers over to rust. I'm not a C++ guru, but I think modern C++ is powerful enough that it doesn't feel lacking in features compared to rust, like C does. There is less of a draw for seasoned C++ programmers. Rust seems to be gaining a lot of momentum and I am becoming more and more confident that it will be regarded as a major language for embedded and general systems programming and possibly even a successor to C.
      - pjmlp 10y ago
        For me C was already lacking when I got to learn it in 1992 , because by then I was quite comfortable with Turbo Pascal 6.0. Just check the feature list and type safety differences. The only advantage from C was being less fragmented than Pascal dialects. So I became a C++ hipster (if that would be a thing in the 90's). We used to have the same heat from C guys that C# and other language users nowadays have from systems languages. Hence why I am always supportive of new programming languages that target the same use cases.
  - Daishiman 10y ago
    > Don't they have anything to gain from using Rust? Sure they do, but they're not throwing away a decade of hard-won experience in their specialties just to tinker; at least not with production code bases. The barrier of entry for beginner systems programmers is lower.
    - jguegant 10y ago
      As a C++ enthusiast, I wouldn't use the words "throw knowledge". All the concepts you can find in Rust are almost matching one to one to a C++14 equivalent (albeit pattern matching for instance). The difference being the enforcement of these good practices by the compiler. It would most likely take me 2 days to read the latest rust doc and 1 month of practice to be proficient. Thing is, it's a bit like switching from Python 2 to Python 3. Why would I move to this new environment where I would need to recode everything from scratch? Python 3 will take decades to overthrow its predecessor, how long will it be for Rust? Will it ever succeed? Will the C++ committee react and borrow some of Rust awesomeness? Can I find co-workers willing to learn Rust?
  - Manishearth 10y ago
    Sure they do. But when you say "gurus" and "magicians" these are people who have spent decades with the language and are awesome at it. It's possible that Rust may improve their lives, but it would take years before they have that same level of proficiency. Not because Rust is hard, but because they are so good at C++ and getting that good in anything is hard. Rust does market to C/++ people, a lot. We just don't market to the super-awesome C++ folks. It's the same reason I preferred Word 2003 over the new stuff for half a decade. I had years of memorized shortcuts, custom macros, and general ui familiarity. I could eventually learn the shiny new Word and become as good, but the activation energy for that is too much and I was happy with 2003. Rust isn't only going after non-systems folks. The community is roughly half systemsy. But it may seem this way because Rust tries very hard to not alienate non-systems people with jargon and unexplained systems concepts.
- steveklabnik 10y ago
  Thanks! To be clear, I do very much want C and C++ programmers to be using Rust as well, I just think there's a lot of opportunity in the "new to systems" group. They're also just my group of people, so I find it easier to pitch things to them. I can talk about anything Ruby at any level with a Ruby person, but I first picked up C++ in the late 90s, and hadn't been active in systems-level stuff for a long time when I came to Rust, so I'm a bit removed from feeling their pains directly.
- gue5t 10y ago
  As a C magician, I haven't written a new C project since the Rust 0.8 era. The only reason you would is ease of updating dependencies through distro package managers (because Rust has no stable ABI and performs extensive cross-library inlining). There's no need to market to C people because those who understand the language well will immediately get why Rust is better. For C++ people, Rust's generics remain less powerful than template metaprogramming (which is Turing-complete, with people building real programs in the tarpit), so there are reasons you might not switch. Meanwhile, Rust does make it a lot easier to get started with systems programming, which is good! Every tool should help both empower beginners and extend the reach of experts. For example, writing zero-copy parsers in C is fairly hard to get right, and might not be worth the debugging or validation time that even an expert might have to put in. C string manipulation works, but it's verbose and fiddly. In Rust, it's trivial to use the lifetime system to make sure you keep all the input data around long enough and don't read outside the buffer. You could even use #[must_use] and affine types to check that every character of input data ends up attributed to exactly one terminal.
  - jjnoakes 10y ago
    > The only reason you would is ease of updating dependencies Or if Rust doesn't support your OS yet. I am working on porting LLVM and writing a MIR to C++ translator in parallel. We'll see which one I get further on. Because I'd love nothing more than to use Rust.
    - gue5t 10y ago
      Is the problem the OS, or the architecture/ABI? I wouldn't expect porting to a new OS to be terribly difficult, though it is a time sink since there's a fair bit of API surface to cover to get Rust's libstd ported, and you'd want to work with upstream so they know your platform matters. If your OS doesn't look at all like UNIX, then you'll have to give up on libstd (which talks about "file"s and "processes" and such nonsense), but libcore (which presents data-structures and other logic, rather than IO, code) should be fine.
      - steveklabnik 10y ago
- epoch1970 10y ago
  > They aren't going after C++ gurus or C magicians but people who are new to systems programming. If this actually is their strategy, is it being done voluntarily or out of necessity? I ask, because I've witnessed enough scepticism about Rust from C and C++ programmers. Rightly or wrongly, there are enough of them who don't appear to be receptive to Rust, and likely never will be. So the Rust community may never be able to appeal to these C and C++ programmers, even if they wanted to. The only option may be to appeal to the non-C and non-C++ programmers.
  - pcwalton 10y ago
    > I ask, because I've witnessed enough scepticism about Rust from C and C++ programmers. I don't think there's a single language on the planet that hasn't had skeptics, especially at the beginning. Remember how skeptical everyone was of Python at first due to its significant whitespace? Programmers are very tribal about their tools.
    - oblio 10y ago
      > Remember how skeptical everyone was of Python at first due to its significant whitespace? A large group of programmers still hates Python for this reason, to this day. They've just moved on and are probably completely ignoring Python these days.
    - ArkyBeagle 10y ago
      Python has come a long way, but for domain reasons, the significant whitespace isn't my primary beef. Packaging is, because I haven't captured all the gnosis yet.
- ArkyBeagle 10y ago
  Magicians, schmagicians. I say that as part of (possibly) that group. We've just learned to "cover our father's nakedness" so to speak. I just hope Rust practitioners can do a few things where they have to use 'C' ( properly ), much as I think assembly is a good thing for 'C' programmers to do. I hope the relationship between 'C' and Rust is collegial - ideally, it would approach being the same people over time because legacy code. Nothing divides like language, and flexibility is a great way to harden your skillset.
- martin1975 10y ago
  Thanks for pointing out the community aspect - they're welcoming, pragmatic and don't foeget, the documentation and examples are rather good. Rust is what it took C++ 20 years to become, except anew and reimagined. It's ready and usable, today.
- Shorel 10y ago
  This is something that should be done as well by the guys doing D. Even if they can succeed by going after the C++ gurus as well.
- kazinator 10y ago
  C gets out of the way and lets you do useful things that are "undefined behavior". How convenient is it it Rust, to, say, use the unused bits in a pointer (due to alignment) and put a type tag in them?
  - korethr 10y ago
    Okay, now you've piqued my curiosity. Is that something to do because it's really smart and clever and fun, or is there a certain problem or class of problems where doing that is unambiguously the best or least-worst solution?
    - to3m 10y ago
      You might do it if you were writing an implementation of a language such as Scheme.
    - gdwatson 10y ago
      As to3m says, this is often done in programming language interpreters. If most objects in your language were heap allocated and you want to store a small integer you would allocate a new object on the heap with space for one integer, set up its headers, etc. You could instead set one of the unused bits in the pointer to indicate that it's an integer and not a pointer, then store the integer in the remaining bits, avoiding the heap allocation at all. The Lisp world calls this a fixnum. The more pointer bits you can steal, the more kinds of data you can store directly in the "pointer" itself. It's also possible to store the type of objects that are actually allocated on the heap in tags on the pointers to them, but I don't know if that's done any more.
    - naasking 10y ago
      Haskell does it automatically as an optimisation: if an algebraic type has fewer than 2-3 cases, then it inline the tag bits directly into the pointer, thus saving an indirection on pattern match. Some C data structures also make use of low level bit tricks like this to save space and reduce indirections. For instance, the hash-array mapped Trie uses a 32 bit mask to both track which indices of the current node are actually populated, and incidentally, how large the node currently is. It's quite clever. These are always my foot examples to evaluate any alleged systems programming language. No language less powerful than a theorem prover is currently capable of expressing these idioms safely.
- korethr 10y ago
  I suppose I'm in their target audience, then. I've not done any systems programming, but do have a curiosity about it, and Rust has caught my eye. But my main problem is a lack of a project -- a ThingIWantToDo that would be well suited to a systems programming language like Rust. And I don't even know what kinds of problems or projects are well suited to systems programming -- so far, when I've had an itch to scratch and gone to scratch it, I've found Python able to do what I want. Now I realize that Python is in no way appropriate for all classes of problems, and that there problems for which it is not fast enough. But thus far, the only project I'd like to tackle that I know Python will be too slow for is doing real-time audio processing on Linux with lv2 plugins and JACK. But lv2 and JACK are C APIs, so that's incentive for me to learn C, not Rust. Understand, this isn't a knock against Rust. As I said, it's caught my eye. I just haven't found a compelling reason to actually get involved yet. I am hoping I eventually will.
  - kbenson 10y ago
    > But lv2 and JACK are C APIs, so that's incentive for me to learn C, not Rust. Maybe, but it might be an incentive to learn just enough C that you can wrap the C interface in Rust. The point of having an API is to have well defined behavior at a particular boundary, which can reduce quite a bit (but not eliminate) a lot of the reasons to use the language it was implemented in on the caller side. I suspect learning rust will probably make you familiar enough with the basics of C that you won't have to do much specific C learning to use most libraries.
  - ChickeNES 10y ago
    Here's an example of a lv2 plugin written in Rust: https://github.com/poidl/eg-amp_rust https://github.com/poidl/eg-amp_rust and here's a WIP rust wrapper for JACK: https://github.com/nicklan/rust-jack https://github.com/nicklan/rust-jack
- bogomipz 10y ago
  Can you give an example of 2? Where have they invested in teaching systems programming 101? Is there a specific blog? Thanks.
  - steveklabnik 10y ago
    The Rust book has this chapter, for example: http://doc.rust-lang.org/stable/book/the-stack-and-the-heap.html http://doc.rust-lang.org/stable/book/the-stack-and-the-heap....
    - bogomipz 10y ago
      Ah neat, I did not know about the book, thanks.
      - steveklabnik 10y ago
        No worries. I'm currently in the process of re-writing it for the second edition...
        bogomipz 10y ago
        Would it be worth including a chapter(s) on writing Linux system utilities using Rust? I hope you announce it on HN when the rewrite is finished.
        steveklabnik 10y ago
        I don't want to put Linux above other platforms by only including it. And it's already a huge task on its own. I will for sure. It's also going to end up getting published by No Starch.
Scarbutt 10y ago
Rust reduces the amount of state I need to keep track of in my brain. I doubt it, the mental overhead of doing "safe memory programming" in Rust is very high. Edit: all good replies, want to clarify and forgot to mention that I was comparing to languages with a GC, since I'm seeing Rust being used for lots of stuff, in a general purpose programming language sense (like creating web frameworks for example). Also, for non-very-low-level stuff I guess this cognitive load will be less if/when they introduce an optional GC.
- ewillbefull 10y ago
  Can you give some examples?
- slimsag 10y ago
  I don't remember the source.. but somewhere someone said that the borrow checker would get in the way until you've learned to a certain point, then after that point developers tend to think in terms of the borrow checker by default and it _works for them instead of against them_. Besides, you're still going to be doing safe memory programming regardless of whatever language you use. (unless you're just saying "writing broken code is easier")
  - steveklabnik 10y ago
    This is consistent with a lot of people's experiences with Rust. Some people haven't even noticed when the mental bit flipped for them, "Oh wait, I just realized I haven't fought the borrow checker in a while..." Of course, some people still don't like it. Not every language can be to everyone's liking, a plurality of languages is a good thing. Plus, we do have some stuff in the pipeline to increase the number of programs the borrow checker will understand; some people can get frustrated when they want to write a valid program that gets rejected, but this is going to be the case with any kind of static analysis.
- scott_s 10y ago
  The mental overhead of doing "safe memory programming" is high already. The difference between Rust and, say, C, is that Rust forces you to do "safe memory programming". C lets you get away with unsafe memory programming.
TheMagicHorsey 10y ago
Is there any reason why embedded software for autonomous vehicles is still being written in C/C++? This last week I was talking to a friend at a company that makes a small autonomous vehicle. During testing their prototype suddenly went off in a straight line. They had to pull a safety to halt the vehicle or it would have gone straight forever into the Pacific Ocean. Turns out there was an unsafe access to a variable in memory, which had not been caught with their software and hardware test platform, even with thousands of virtual sorties. If their code was written in Rust, that sort of bug could not have occurred.
- wyldfire 10y ago
  > any reason why embedded software for autonomous vehicles is still being written in C/C++ Nearing a half-century of momentum in the community which includes developers, mature tools, etc. Until rust arrived it was nearly the only game in town for predictable low-latency systems programming. Yes, now that Rust's here there's a bit of an alternative. But if you've got a team of 30+ software devs who know C/C++ and an existing well-tested codebase of millions of lines, even if you had multiple Rust champions it would take a very long time to evolve towards Rust.
- steveklabnik 10y ago
  There's two reasons Rust might not be ready here yet. First, while LLVM supports a wide number of platforms, some embedded devices literally only support the exact version of the C compiler they ship to you, sometimes, it's even got its own custom patches. Second, we sort of assume 32 bits at the lowest, though we have a patch in the queue that starts some work on 8/16 bit support. This means some tiny micros are out of reach at the moment.
  - dv_dt 10y ago
    A rust -> C compiler would be really nice for those custom/slow updating environments, but I can understand if that just too much of a distraction.
    - 10y ago
xvilka 10y ago
Well, Rust is awesome, but there is a place for C too. I just don't understand lack of the life and no improvements in C for ages. Better typing system (for example _Generic doesn't know uint8_t, etc types - they are just typedefs), 'pure' keyword for functions without side effects, tuples support, deprecate a lot of the things and so on.
- stirner 10y ago
  > I just don't understand lack of the life and no improvements in C for ages. Well, MSVC still hasn't even fully implemented C99. One of the big draws of C, as I see it, is its wide support on many operating systems and architectures. If you're going to abandon that by using new C features, you might as well use a language with less cruft.
  - valarauca1 10y ago
    >Well, MSVC still hasn't even fully implemented C99 Neither does GCC. Both don't fully implement C11 either. Most these features are either things C-Compilers don't need to support themselves. Namely: special integer types can be placed in libraries instead of compilers. Also bounds checking interfaces are a performance loss and not included in C compilers despite them being part of the C11 standard. (Well they're optional)
- ArkyBeagle 10y ago
  It's harder than it looks. If you improve things willy-nilly, then you split the language - some will use the more modern version, some will stay behind. IMO, a better evolution is to do what the Rust folks have done - define a new language. This way it has a new name and you don't have to qualify which version of 'C' you mean.
- wahern 10y ago
  _Generic absolutely can handle uint8_t. In fact, the reason _Generic is problematic is precisely because on most implementations uint8_t is a typedef to unsigned char. But in a _Generic list you can't specify multiple compatible types. If you're unsure if uint8_t is compatible with unsigned char, you have to chain multiple _Generic expressions, nesting one inside the default: case like: `_Generic(x, uint8_t: foo_u8, default: _Generic(x, unsigned char: foo_uc, default: baz))`. So if I specify both unsigned char and uint8_t as cases the same _Generic expression, with GCC 6.1 I get: foo.c:6:2: error: ‘_Generic’ specifies two compatible types uint8_t: "uint8_t", \ ^ ... foo.c:5:2: note: compatible type is here unsigned char: "unsigned char", \ ^ and with Apple clang-7001.81 I get foo.c:12:22: error: type 'uint8_t' (aka 'unsigned char') in generic association compatible with previously specified type 'unsigned char' Another issue with _Generic: you have to be careful with type promotion, especially because everything smaller than int is quickly promoted to int in most kinds of expressions. Another issue is type qualifiers: (int) is different from (const int) is different from (volatile int) is different from (const volatile int). _Atomic and restrict increase the permutations. I have a fuzzy memory that early clang had a wrong implementation of _Generic that didn't obey the standard. But as far as I know, today both clang and GCC have identical behavior. Whether Microsoft implements it compatibly if they add it is another question. For example, Microsoft has an idiosyncratic interpretation of macro tokenization and evaluation that makes implementing certain C99 variable argument macro constructions difficult.
bjourne 10y ago
Performance. Rust is still twice as slow as C (http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=spectralnorm http://benchmarksgame.alioth.debian.org/u64q/performance.php...) which is still a fair bit slower than if a skilled assembly programmer had taken on the task. Rust aficionados will say that their compiler is getting better, but so is C. clang has gotten faster than gcc on some benchmarks and on some others gcc has catched up and is now faster than clang again. But what if you don't need optimal performance? Then you can use Rust. But then you can also use Go, Python, SBCL, Haskell, Java, C#...
- frankmcsherry 10y ago
  Or it is faster than C (http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=mandelbrot http://benchmarksgame.alioth.debian.org/u64q/performance.php...). Depends which link you click on.
  - bjourne 10y ago
    From the looks of it, that Rust program spawns 20 threads and does the computations in parallel. The C program does it all in one thread and doesn't even utilize sse intrinsics. I know full well that The Computer Language Benchmarks Game isn't a perfect source for programming language speed arguments, but what you can you do.
    - tatterdemalion 10y ago
      You're right - for microbenchmarks, the difference between Rust and C is going to be in how the solution is implemented, because the languages have such similar performance characteristics. This is why your original comment that Rust is not as performant as C is quite silly. You look rather hypocritical turning around and pointing it out when someone links to a microbenchmark on which Rust outperforms C.
    - frankmcsherry 10y ago
      Yeah, given that the CPU load for the C lines are listed as 100% 95% 95% 95% on a quadcore, I'm going to say "not one thread". Edit: to be helpful, rather than just obnoxious, (<3) the C version uses open mp pragmas, so it looks single-threaded.
fdr 10y ago
I'd like to be able to use something like rust, and maybe I will for smaller projects or for novelty sake, but I chafe over how slow compilation time is relative to C (not C++!) projects last I checked. On the hardware of yesteryear, a parallel compile could build Postgres in about 45 seconds (750-1305KLOC, depending on measurement) , and user mode Linux (which doesn't compile so many drivers) in about a minute.
- steveklabnik 10y ago
  We've made steady improvements here, so depending on when you checked, it might be much better. The real improvements will come when incremental compilation lands. The precursor requirements are just landing now; so it won't be immediately here, but it will be soonish.
jernfrost 10y ago
I love C, but I think we really have to stop building all kinds of shared libraries in C. Important code which needs to be secure and solid can't be built on C anymore, it puts everybody at risk. Just look at the disaster OpenSSL has been. I think Rust would be create for building common crypto infrastructure and things such as crypto currency. It seems risky to me to build something like Bitcoin with C++ where millions can easily be at stake if the system doesn't work. I am an application programmer so I might not be the primary target, but I started programming with Swift and although it isn't the same as Rust it has some similarities. A lot stricter language than C++, C, Lua, Python and Objective-C which have have used most in the past. So many bugs are caught at compile time. I used to be skeptical towards static typing, primarily because languages like C++ and Java made types so awful to work with. But with the newer OOP languages with more functional inspiration, it is getting easier to deal with strict typing. You don't have to chose between productivity and safety so much anymore.
- pcwalton 10y ago
  > You don't have to chose between productivity and safety so much anymore. Exactly. If I had to sum up Rust's philosophy in one sentence, this would basically be it. (Add "and performance" after "safety" too.) :)
  - infogulch 10y ago
    Safe. Productive. Fast. Choose any three. (Taking a hint from SQLite.)
- technion 10y ago
  I'll raise one set of shared libraries in particular: graphics parsers. Whether you're writing in PHP or Ruby or whatever, odds are you'll end up manipulating graphics in some C library. Imagemagick has a long history of issues (although I appreciate the most recent, major issue could have been written into any language). Mozilla only just audited libjpeg-turbo and found a series of issues, and a quick Google will point to most of the options being terrible. I'm sure someone will (if not already) write a decent Rust alternative - but what everyone is missing at the moment is bindings for their favourite high level language with comparable APIs to their existing tools.
Animats 10y ago
Rather than writing for Linux in Rust, we need a new kernel written in Rust. I'd like to see a replacement for the QNX microkernel written in Rust. It's about 60K bytes of code, yet you can run POSIX programs on it. (You need file system and networking, which are user processes.) The QNX kernel is stable - it changes very little from year to year. There's hope of catching all the bugs. This offers a way out of "patch and release" OS development. Yes, you take a 20% or so performance hit for using a microkernel. Big deal. At one time, you could download the QNX kernel sources and look at them.[1] This would be helpful in getting the microkernel architecture right. It's very hard to get that right. See Mach or Hurd. [1] http://community.qnx.com/sf/sfmain/do/downloadAttachment/projects.core_os/wiki/BuildKernelWithIDE?id=atch1253 http://community.qnx.com/sf/sfmain/do/downloadAttachment/pro...
- scythe 10y ago
  QNX is proprietary. Also, the NetBSD anykernel is where I think the sweetspot is.
  - cpeterso 10y ago
    Or MINIX. You could rewrite MINIX's microkernel servers one by one. You have a working kernel and userspace on day one and the end result is a robust microkernel design written in a safe language.
- CUViper 10y ago
  Redox may be exactly what you're looking for: http://www.redox-os.org/ http://www.redox-os.org/ And there are others: http://wiki.osdev.org/Rust http://wiki.osdev.org/Rust
  - Animats 10y ago
    Redox is close, but they have pipe-like, rather than call-like, interprocess communications semantics. That means another layer of overhead. More important, it breaks the tight integration between scheduling and interprocess calls required to make a message-passing OS work fast under load. Here's the QNX architecture document on this, which discusses how message passing and CPU scheduling integrate.[1] Microkernel designers need to read this very carefully. A good test is to run a message-passing benchmark on an idle system, then run it again with a CPU-bound process of equal priority in round-robin mode also running. If the message passing-task starves, or the CPU-bound task starves, message passing was misdesigned. If, on a multiprocessor, a simple message pass causes a CPU switch, message passing was done wrong. If message passing and scheduling do not play very well together, a service-oriented architecture (sorry, "microservices" architecture) will be sluggish. This is where most microkernels fail. [1] http://www.qnx.com/developers/docs/6.4.1/neutrino/sys_arch/ipc.html http://www.qnx.com/developers/docs/6.4.1/neutrino/sys_arch/i...

200 points by pieceofpeace 10y ago

As a long-time developer marketing person, I must say Rust is kicking ass, not just as a language but as a community. They are deeply strategic. 1. Clear audience target: They aren't going after C++ gurus or C magicians but people who are new to systems programming. From Klabnik to Katz to literally everyone in the community, they are consistent with this messaging. 2. As part of 1, they have invested a lot in teaching systems programming 101 (heap v. stack, etc.), i.e., stuff that you learn in the first course in systems programming in college, but many self-taught, higher-level programmers might not know. This is a great example of authentic content marketing based on a clear strategy working out. 3. Their community is very inclusive. My experience (as a marketing guy who barely remembers how to code) is that people are very helpful when you ask questions, submit a patch, etc. This has been the case for me not just with Rust itself but a couple of Rust projects that I've interacted with.

Bromskloss 10y ago
> developer marketing person What is that? > They aren't going after C++ gurus or C magicians Don't they have anything to gain from using Rust?
- glibgil 10y ago
  Someone who markets to developers. The language and context should clear up the ambiguity that they don't mean they are merely a developer that works in marketing for something like, say selling potato chips
  - mkawia 10y ago
    So like a lite developer advocate
    - glibgil 10y ago
      It used to be called advertising, then marketing, then evengelizing and now advocacy, yes
- ktamura 10y ago
  Developer marketing: marketing to developers. Marketing gets a bad reputation among developers, but it's vital for any technology to be marketed: keeping documentation up to date, answering questions for newcomers, explaining strengths/weaknesses, etc. >Don't they have anything to gain from using Rust? Who's "they"?
  - tiglionabbit 10y ago
    The magicians.
    - njknsdf 10y ago
      We don't need your muggle tools.
    - oblio 10y ago
      They might have something to gain, but they're probably deeply invested in the tech already. People are very hard to dislodge from such positions, unless the new positions have overwhelming benefits such as: a new environment does not support the old tools/programming language; a radical paradigm shift has happened that risks to make completely obsolete their previous knowledge, etc. Rust is more of an incremental improvement over C++, than a radical leap forward. So C++ magicians are less likely to want to switch over.
      - ArkyBeagle 10y ago
        I still use 'C'. I do this primarily because the legacy code base is staggeringly large. I'd jump on a gig doing Rust in a heartbeat, all other factors to the good.
- pjmlp 10y ago
  A developer evangelist. Think someone doing a talk about new Java 9 features at a Java conference. C++ gurus and C magicians already have invested too deep into their languages to throw everything away and start from zero. For example I love Rust and play occasionally with it, but for the time being C++ is my native language on the job when I need to use a native language outside .NET or JVM. I know it since the C++ARM "standard" and we depend on standard OS tooling that Rust is still catching up with. The day will come when our customers will be able to do mixed debugging between JVM/.NET and Rust. Or produce COM as easy as C++ compilers do. But these are things that beginners in systems programming aren't usually doing.
  - jdeeny 10y ago
    As a C magician, rust provides too many clear improvements over C to ignore it. I certainly don't feel like I am 'throwing everything away and starting from zero,' as much of my C (and other language) knowledge transfers over to rust. I'm not a C++ guru, but I think modern C++ is powerful enough that it doesn't feel lacking in features compared to rust, like C does. There is less of a draw for seasoned C++ programmers. Rust seems to be gaining a lot of momentum and I am becoming more and more confident that it will be regarded as a major language for embedded and general systems programming and possibly even a successor to C.
    - pjmlp 10y ago
      For me C was already lacking when I got to learn it in 1992 , because by then I was quite comfortable with Turbo Pascal 6.0. Just check the feature list and type safety differences. The only advantage from C was being less fragmented than Pascal dialects. So I became a C++ hipster (if that would be a thing in the 90's). We used to have the same heat from C guys that C# and other language users nowadays have from systems languages. Hence why I am always supportive of new programming languages that target the same use cases.
- Daishiman 10y ago
  > Don't they have anything to gain from using Rust? Sure they do, but they're not throwing away a decade of hard-won experience in their specialties just to tinker; at least not with production code bases. The barrier of entry for beginner systems programmers is lower.
  - jguegant 10y ago
    As a C++ enthusiast, I wouldn't use the words "throw knowledge". All the concepts you can find in Rust are almost matching one to one to a C++14 equivalent (albeit pattern matching for instance). The difference being the enforcement of these good practices by the compiler. It would most likely take me 2 days to read the latest rust doc and 1 month of practice to be proficient. Thing is, it's a bit like switching from Python 2 to Python 3. Why would I move to this new environment where I would need to recode everything from scratch? Python 3 will take decades to overthrow its predecessor, how long will it be for Rust? Will it ever succeed? Will the C++ committee react and borrow some of Rust awesomeness? Can I find co-workers willing to learn Rust?
- Manishearth 10y ago
  Sure they do. But when you say "gurus" and "magicians" these are people who have spent decades with the language and are awesome at it. It's possible that Rust may improve their lives, but it would take years before they have that same level of proficiency. Not because Rust is hard, but because they are so good at C++ and getting that good in anything is hard. Rust does market to C/++ people, a lot. We just don't market to the super-awesome C++ folks. It's the same reason I preferred Word 2003 over the new stuff for half a decade. I had years of memorized shortcuts, custom macros, and general ui familiarity. I could eventually learn the shiny new Word and become as good, but the activation energy for that is too much and I was happy with 2003. Rust isn't only going after non-systems folks. The community is roughly half systemsy. But it may seem this way because Rust tries very hard to not alienate non-systems people with jargon and unexplained systems concepts.
steveklabnik 10y ago
Thanks! To be clear, I do very much want C and C++ programmers to be using Rust as well, I just think there's a lot of opportunity in the "new to systems" group. They're also just my group of people, so I find it easier to pitch things to them. I can talk about anything Ruby at any level with a Ruby person, but I first picked up C++ in the late 90s, and hadn't been active in systems-level stuff for a long time when I came to Rust, so I'm a bit removed from feeling their pains directly.
gue5t 10y ago
As a C magician, I haven't written a new C project since the Rust 0.8 era. The only reason you would is ease of updating dependencies through distro package managers (because Rust has no stable ABI and performs extensive cross-library inlining). There's no need to market to C people because those who understand the language well will immediately get why Rust is better. For C++ people, Rust's generics remain less powerful than template metaprogramming (which is Turing-complete, with people building real programs in the tarpit), so there are reasons you might not switch. Meanwhile, Rust does make it a lot easier to get started with systems programming, which is good! Every tool should help both empower beginners and extend the reach of experts. For example, writing zero-copy parsers in C is fairly hard to get right, and might not be worth the debugging or validation time that even an expert might have to put in. C string manipulation works, but it's verbose and fiddly. In Rust, it's trivial to use the lifetime system to make sure you keep all the input data around long enough and don't read outside the buffer. You could even use #[must_use] and affine types to check that every character of input data ends up attributed to exactly one terminal.
- jjnoakes 10y ago
  > The only reason you would is ease of updating dependencies Or if Rust doesn't support your OS yet. I am working on porting LLVM and writing a MIR to C++ translator in parallel. We'll see which one I get further on. Because I'd love nothing more than to use Rust.
  - gue5t 10y ago
    Is the problem the OS, or the architecture/ABI? I wouldn't expect porting to a new OS to be terribly difficult, though it is a time sink since there's a fair bit of API surface to cover to get Rust's libstd ported, and you'd want to work with upstream so they know your platform matters. If your OS doesn't look at all like UNIX, then you'll have to give up on libstd (which talks about "file"s and "processes" and such nonsense), but libcore (which presents data-structures and other logic, rather than IO, code) should be fine.
    - steveklabnik 10y ago
epoch1970 10y ago
> They aren't going after C++ gurus or C magicians but people who are new to systems programming. If this actually is their strategy, is it being done voluntarily or out of necessity? I ask, because I've witnessed enough scepticism about Rust from C and C++ programmers. Rightly or wrongly, there are enough of them who don't appear to be receptive to Rust, and likely never will be. So the Rust community may never be able to appeal to these C and C++ programmers, even if they wanted to. The only option may be to appeal to the non-C and non-C++ programmers.
- pcwalton 10y ago
  > I ask, because I've witnessed enough scepticism about Rust from C and C++ programmers. I don't think there's a single language on the planet that hasn't had skeptics, especially at the beginning. Remember how skeptical everyone was of Python at first due to its significant whitespace? Programmers are very tribal about their tools.
  - oblio 10y ago
    > Remember how skeptical everyone was of Python at first due to its significant whitespace? A large group of programmers still hates Python for this reason, to this day. They've just moved on and are probably completely ignoring Python these days.
  - ArkyBeagle 10y ago
    Python has come a long way, but for domain reasons, the significant whitespace isn't my primary beef. Packaging is, because I haven't captured all the gnosis yet.
ArkyBeagle 10y ago
Magicians, schmagicians. I say that as part of (possibly) that group. We've just learned to "cover our father's nakedness" so to speak. I just hope Rust practitioners can do a few things where they have to use 'C' ( properly ), much as I think assembly is a good thing for 'C' programmers to do. I hope the relationship between 'C' and Rust is collegial - ideally, it would approach being the same people over time because legacy code. Nothing divides like language, and flexibility is a great way to harden your skillset.
martin1975 10y ago
Thanks for pointing out the community aspect - they're welcoming, pragmatic and don't foeget, the documentation and examples are rather good. Rust is what it took C++ 20 years to become, except anew and reimagined. It's ready and usable, today.
Shorel 10y ago
This is something that should be done as well by the guys doing D. Even if they can succeed by going after the C++ gurus as well.
kazinator 10y ago
C gets out of the way and lets you do useful things that are "undefined behavior". How convenient is it it Rust, to, say, use the unused bits in a pointer (due to alignment) and put a type tag in them?
- korethr 10y ago
  Okay, now you've piqued my curiosity. Is that something to do because it's really smart and clever and fun, or is there a certain problem or class of problems where doing that is unambiguously the best or least-worst solution?
  - to3m 10y ago
    You might do it if you were writing an implementation of a language such as Scheme.
  - gdwatson 10y ago
    As to3m says, this is often done in programming language interpreters. If most objects in your language were heap allocated and you want to store a small integer you would allocate a new object on the heap with space for one integer, set up its headers, etc. You could instead set one of the unused bits in the pointer to indicate that it's an integer and not a pointer, then store the integer in the remaining bits, avoiding the heap allocation at all. The Lisp world calls this a fixnum. The more pointer bits you can steal, the more kinds of data you can store directly in the "pointer" itself. It's also possible to store the type of objects that are actually allocated on the heap in tags on the pointers to them, but I don't know if that's done any more.
  - naasking 10y ago
    Haskell does it automatically as an optimisation: if an algebraic type has fewer than 2-3 cases, then it inline the tag bits directly into the pointer, thus saving an indirection on pattern match. Some C data structures also make use of low level bit tricks like this to save space and reduce indirections. For instance, the hash-array mapped Trie uses a 32 bit mask to both track which indices of the current node are actually populated, and incidentally, how large the node currently is. It's quite clever. These are always my foot examples to evaluate any alleged systems programming language. No language less powerful than a theorem prover is currently capable of expressing these idioms safely.
korethr 10y ago
I suppose I'm in their target audience, then. I've not done any systems programming, but do have a curiosity about it, and Rust has caught my eye. But my main problem is a lack of a project -- a ThingIWantToDo that would be well suited to a systems programming language like Rust. And I don't even know what kinds of problems or projects are well suited to systems programming -- so far, when I've had an itch to scratch and gone to scratch it, I've found Python able to do what I want. Now I realize that Python is in no way appropriate for all classes of problems, and that there problems for which it is not fast enough. But thus far, the only project I'd like to tackle that I know Python will be too slow for is doing real-time audio processing on Linux with lv2 plugins and JACK. But lv2 and JACK are C APIs, so that's incentive for me to learn C, not Rust. Understand, this isn't a knock against Rust. As I said, it's caught my eye. I just haven't found a compelling reason to actually get involved yet. I am hoping I eventually will.
- kbenson 10y ago
  > But lv2 and JACK are C APIs, so that's incentive for me to learn C, not Rust. Maybe, but it might be an incentive to learn just enough C that you can wrap the C interface in Rust. The point of having an API is to have well defined behavior at a particular boundary, which can reduce quite a bit (but not eliminate) a lot of the reasons to use the language it was implemented in on the caller side. I suspect learning rust will probably make you familiar enough with the basics of C that you won't have to do much specific C learning to use most libraries.
- ChickeNES 10y ago
  Here's an example of a lv2 plugin written in Rust: https://github.com/poidl/eg-amp_rust https://github.com/poidl/eg-amp_rust and here's a WIP rust wrapper for JACK: https://github.com/nicklan/rust-jack https://github.com/nicklan/rust-jack
bogomipz 10y ago
Can you give an example of 2? Where have they invested in teaching systems programming 101? Is there a specific blog? Thanks.
- steveklabnik 10y ago
  The Rust book has this chapter, for example: http://doc.rust-lang.org/stable/book/the-stack-and-the-heap.html http://doc.rust-lang.org/stable/book/the-stack-and-the-heap....
  - bogomipz 10y ago
    Ah neat, I did not know about the book, thanks.
    - steveklabnik 10y ago
      No worries. I'm currently in the process of re-writing it for the second edition...
      - bogomipz 10y ago
        Would it be worth including a chapter(s) on writing Linux system utilities using Rust? I hope you announce it on HN when the rewrite is finished.
        steveklabnik 10y ago
        I don't want to put Linux above other platforms by only including it. And it's already a huge task on its own. I will for sure. It's also going to end up getting published by No Starch.

Scarbutt 10y ago

Rust reduces the amount of state I need to keep track of in my brain. I doubt it, the mental overhead of doing "safe memory programming" in Rust is very high. Edit: all good replies, want to clarify and forgot to mention that I was comparing to languages with a GC, since I'm seeing Rust being used for lots of stuff, in a general purpose programming language sense (like creating web frameworks for example). Also, for non-very-low-level stuff I guess this cognitive load will be less if/when they introduce an optional GC.

ewillbefull 10y ago
Can you give some examples?
slimsag 10y ago
I don't remember the source.. but somewhere someone said that the borrow checker would get in the way until you've learned to a certain point, then after that point developers tend to think in terms of the borrow checker by default and it _works for them instead of against them_. Besides, you're still going to be doing safe memory programming regardless of whatever language you use. (unless you're just saying "writing broken code is easier")
- steveklabnik 10y ago
  This is consistent with a lot of people's experiences with Rust. Some people haven't even noticed when the mental bit flipped for them, "Oh wait, I just realized I haven't fought the borrow checker in a while..." Of course, some people still don't like it. Not every language can be to everyone's liking, a plurality of languages is a good thing. Plus, we do have some stuff in the pipeline to increase the number of programs the borrow checker will understand; some people can get frustrated when they want to write a valid program that gets rejected, but this is going to be the case with any kind of static analysis.
scott_s 10y ago
The mental overhead of doing "safe memory programming" is high already. The difference between Rust and, say, C, is that Rust forces you to do "safe memory programming". C lets you get away with unsafe memory programming.

TheMagicHorsey 10y ago

Is there any reason why embedded software for autonomous vehicles is still being written in C/C++? This last week I was talking to a friend at a company that makes a small autonomous vehicle. During testing their prototype suddenly went off in a straight line. They had to pull a safety to halt the vehicle or it would have gone straight forever into the Pacific Ocean. Turns out there was an unsafe access to a variable in memory, which had not been caught with their software and hardware test platform, even with thousands of virtual sorties. If their code was written in Rust, that sort of bug could not have occurred.

wyldfire 10y ago
> any reason why embedded software for autonomous vehicles is still being written in C/C++ Nearing a half-century of momentum in the community which includes developers, mature tools, etc. Until rust arrived it was nearly the only game in town for predictable low-latency systems programming. Yes, now that Rust's here there's a bit of an alternative. But if you've got a team of 30+ software devs who know C/C++ and an existing well-tested codebase of millions of lines, even if you had multiple Rust champions it would take a very long time to evolve towards Rust.
steveklabnik 10y ago
There's two reasons Rust might not be ready here yet. First, while LLVM supports a wide number of platforms, some embedded devices literally only support the exact version of the C compiler they ship to you, sometimes, it's even got its own custom patches. Second, we sort of assume 32 bits at the lowest, though we have a patch in the queue that starts some work on 8/16 bit support. This means some tiny micros are out of reach at the moment.
- dv_dt 10y ago
  A rust -> C compiler would be really nice for those custom/slow updating environments, but I can understand if that just too much of a distraction.
  - 10y ago

xvilka 10y ago

Well, Rust is awesome, but there is a place for C too. I just don't understand lack of the life and no improvements in C for ages. Better typing system (for example _Generic doesn't know uint8_t, etc types - they are just typedefs), 'pure' keyword for functions without side effects, tuples support, deprecate a lot of the things and so on.

stirner 10y ago
> I just don't understand lack of the life and no improvements in C for ages. Well, MSVC still hasn't even fully implemented C99. One of the big draws of C, as I see it, is its wide support on many operating systems and architectures. If you're going to abandon that by using new C features, you might as well use a language with less cruft.
- valarauca1 10y ago
  >Well, MSVC still hasn't even fully implemented C99 Neither does GCC. Both don't fully implement C11 either. Most these features are either things C-Compilers don't need to support themselves. Namely: special integer types can be placed in libraries instead of compilers. Also bounds checking interfaces are a performance loss and not included in C compilers despite them being part of the C11 standard. (Well they're optional)
ArkyBeagle 10y ago
It's harder than it looks. If you improve things willy-nilly, then you split the language - some will use the more modern version, some will stay behind. IMO, a better evolution is to do what the Rust folks have done - define a new language. This way it has a new name and you don't have to qualify which version of 'C' you mean.
wahern 10y ago
_Generic absolutely can handle uint8_t. In fact, the reason _Generic is problematic is precisely because on most implementations uint8_t is a typedef to unsigned char. But in a _Generic list you can't specify multiple compatible types. If you're unsure if uint8_t is compatible with unsigned char, you have to chain multiple _Generic expressions, nesting one inside the default: case like: `_Generic(x, uint8_t: foo_u8, default: _Generic(x, unsigned char: foo_uc, default: baz))`. So if I specify both unsigned char and uint8_t as cases the same _Generic expression, with GCC 6.1 I get: foo.c:6:2: error: ‘_Generic’ specifies two compatible types uint8_t: "uint8_t", \ ^ ... foo.c:5:2: note: compatible type is here unsigned char: "unsigned char", \ ^ and with Apple clang-7001.81 I get foo.c:12:22: error: type 'uint8_t' (aka 'unsigned char') in generic association compatible with previously specified type 'unsigned char' Another issue with _Generic: you have to be careful with type promotion, especially because everything smaller than int is quickly promoted to int in most kinds of expressions. Another issue is type qualifiers: (int) is different from (const int) is different from (volatile int) is different from (const volatile int). _Atomic and restrict increase the permutations. I have a fuzzy memory that early clang had a wrong implementation of _Generic that didn't obey the standard. But as far as I know, today both clang and GCC have identical behavior. Whether Microsoft implements it compatibly if they add it is another question. For example, Microsoft has an idiosyncratic interpretation of macro tokenization and evaluation that makes implementing certain C99 variable argument macro constructions difficult.

bjourne 10y ago

Performance. Rust is still twice as slow as C (http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=spectralnorm http://benchmarksgame.alioth.debian.org/u64q/performance.php...) which is still a fair bit slower than if a skilled assembly programmer had taken on the task. Rust aficionados will say that their compiler is getting better, but so is C. clang has gotten faster than gcc on some benchmarks and on some others gcc has catched up and is now faster than clang again. But what if you don't need optimal performance? Then you can use Rust. But then you can also use Go, Python, SBCL, Haskell, Java, C#...

frankmcsherry 10y ago
Or it is faster than C (http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=mandelbrot http://benchmarksgame.alioth.debian.org/u64q/performance.php...). Depends which link you click on.
- bjourne 10y ago
  From the looks of it, that Rust program spawns 20 threads and does the computations in parallel. The C program does it all in one thread and doesn't even utilize sse intrinsics. I know full well that The Computer Language Benchmarks Game isn't a perfect source for programming language speed arguments, but what you can you do.
  - tatterdemalion 10y ago
    You're right - for microbenchmarks, the difference between Rust and C is going to be in how the solution is implemented, because the languages have such similar performance characteristics. This is why your original comment that Rust is not as performant as C is quite silly. You look rather hypocritical turning around and pointing it out when someone links to a microbenchmark on which Rust outperforms C.
  - frankmcsherry 10y ago
    Yeah, given that the CPU load for the C lines are listed as 100% 95% 95% 95% on a quadcore, I'm going to say "not one thread". Edit: to be helpful, rather than just obnoxious, (<3) the C version uses open mp pragmas, so it looks single-threaded.

fdr 10y ago

I'd like to be able to use something like rust, and maybe I will for smaller projects or for novelty sake, but I chafe over how slow compilation time is relative to C (not C++!) projects last I checked. On the hardware of yesteryear, a parallel compile could build Postgres in about 45 seconds (750-1305KLOC, depending on measurement) , and user mode Linux (which doesn't compile so many drivers) in about a minute.

steveklabnik 10y ago
We've made steady improvements here, so depending on when you checked, it might be much better. The real improvements will come when incremental compilation lands. The precursor requirements are just landing now; so it won't be immediately here, but it will be soonish.

jernfrost 10y ago

I love C, but I think we really have to stop building all kinds of shared libraries in C. Important code which needs to be secure and solid can't be built on C anymore, it puts everybody at risk. Just look at the disaster OpenSSL has been. I think Rust would be create for building common crypto infrastructure and things such as crypto currency. It seems risky to me to build something like Bitcoin with C++ where millions can easily be at stake if the system doesn't work. I am an application programmer so I might not be the primary target, but I started programming with Swift and although it isn't the same as Rust it has some similarities. A lot stricter language than C++, C, Lua, Python and Objective-C which have have used most in the past. So many bugs are caught at compile time. I used to be skeptical towards static typing, primarily because languages like C++ and Java made types so awful to work with. But with the newer OOP languages with more functional inspiration, it is getting easier to deal with strict typing. You don't have to chose between productivity and safety so much anymore.

pcwalton 10y ago
> You don't have to chose between productivity and safety so much anymore. Exactly. If I had to sum up Rust's philosophy in one sentence, this would basically be it. (Add "and performance" after "safety" too.) :)
- infogulch 10y ago
  Safe. Productive. Fast. Choose any three. (Taking a hint from SQLite.)
technion 10y ago
I'll raise one set of shared libraries in particular: graphics parsers. Whether you're writing in PHP or Ruby or whatever, odds are you'll end up manipulating graphics in some C library. Imagemagick has a long history of issues (although I appreciate the most recent, major issue could have been written into any language). Mozilla only just audited libjpeg-turbo and found a series of issues, and a quick Google will point to most of the options being terrible. I'm sure someone will (if not already) write a decent Rust alternative - but what everyone is missing at the moment is bindings for their favourite high level language with comparable APIs to their existing tools.

Animats 10y ago

Rather than writing for Linux in Rust, we need a new kernel written in Rust. I'd like to see a replacement for the QNX microkernel written in Rust. It's about 60K bytes of code, yet you can run POSIX programs on it. (You need file system and networking, which are user processes.) The QNX kernel is stable - it changes very little from year to year. There's hope of catching all the bugs. This offers a way out of "patch and release" OS development. Yes, you take a 20% or so performance hit for using a microkernel. Big deal. At one time, you could download the QNX kernel sources and look at them.[1] This would be helpful in getting the microkernel architecture right. It's very hard to get that right. See Mach or Hurd. [1] http://community.qnx.com/sf/sfmain/do/downloadAttachment/projects.core_os/wiki/BuildKernelWithIDE?id=atch1253 http://community.qnx.com/sf/sfmain/do/downloadAttachment/pro...

scythe 10y ago
QNX is proprietary. Also, the NetBSD anykernel is where I think the sweetspot is.
- cpeterso 10y ago
  Or MINIX. You could rewrite MINIX's microkernel servers one by one. You have a working kernel and userspace on day one and the end result is a robust microkernel design written in a safe language.
CUViper 10y ago
Redox may be exactly what you're looking for: http://www.redox-os.org/ http://www.redox-os.org/ And there are others: http://wiki.osdev.org/Rust http://wiki.osdev.org/Rust
- Animats 10y ago
  Redox is close, but they have pipe-like, rather than call-like, interprocess communications semantics. That means another layer of overhead. More important, it breaks the tight integration between scheduling and interprocess calls required to make a message-passing OS work fast under load. Here's the QNX architecture document on this, which discusses how message passing and CPU scheduling integrate.[1] Microkernel designers need to read this very carefully. A good test is to run a message-passing benchmark on an idle system, then run it again with a CPU-bound process of equal priority in round-robin mode also running. If the message passing-task starves, or the CPU-bound task starves, message passing was misdesigned. If, on a multiprocessor, a simple message pass causes a CPU switch, message passing was done wrong. If message passing and scheduling do not play very well together, a service-oriented architecture (sorry, "microservices" architecture) will be sluggish. This is where most microkernels fail. [1] http://www.qnx.com/developers/docs/6.4.1/neutrino/sys_arch/ipc.html http://www.qnx.com/developers/docs/6.4.1/neutrino/sys_arch/i...