Althea Development Update #40: proc_macro and the language tradeoff

I post bi-weekly development updates for Althea, in the past I’ve done this on Reddit but with development ramping up I’ve decided to move them here.

Alpha Deployment Status

In our last update we hoped to have the minimum viable firmware done to roll out to our Alpha users. Not quite there yet I’m afraid, we spent a lot of the last two weeks trying to raise a seed round and it was exhausting beyond words, although coming to an end now. Our partners in Clatskanie are similarly delayed with network hardware setup by a cavalcade of personal mishaps and bad weather. Overall progress continues and we don’t expect to be too far delayed, we may still hit the end of the month.

proc_macro woes

Althea selected Rust as it’s major implementation language several months ago after a lot of discussion. Other modern languages such as GO, Python, or Javascript would all consume too much memory and disk space pretty rapidly. Especially if we developed by pulling in lots of libraries.

C and C++ would be both more performant and small enough but lacked modern safety features. There are developers who can write great cryptography and blockchain applications without these safety properties through heroic effort and care. But we would prefer to avoid the risk.

In comes Rust, a modern compiled language that promises the best of both worlds. The safety of a modern language but the speed and size of C/C++ even when using large libraries.

Well obviously I’m talking about problems, so what went wrong?

proc_macro is a very cool part of the Rust language, it allows compile time syntactic sugar to be turned into static and efficient compiled code.

#[derive(Serialize, Deserialize, Debug)]
struct Point {    
  x: i32,    
  y: i32,
}

It’s great when it works, which is all the time on desktop. Sadly for OpenWRT targets we’re getting that new language smell.

Unable to find crate `proc_macro` on musl target · Issue #40174 · rust-lang/rust
Using procedural derive macros on musl seems to work just fine for the most of the cases, but there is one pitfall; in…github.com

Use of proc_macro is very pervasive because it’s just so darn convenient and great. Working low level magic with almost no developer effort. After evaluating our options we’ve decided to make a serious attempt at fixing this in Rust upstream.

If that fails we can always just avoid using code that triggers this issue. But it would be really great to live the dream of no compromises embedded development. Even if we have to do some work to get there.

Big thanks to contributor drozdziak1 for doing a lot of the investigative work here.