Hacker News Reader

Comment by linuxlizard | Hacker News Reader

I wish Rust's non-x86 support was a bit better. I wish I had time to jump in and help on the MIPs target. I wish I could figure out how to cross-compile to ARM/ARM64+uClibC. I wish I had a pony, too.

Very exciting to see a language tuned toward reliability taking off like this.

View on HN

ARM themselves are sponsoring work on the aarch64 Linux target. https://github.com/rust-lang/rfcs/pull/2959

I work in arm32 daily, it works well for us. Happy to help if you need some!

Do you mean Tier 1 support? There are just so many rust arm targets that it is difficult to make guarantees. Here is the official list if anyone is interested:

https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

Well, luckily with Apple hopping on board I'm sure they'll put the effort in to ensure they can compile to ARM targets.

A Rust + Swift, massively cross-compiled future sounds pretty nice actually.

I have an example of cross-compiling Rust to multi-arch docker images here via GH releases + cross, if it's helpful:

https://github.com/mmastrac/stylus/blob/master/.github/workf...

https://github.com/mmastrac/stylus/blob/master/build.sh

Limited experience here but seems like fairly large binaries for embedded as well. Though have not spent much time investigating how to make them smaller.

There's a ton of stuff you can do. If you don't care about binary size, they can blow up easily, but if you do, you can make it work. 145 bytes is the smallest binary rustc ever produced.

Actually, the embedded Rust guys track this.

no_std is the result of that. The panic/backtrace machinery turns out to be remarkably expensive. formatting machinery turns out to be expensive. etc.

The fundamental problem is that Rust relies REALLY hard on LLVM optimizing stuff away after code generation. That's not a good way to deal with embedded. It has issues even on Desktop, too (for example, the difference in speed between debug and release modes is enormous--often to the point that if you have performance code you can't realistically run a debug build to actually ... you know ... debug).

There are changes afoot because of MIR, but they will take a while to land.

People forget how many companies created weird and wacky compilers for C on 8-bit targets because C code was "too large/too slow/etc." And how many years those companies persisted.

Optimization for embedded takes time, and the amount of resources available for it is orders of magnitude smaller than general development.

Reply on news.ycombinator.com