I may have wrong assumptions, but I find it funny they didn't use Golang. Is it not capable of doing the same thing ?
Anyway, happy to see rust being adopted for that usage.
Not just garbage collection but also the way hardware work is done with languages that allow you to write one-to-one memory representations in order to be able to drive raw interfaces of hardware. A GC language almost always comes with a reference based type system that hides the very interfaces you'd like to access (fast) and adds deserialization overhead which has visible performance and battery life effects.
The other reason is C interoperation. All of the common systems rely on C. C is not just a programming language. Since 80s everybody designs systems on top of C. We ended up with OSes written in C that ship their tightly integrated C compiler that outputs binaries optimized for C's memory layout and primitives that the very same OS runs on silicon that's optimized to run C fast. C unfortunately became the meta-language of the low level APIs.
Go's interoperability with C is out of hell. Its green-thread scheduler doesn't play well with C. The foreign function interface is defined in the comments (!) of a source file and making CGo work on custom cross toolchains is full of hard to solve compiler errors.
Rust can operate at the same level as C easily and it has all the low level primitives. C interoperability is a core language function that's part of the syntax and standard library. It solves many gotchas of C without compromising speed.
> Since 80s everybody designs systems on top of C.
More like since the 1990's, as outside UNIX during the 1980's no one cared about C, and mostly thanks to the GNU Manifesto and FOSS uptake that took the steam out of C++ adoption being pushed by Apple, IBM and Microsoft.
I did a lot of cross platform development work from 1982 onwards and 1987 was very much the year of C for Intel | DOS machines - they were cheap (comparitively), widely available and Borlands Turbo C was a fully integrated IDE that was affordable (and|or pirated) with some outstanding manuals.
Between that and their ASM for low level work, C took off in a big way and Pascal sharply dwindled in popularity (although it still hung on for a long time, even up to the present).
In Europe, in a MS-DOS world without cross-platform considerations, it took until Windows 3.x release, and Watcom C++ with its DOS extender for folks to really care about C and C++.
In fact, we used Turbo C 2.0 to prepare our code samples to deploy them into a single Xenix computer shared across the whole school, and that was it, nothing else.
Watcom was a much much better compiler and was welcomed with open arms to be sure - I still have a copy of the last release and use it on occassions.
If we're waxing historic here, my first C compiler (of my own and not a university VAX | PDP version) was the Cain | Hendrix Small C compiler (released 1980) which I handcopied in 1982 and extended over the next year or three as I read the Dragon books and other works .. bit of a side exercise while doing an engineering degree and working on a sheep shearing robot.
Thank-you Dr. Dobb's Journal of Computer Calisthenics & Orthodontia
The non-JVM code used in mentioned context will run in environments where yet another GC fighting the JVM GC isn't desired or have to be a shared library talking to existing JVM code. While you can use Go to build libraries with C calling convention, it's not the most supported use case and it shows in ergonomics. This also includes standard Go types and standard library which don't fit nicely into a model where code needs to talk a lot with JVM world.
It's possible... But it feels like screwing screws with a knife. It's doable, but noone from the language designers, stl designers and library developers are really thinking about that use case.
Rust on the other hand fits very well into the model where it needs to be just a piece of a bigger whole - it's been built that way ("system" programming language) and it doesn't come with GC that will fight with JVM or Binder lifetimes, compatible type system and plenty of libraries that help develop libraries on an embedded platform. When building the language, Rust designers consider this as one of the main use cases of the language and it shows with how much less hassle it is to work with.
The fact that it easily fits into existing C/C++ codebases helps too.
The blog immediately put that statement into context, stating that the binary file actually ended up replacing most of their stack. At the end of the day, they ended up with about the same size binary size. Also, they were not even really trying to optimize for size.
It worked rather well for Xerox PARC, TI, Genera and others, had they not mismanaged their products, or fighting against workstations being built with a free beer OS.
