Rust, Wright's Law, and the Future of Low-Latency Systems
youtube.com
youtube.com
* no_std
* composability of no_std crates
IMO the development-time packaging (cargo) means that as a developer I can have a deep and broad list of dependencies without having to orchestrate my development environment. This is Rust's killer feature, I agree. The fact that you can do it w/no_std is also very awesome.
Does anyone have more info about "Hubris" - the OS he refers to as under development?
I am extremely excited.
The one thing I wanted to point out is that there's already a "namespace collision" when you search on "Rust" and "Hubris" — a language called Hubris written in Rust:
Cheers.
I wrote fontdue [0] (which is very incomplete spec wise) because there just wasn't another font library that was no_std at that time. It felt like the existing libraries were in an arms race for gpu caches and bundling file loading. Like if I wanted to commit to a running on a platform I'd do the sane thing and use harfbuzz or the platform APIs.
It's very naive because I don't understand all of the complexity, but I'd really like to see the standard library being easier to piecewise implement from crates. Like a standard trait library and a standard implementation library for those traits.
This sounds like a very good idea. (The thinness of the std future API paved the way for multiple async runtimes. And sowed confusion! evil laugh But seriously, having a high throughput optimized runtime like Tokio and a size optimized like smol is a good thing.) But a very much non trivial amount of work. Has this been discussed on internals?
https://www.usenix.org/legacy/events/hotos09/tech/full_paper...
We argue that a new OS for a multicore machine should be designed ground-up as a distributed system, using concepts from that field. Modern hardware resembles a networked system even more than past large multiprocessors: in addition to familiar latency effects, it exhibits node heterogeneity and dynamic membership changes
And now that I look at the author list, I see Roscoe, who gives the 2021 keynote that Cantrill recommends:
I'm not a hardware guy so I don't have the imagination of what you could do on these cores without CPUs or meaningful memory.
The tricky part is providing a programming model that is usable, understandable, and useful, given the wide variability of the conditions the code would need to operate in. The eBPF project has made remarkable progress in that direction. eBPF code can be generated from C, C++, Rust, and a bunch of other languages. The "no_std" feature in Rust has no substantial role in getting your code compiled down to eBPF, in preparation to be further translated to the object code that actually runs in the peripheral gadget.
In the past, I was interviewing at a hardware company and one of the things they had just discovered was an "unused" and undocumented processing unit that they could run a process on to get squeeze out more compute from the cameras they used for calibration for the hardware bill of materials that they had already settled on.
[0] https://www.youtube.com/watch?v=36myc8wQhLo
[1] https://github.com/oxidecomputer/twitter-spaces/blob/master/...
- Transistors are getting cheaper
- Therefore it is cheap to put computing closer to I/O (which reduces latency)
- That computing will not have the sorts of things a general-purpose CPU has (maybe no MMU, limited RAM, perhaps it's a harvard architecture)
The rest just says that compute elements are showing up in our peripherals, and that we will need, and want, to program them. (People have said this for decades, but there has been little movement toward enabling it, because it will always be hard, for reasons.) Then it makes the absurd claim that Rust is uniquely capable of programming those elements, because it has a feature called "no_std", where your build fails if your code tries to use any standard library features.
Of course, all those peripheral processors are already programmed, today, almost all in C and C++. It is arbitrarily hard to run your own code on most, today, because where it is possible at all, you need to solder in a JTAG connector and reverse-engineer the code in there to figure out how your code can operate in the environment.
Lots of peripherals, though, get their object code loaded into them by the kernel driver at startup before they will do anything useful.
Maybe someday it will get easier to download your own code into them from a running system, to extend what they are already doing, and maybe someday somebody will document what your code would need to do to contribute to such operation. But if that ever happens -- and, to be clear, it is happening in certain, select places, like some NICs -- Rust will have no advantage over other languages. Using "no_std" will not materially help.
For example, a company Netronome has today a NIC that lets you run your own code on it, e.g. to filter or alter packets before they get DMA'd out to the ring buffer where the kernel sees them. It is programmed using eBPF, which is a virtual object code format that a kernel driver will translate to native machine code. eBPF code can be generated by running LLVM over a file generated by a compiler for C, C++, Rust, or really almost any language that can be compiled to LLVM intermediate code, and offers some way to call out to a C library API.
The Netronome kernel driver takes your eBPF object code, compiled from any language, translates it to machine code for one of the cores in the NIC, copies that onto the NIC, and patches it into what is already running there.
Of course none of the other languages have "no_std", and don't need it. Your Rust code doesn't need it either. Don't want to use library features? Just don't use them. The things an eBPF program is allowed to do are quite limited, but surprisingly powerful, including calling out to a special ("standard") eBPF library. That Rust's sum types are core language features gives it no advantage over the equivalent C++ Standard Library features that (also) do not depend on linking to a runtime support library.
I think the software world has got to the point where the obligatory Moore's Law graphs, etc are no longer required when talking about CPU performance.
If you want to do stuff like this, anything you use to do it will have to look a lot like eBPF. eBPF doesn't make it easy, it only makes it possible. But dtrace was not eBPF.
It is not being done with WASM, and probably will not be.
Right. Short version: Moore's law over, fabs too expensive.
Then it goes on to make the absurd claim that Rust is uniquely capable of programming those elements. This is asserted to be because of a feature called "no_std", where your build fails if your code tries to use any standard library features.
He's a bit vague there. What he's getting at, though, is that a common heap is a problem when you have enough CPUs. Shared-memory multiprocessor architecture is hitting a wall. Caches, and cache sharing, and cache intercommunication have made it possible to get a large number of CPUs to pretend they share memory. But they really don't share, and trying to maintain that illusion adds considerable overhead.
This is an old observation. It's led to lots of distributed systems - the Transputer, the Cell, and a whole bunch of experimental one-offs. All failed.
Now, there are successes of loosely coupled parallelism. GPUs. Neural net simulation chips. Bitcoin miners. Supercomputers doing finite element analysis. Those are useful for very specific problems where you need a large number of semi special purpose compute elements. What this guy may be thinking is some general product to do all that.
But he doesn't say much about how to do that.
This gets conflated, absurdly, with an inability to allocate, manage, and use heap memory. Billions of embedded devices reserve and manage heap memory without difficulty. Indeed, every OS kernel is running in just such an embedded environment. Managing memory for its own use and on behalf of user processes is among its chief activities.
The problem with defining a "free-standing" version of a Standard is that, in practice, real systems invariably need to use some of what is not specified to be part of the negotiated "free-standing" subset. There are at all times active proposals to add this or that extra library feature to the "free-standing" subset. Meanwhile, the language implementers have very little incentive to package any "free-standing" subset at all, because no one such subset that any substantial number of embedded users can actually use is possible.
In practice, embedded-system developers use the regular toolchain, and just link a runtime support library that implements the things they need. So, for example, C++'s std::vector will, by default, call operator new(). But any particular use of it, in an embedded program, may specify a custom allocator, and the object code for the program then ends up with no calls to operator new(), and so links happily to a runtime library without one.
Incidentally, “every” OS does not have a heap. Many do, possibly even “most,” but that’s not required. It is extremely nice to be able to know what needs a heap and what does not.
It is not just nice, but essential, to know what needs a heap. And, every embedded coder does know. Or quickly learns.
> Billions of embedded devices reserve and manage heap memory without difficulty. Indeed, every OS kernel is running in just such an embedded environment.
You claim every OS kernel is "running in just such an embedded environment" and you describe that environment by saying it does "reserve and manage heap memory without difficulty". (My emphasis). Would you like to explain how this is different from the claim you now say you didn't make?
This will obviously be true in C++ but it's far from obvious that it's a sound prediction of the future in Rust.
Let's take a fairly simple thing we might expect to be able to do. We have two fixed size static arrays of data of the same fundamental type. We're writing a function that processes such data (maybe it's writing control bytes to an MMIO register) and sometimes we will want to process both of them, we can't splash out on more RAM to just concatenate both arrays into a temporary vector, that would blow our budget. Cutting the function up into parts is messy, surely we can do better?
In both C++ and Rust, this feels not so hard to achieve. Our function can just take an iterator, it iterates over the provided data and processes all of it, we use iterator adaptors to feed both arrays in when that's what we need. The optimiser should make this just as nice as if we'd meticulously hand-rolled it, but with fewer opportunities for mistakes.
And in Rust it really is that easy, the natural array type works as expected, it is IntoIterator, the core::iter namespace provides a suitable adaptor to connect two together naturally (Chain).
But in C++ we immediately run into problems. The built-in array type is ghastly and we can't very well use it. There's a usable array type but it's not free standing for some reason. Even once we have an array type, we need iterators which also aren't free standing. And then we quickly discover C++ iterators aren't powerful enough here and we need to resort to third party libraries anyway.
Except, we don't. The built-in array type works fine. Anyway std::array doesn't need runtime-library support, iterators likewise. Nobody implements "freestanding", or would use it, so that's a non-issue. Libraries are fine. But std::ranges::join_view [1] seems to be what you are talking about?
(NGL, you read a bit desperate. Things OK?)
It is a mark of weakness, in a language, to need to implement in its core what, with better core features, could as well have been in the library instead. Finding stuff that lives in the C++ Standard Library in core Rust is not really a thing to brag on.
It does not seem to be a Container and doesn't remember its own size. It's a sad relic of C and for whatever reason C++ can't or won't fix it.
> Nobody implements "freestanding", or would use it
So, you've gone from everybody wants to add things to free-standing, to now, in C++ nobody implements it and it's unused? No wonder offering something better would be popular.
It is true that I'd forgotten if you have C++ 20 you can now make a view out of two iterators by adding yet another non-freestanding dependency for ranges instead of needing Boost.
> (NGL, you read a bit desperate. Things OK?)
I'm not "NGL" whoever you think that is. My legal name is a matter of public record and so it's always striking to me that people so often think guessing who I am is somehow a revelation that will make up for the weakness of their argument.
> It is a mark of weakness, in a language, to need to implement in its core what, with better core features, could as well have been in the library instead.
Rust's core library is, as its name would suggest, a library, just one which unlike std is free from tricky environmental dependencies.
But sure, it is a weakness that in C++ "volatile" gets to be a language level type qualifier whose semantics are poorly defined, whereas in Rust the things you actually wanted (a way to read or write MMIO that doesn't tear or get messed about by the compiler) are provided by an intrinsic in the core library. This weakness is apparently something people are trying to repair in C++ 23, decades after the mistake was made. Better late than never?
A bunch of things in core couldn't have been handrolled because they are "magic". For example the Drop and Copy traits do define functions so they aren't pure markers, but the compiler cares that it can see how to copy something which claims to implement Copy, and won't allow Drop if the type is also Copy since that's nonsense -- so you couldn't be allowed to define these traits yourself in the natural way. You also aren't (yet) allowed to go around implementing the Fn* traits yourself either because there is considerable wizardry involved.
However, core also contains numerous things that you could roll yourself, but shouldn't, up to and including iterators. For example, core::mem::drop() isn't magic, it really is just an empty function. You could write that yourself. It would do the same thing, but, core::mem::drop() exists so that everybody understands what you're doing when you call it. Likewise core re-exports all the primitive types so that you can definitely say core::primitive::bool to refer to the primitive type bool, even in code where you've gone completely crazy and re-defined the type name bool.
"In the core language" means not in a library. Thus, "core library" is an oxymoron. So, having things like sum types and iterators implemented in the core language, not in the standard library, betrays language weakness. Is this concept difficult for you? Take your time.
I know you were already aware that volatile and native array types in C++ came to it from C. Nobody ever suggested C was a powerfully expressive language. So, only confusion could provoke criticism of volatile in C++. (You earlier expressed confusion about the need for C++ to maintain backward compatibility with C. Please do think it through.)
It might seem strange that nobody implements or uses the freestanding C++ subset, yet people nonetheless continually propose additions to it. Standardization is strange, and people have reasons they do not always tell.
Most oxymorons (including "oxymoron" itself in Latin) have this property in which the superficial appearance of contradiction is not the reality. A core library is a quite reasonable thing to offer, even if you don't seem quite clear whether C++ needs such a thing (and people are clamouring to add more to it) or doesn't (and so nobody implements or uses it)...
By their nature Rust's sum types are a language construct but specific sum types have to be implemented somewhere and Rust puts some very useful ones (such as Option and Result) that don't require environmental support in core.
Iterators are a tiny bit special because Rust's for loop is just syntactic sugar for iteration, the compiler knows core is providing the relevant stuff so it de-sugars a for loop by relying on IntoIterator, Iterator and Option implementations in core, if they somehow don't exist your for loops won't compile.
Compatibility claims are a weak excuse. Once upon a time I would have expected better, but it's certainly possible the modern C++ committee will agree with you that fixing volatile isn't worth doing and vote down P1382.
[P1382 is the same as the Rust volatile intrinsics except as a C++ template, not so much because it's inspired by Rust, but because those are in fact the volatile semantics you need -- same as C++ and Rust having the same maximum value for a 32-bit unsigned integer]
Oh, you didn't? And you haven't? My mistake.
Without Epochs, C++ doesn't have a way to do what Rust does all the time with "editions". I expect you'll see a HN topic about it later this month, but Rust 2021 will follow Rust 2018 in "breaking" several Rust 1.0 (aka Rust 2015) features, knowing this is fine because those features still exist (and work just fine) in previous editions.
When Rust 1.0 shipped myArray.into_iter() was clearly referring to the reference, ie (&myArray).into_iter() since (&myArray) implements IntoIterator whereas back then myArray did not. There will be code out there that does this, and of course we can't very well just break it because it's ugly.
So, even though today's arrays implement IntoIterator, myArray.into_iter() is still treated as (&myArray).into_iter() to keep that old code working as expected. Well, you get a warning these past few months, but that's still what the code does.
Until Rust 2021. In Rust 2021, arrays have "always" implemented IntoIterator, so myArray.into_iter() just does what you'd naturally expect it to.
This is possible with editions, because as I said, all the old code is still working under the edition it was written for even on shiny new compilers. If somebody wants to update that code (perhaps they want a feature from a newer edition), there is tooling to help them, but if not it'll compile as it is under the old edition indefinitely.
1) no_std allows composability. One of Rust's biggest strengths is its package ecosystem, and I imagine this will only become more true in the increasingly "weird" and sprawling hardware ecosystem described by the OP, where the ability to re-use code that other people might have written for your hardware could save you from having to "solder in a JTAG connector and reverse-engineer the code in there to figure out how your code can operate in the environment". "Just don't use [the standard library]" doesn't work when you want to use third-party libraries.
2) no_std's static checks are nice even in your own code. The value of static analysis has been argued about so many times in threads like these that I don't feel like re-treading that ground. But suffice to say: it's clear some people think they can write flawless code and don't see the benefits of assistance, but plenty of others know their limitations and benefit from static analysis.
3) Rust seems to have straddled an interesting and useful line in terms of which features are available in these limited contexts and which ones aren't, giving you as much to work with as possible. And thanks to #1 and #2 you can use those features fearlessly; you never have to guess about whether or not they're in the "safe" category. Hygenic macros in particular can act as a compile-time force-multiplier when you want better abstractions but don't want to (or can't afford to) do extra things at runtime.
As always comes up in these discussions: yes, you can technically cover this usecase with C and C++. You can technically cover it with raw assembly code, or binary strings, or a pair of wires. Don't discount ease-of-use as a factor that can take things from "technically possible but practically infeasible" to "doable and worth doing".
Not just technically: essentially all code covering "this usecase" -- operating peripheral cores -- is today C++ or C code.
It would be more meaningful to say you can technically do it in Rust, because it is possible in principle to do it, even though practically nobody ever has, and vanishingly few ever will.
Everyone who makes up an "embedded subset" congratulates themselves for identifying just the right subset. Then they immediately start moving other stuff over the line. And never stop. This is all familiar ground. All that is new is new people noticing it.
An embedded program in any language that relies on a library function not implemented in its runtime environment will, in any case, fail to link. That is static checking. Rust is not doing more static checking here. It is just doing it sooner, and forbidding a truly enormous amount of what would also be useful to embedded programs. Most of us would rather have access to all of that, and let the linker identify what support is needed for what is used.
When has "essentially all...today" ever placed a limitation on future progress?
How about you break "essentially all" down between these two different languages?
You must have good statistics on this, to have such confidence to say "essentially all" here, and yet for some reason you lump together C and C++ as if they're the same when you know they aren't. Might it in fact also have been true to say "essentially all" are C?
> Most of us would rather have access to all of that,
Which notable embedded systems did you program ncmncm? Or is "us" here based on a survey you can point us to about other embedded systems programmers who actually have practical experience?
But people also seem to be merrily using special-purpose high level languages for their domain e.g. P4. What I couldn't find much of was C++. If you had numbers we'd be looking at them, right?
I guess the advantage is that it sets a bar that means "can run in a wide range of environments" and it's a standard bar so that everything that's "no_std" can (more or less) run in the same wide range of environments.
But I don't know. A standard bar is nice, but I'm not sure it's really that much of a help.
I just dabble with embedded programming as a hobby, but it doesn't seem to me like non-Rust approaches (I'm thinking of C and Python) are suffering from a lack of composability.
I don't think Rust needs or benefits from that kind of promotion. It's a pretty good language that will get usable in more places as it matures. Overpromoting it into places it is not mature enough for yet causes problems. Is Rust mature enough for embedded use? In some places, certainly. In all places? Certainly not.
You've intentionally taken mine and others' words in the most uncharitable ways possible and you've displayed a general willingness to make this an unproductive discussion, so I'm going to stop engaging with you now.
Rust the language and Rust the community do not benefit from people posting transparent falsehoods. There is plenty of substance to Rust. It doesn't need puffing.
First discovering the world of embedded programming is tremendously exciting. We've all been there. Discovering all these embedded processors in equipment you already own compounds the excitement.
But programming "channel processors" goes back to the early '60s, six decades ago. We already know how. We haven't needed Rust. Embedded subsets are also re-invented over and over. That idea hasn't aged so well.
In practice, there is no upper limit to the complexity of code you might want to run in a channel processor, so you run into the boundary of your subset early. You often discover you want resource management support, so you link in an embedded RTOS. (OS as library did not originate with Unikernels.) There are many, many free RTOSes, many of them very good. The more POSIXy they are, the less fun and educational they might be.
But, to be clear: 1. There is nothing wrong with Rust, or with coding embedded Rust. 2. Rust brings nothing new to the embedded table, beyond what it does with ordinary programming; 3. non_std has been found by repeated experience over many decades to be a failed idea.
I don't like people promoting falsehoods on the internet. Instead of apologizing, just don't!
Now you want to pull in a library
Does that library work in that constrained environment, or will it break in obvious or subtle ways?
In Rust, no_std is a first-class crate attribute. It's enforced inside the crate, and it tells your crate as much when on a dependency. It's impossible (as far as I know) to accidentally use a std crate from your no_std crate, and for a no_std crate to accidentally use something from std internally (or in its dependencies). You can search for a crate on crates.io, and it can have dependencies of its own and dependencies for those dependencies, and you can integrate it all into your project without having to dig into the source code or whatever else to try and find out whether it will fit this set of constraints. That's powerful.
In C you would have to either write everything yourself, read through all of your dependencies, or just cross your fingers.
Since no_std would forbid an enormous amount of what you probably also want to use, you probably don't use it. Instead, you see what symbols the linker says need to be defined in your runtime support library, and add those.
The thing is, there is no single line that makes a library suitable for my project, whether it's for a constrained environment or not. I carefully consider many aspects of a library, all from the perspective of what, specifically, my project needs. no_std might be one thing to look for, but I don't know that it's really answering that many of my questions. Also, in my embedded dabbling, there seem to be such an incredibly rich set of libraries available for constrained environments it is astounding. So the lack of no_std doesn't seem to be holding non-Rust back.
> In C you would have to either write everything yourself, read through all of your dependencies, or just cross your fingers.
I really don't think no_std changes that at all.
> in my embedded dabbling, there seem to be such an incredibly rich set of libraries available for constrained environments it is astounding
What about more general libraries that aren't specifically designed for embedded scenarios? It seems like being able to know up-front whether or not those, for example, allocate, would be helpful