Rust, Wright's Law, and the Future of Low-Latency Systems
The first 15 minutes are just historical rehash, and can be skipped over without missing anything at all.<p>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 &quot;no_std&quot;, where your build fails if your code tries to use any standard library features.<p>Of course, all those peripheral processors are <i>already</i> programmed, today, <i>almost all</i> 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.<p>Lots of peripherals, though, get their object code loaded into them by the kernel driver at startup before they will do anything useful.<p><i>Maybe someday</i> it will get easier to download your own code into them from a running system, to extend what they are already doing, and <i>maybe someday</i> 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 <i>is</i> happening in certain, select places, like some NICs -- Rust will have no advantage over other languages. Using &quot;no_std&quot; will not materially help.<p>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&#x27;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.<p>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.<p>Of course none of the other languages have &quot;no_std&quot;, and don&#x27;t need it. Your Rust code doesn&#x27;t need it either. Don&#x27;t want to use library features? Just don&#x27;t use them. The things an eBPF program is allowed to do are quite limited, but surprisingly powerful, including calling out to a special (&quot;standard&quot;) eBPF library. That Rust&#x27;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.