Why Rust? What a 1 GB Orange Pi taught me

Rust had been on my list for years, but a busy workload never left me the time to start. A memory problem on an Orange Pi PC Plus in the field finally made it impossible to put off.

#The problem

We had services collecting sensor data from devices in the field over MQTT. They ran on Node.js on an Orange Pi PC Plus. The board has 1 GB of memory, shared between the operating system, the MQTT broker and our own services.

The first days went fine. Then I noticed a pattern: the services' memory use crept up over hours and never came back down. Node was leaking memory. On a 1 GB board there is only one way that ends: memory fills up, the system slows down, and eventually the service, or the whole device, stops responding.

#My first reaction: restart it

My first fix was what most people would do. I put the service under systemd and let it restart itself with Restart=always whenever it crashed.

That was a band-aid, not a fix. Every restart left a gap of a few seconds, and any data arriving in that window was lost. I hadn't solved the problem, I had hidden it.

#The real issue

At some point I accepted that the problem wasn't a single bad line. I was running a runtime that relies on a garbage collector, and on when that collector decides to run, on a device where memory is this scarce. A leak nobody would notice on a server was taking the system down within days on a 1 GB board.

What I needed was:

• Memory use that is predictable.
• Leaks caught while writing the code, where possible, not at runtime.
• A small, single executable that doesn't carry a whole runtime with it.

#Why Rust?

C or C++ would have given me the same control. But then the whole burden of memory safety would be mine. Escaping leaks, I would be fighting overflows and invalid memory access instead.

Rust sits between the two. There is no garbage collector; when memory is allocated and freed is known. Ownership rules let the compiler check that. So I see most of my mistakes at compile time, not on a device that crashes in the field at midnight.

#I considered Go too

Before settling on Rust I took a serious look at Go. Go also compiles to a single executable, it is easy to learn and it is everywhere on the server side. But I made the call on data, not curiosity. Among the languages I evaluated (Node.js, Go and Rust), Rust was the fastest by a wide margin:

• Speed and energy: In the study by Pereira et al. at the University of Minho, which compares 27 languages on the same 10 problems, execution time normalised to C, the fastest language, is 1.04 for Rust, 2.83 for Go and 6.52 for JavaScript. Energy use follows the same order: Rust 1.03, Go 3.23, JavaScript 4.45. Rust is nearly level with C and, in this measurement, about 2.7 times faster than Go.
• Recent measurements: In The Computer Language Benchmarks Game results comparing Rust 1.84 with Go 1.23, the fastest Rust program finishes ahead of the fastest Go program on all 10 listed problems. For example 0.95 seconds against 3.77 seconds on mandelbrot, and 0.72 seconds against 1.43 seconds on spectral-norm.
• Garbage collection: Go has a garbage collector; Rust doesn't. That is exactly why Discord moved its "Read States" service from Go to Rust in 2020: Go's garbage collector was forced to run every two minutes and caused regular latency spikes. The service rewritten in Rust no longer had them.

To be fair, Go is not behind on every measure. In the same study Go does better than Rust on memory use (1.05 against 1.54). But the problem on my device was less the total amount of memory than not knowing when it would be released. With no garbage collector and C-level speed, Rust was the better fit for what I needed.

#Conclusion

This taught me that the right tool depends on the environment where the problem lives. Node.js is still a great tool for many jobs. But on an edge device where every megabyte counts, I had to choose control over uncertainty. Rust had been on my list for years; this problem in the field is what finally got me started.

#Sources

• Rui Pereira et al., Energy Efficiency across Programming Languages: How Do Energy, Time, and Memory Relate?, SLE 2017, Table 4.
• The Computer Language Benchmarks Game: Rust vs Go
• Discord Engineering, Why Discord is switching from Go to Rust, 2020.