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.

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.