6 ms·

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/

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.

fastball 6y ago
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.
steveklabnik 6y ago
ARM themselves are sponsoring work on the aarch64 Linux target. https://github.com/rust-lang/rfcs/pull/2959 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!
davidhyde 6y ago
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.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
mmastrac 6y ago
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/workflows/release.yaml https://github.com/mmastrac/stylus/blob/master/.github/workf... https://github.com/mmastrac/stylus/blob/master/build.sh https://github.com/mmastrac/stylus/blob/master/build.sh
zip1234 6y ago
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.
- steveklabnik 6y ago
  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.
- bsder 6y ago
  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.

fastball 6y ago

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.

steveklabnik 6y ago

ARM themselves are sponsoring work on the aarch64 Linux target. https://github.com/rust-lang/rfcs/pull/2959 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!

davidhyde 6y ago

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.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

mmastrac 6y ago

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/workflows/release.yaml https://github.com/mmastrac/stylus/blob/master/.github/workf... https://github.com/mmastrac/stylus/blob/master/build.sh https://github.com/mmastrac/stylus/blob/master/build.sh

zip1234 6y ago

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.

steveklabnik 6y ago
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.
bsder 6y ago
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.