2025-09-01
During my years as a postdoctoral fellow, I led the development of several science and engineering products. These products were built using combinations of embedded electronics and software, desktop software, and mechanical and HPLC fluidic parts. If you've worked across these disciplines, you can imagine the nightmarish scenario that results from combining together these particulars to form a single multidimensional product.
I'm tempted to say that fluidics is the most difficult of the particulars. This is not necessarily the case as fluidic complexity does depend upon specific requirements. In my case, the project required the fluidics to operate at high pressure and high temperature while also maintaining high-precision dynamic and static flow behavior. Needless to say, breathing (literally) near the apparatus often proved sufficient to destabilize and destroy experiments.
Just in case you are curious about the microfluidic pressure and temperature requirements, the ballpark figures were around 10 bar and 150°C. As for stability, particles inside the liquid phase were accessible only through a 60x microscope lens, so the tiniest flows were amplified.
Compared to the fluidic nightmare requirements that I was constrained to work with, electronics and software were truly in the tractable column. Unlike highly pressurized liquid inside tiny flexible tubing that always want to escape and squirt all over the lab equipment, electrons in electrical circuits generally prefer to remain with the copper conductor. Software is even more friendly once the language and tools are understood. The wonderful thing about software is that if you have a problem, you simply fix the bug from the comfort of your chair and recompile the code. You are not confined to a cold, darkened, coffee-free lab and there are no messes to clean up.
But software has its own kind of difficult. While building fluidic systems requires a small number of carefully chosen parts, and electronics requires a large number of carefully chosen parts, software offers a combinatorial explosion of possibilities. How many times have I heard people say that really smart algorithms are not always the best, because the next person actually needs to understand how that genius algorithm works. The reality is, there are a million different ways to write a piece of code, and mastery of a single programming language takes years. To make matters worse, there are hundreds of programming languages, each with its cheerleaders and benefits.
So where am I going with this?
I did a presentation in Blenheim about a year ago titled "Rust 101 -- World Domination?". The title was actually mostly serious, with a few coffee beans thrown in. In the 1990s Java and its coffee cup were the Promised Land and the phrase "write once, run anywhere" was the creed. Needless to say, Java succeeded in the sense that it is still around today and is still being taught 25 years after my undergrad days, probably in the same lecture theaters. But the "write once, run anywhere" promise of Java failed. To the best of my knowledge, desktop apps are rarely if ever written in Java, and embedded software is also a Java-free zone. The suggestion of Rust World Domination therefore doesn't have a lot of precedent.
But I really do think that Rust is different. As I said in my presentation, Rust is already running everywhere.
For example, Rust is running in the embedded space. The Embassy project currently supports a variety of STM32, Nordic, Raspberry Pi Pico and ESP32 microcontrollers. I can write embedded code in my fantastic Zed editor (written in Rust), compile it to binary, and send it via probe-rs to the target device. This is C-speed binary code running on bare metal, not byte code running on a virtual machine.
If I want to USB-communicate with the target microcontroller using HID or CDC communications, I can do so with nusb or hidapi or another USB crate. These USB crates work across platforms: Windows, Mac, Linux and Raspberry Pi. As far as I know, the only other popular language that provides that level of cross-platform functionality is Python with pyserial and I don't recall pyserial providing HID.
But Rust is better than this. As well as low-level cross-platform USB comms, Rust also has a few fantastic GUI front-end options with others being studied and developed. You can check out these GUI projects at areweguiyet but my preferred option is the MIT-licensed egui (see also the project lead's rerun website) and you can find an incredible egui demo at www.egui.rs. Note that this demo is running WASM code, which means that the Rust code was compiled to Web Assembly and runs sandboxed in the browser at close to native speed. I don't know the exact speed numbers but I think WASM is generally around 3x slower than raw native Rust code which is quite impressive. Furthermore, the egui Rust code running in your browser can be compiled into a cross-platform binary, almost with a click of the finger. The resultant --release binary size should be around 14 MB. Did someone say that Electron is around 600 MB before you do any of your own customizations?
Perhaps you don't want egui but prefer instead something a bit more retro, smaller, faster and lightweight. In that case we might opt for Ratatui which I now know something about since the Turkish lead of the Ratatui project was in Wellington a few days ago at RustForge 2025.
Since I mentioned RustForge 2025 in Wellington, I should also mention a couple of other workshops that ran before the two conference days. A lead on the Bevy project took a thirty-hour flight from Germany to provide some Bevy training (it was appreciated!). Bevy is generally considered to be a Rust gaming engine in the same genre as Unreal and Unity, but apparently most 3D Bevy usage is not in the gaming space. That is interesting and I also have some ideas for the non-gaming space. Take a look at the Bevy demos -- the demo code is very elegant.
The other RustForge workshop that I will mention was focused on the Leptos project. Leptos is a full-stack Rust framework for the modern web. If this is your space then Leptos may be the cool tool for your work. To the best of my understanding Leptos provides full client-server plumbing between the client and server using WASM rather than JavaScript. I suspect this is something like Blazor in the Microsoft C# world. Leptos also provides hot reloading.
I didn't mean to go on this long, so all of this is to say that from my vantage point at least, Rust is rapidly filling every niche within the software landscape. In every case (with the possible exception of WASM), and unlike Java, Rust compiles to ones and zeros which means that it is super fast with small binaries. Not only does Rust compile into the embedded space, but also makes it possible at long last to "write once, run anywhere". And this is a large part of the reason I have adopted Rust. Rust allows me to write code for all my platforms and devices using a common language!
But cross-platform-device-ness is only part of the reason that I think that Rust wins. There are many other reasons. One is that Rust programs run as fast as a speeding bullet, like C and C++. Another is that it is no longer necessary to learn multiple different programming languages. Rust's ecosystem allows developers to focus on learning one language well. And another is the fact that the compiler is your friend, even if it points out all your faults. In my experience, if my Rust code compiles, I can be confident that my Rust code will almost certainly run and even run correctly.
Comments are welcome via the feedback form and may be added below.
(c. 1,300 words)