Comment by przemoc | Hacker News Reader

Comment by przemoc | Hacker News Reader

Now that Rust reached v1.0, I may finally look into it without the fear of wasting time to learn stuff that will change within next months. (It's quite sad, though, that recently released Debian Jessie won't have it in its main repositories.)

Allow me to ask some questions, because I cannot easily find the answers and they're IMHO crucial for wider Rust adoption:

1. What CPU architectures/platforms Rust currently supports?

2. What's the state of cross-compilation support?

Most of devs have workstation on i386/amd64, but some of us may work with ARM, PowerPC and other architectures. Rust's memory safety seems appealing for embedded solutions, but can it be used there already?

BTW The install page is not well-thought-out.

http://www.rust-lang.org/install.html

Unless I hover on the 32-bit/64-bit links and read addresses they point to, there's no way to tell whether it's for x86 or ARM for instance. And installation via piping script that is being downloaded to shell is something that shouldn't be present at all.

1. In a sense, anything LLVM supports. Some stuff is more first-class than others, of course. We test every commit on x86, x86_64, and ARM.

2. Exists, but isn't particuarly easy. The biggest hurdle is getting a copy of the standard library for the target platform, then it's pretty easy. It's gonna be a focus in the near-term.

Thank you for such a prompt answer.

EDIT:

Quick googling revealed that Rust doesn't work with musl libc yet. It will be really nice when it will be fixed.

There is actually preliminary support: https://github.com/rust-lang/rust/pull/24777

Making this work well is a very high priority.

Alas, ARM describes a mutually incompatible family of related ISAs. Which ARM(s) is Rust tested on? V7-A, V6, V7-M, V4T?

Ah, so you know what: I thought we tested Android on ARM, but apparently it's x86 and x86_64 too: http://buildbot.rust-lang.org/buildslaves/linux-64-x-android...

There's a community member that keeps the iOS build green, I forget which ARM that is.

We do test Android on ARM. That's an x86_64 buildbot which builds a cross-compiler to Android on ARM and executes a full test suite on Android emulator using a remote testing support which even includes running gdb remotely.

The official tested support is for V7-A, but V6 support also is in tree.

Works for me on ARMv8 (aarch64): https://github.com/dpc/titanos , and I expect it to work on anything that LLVM supports.

> installation via piping script that is being downloaded to shell is something that shouldn't be present at all

The alternative is you download a binary and run it, at which point that binary can do whatever the shell script could have done.

(The other alternative is you download source, at which point the Makefile or any other piece of the build that you execute can do whatever the shell script would have done.)

As long as the script is available via https the security is equivalent to the alternatives.

> The other alternative is you download source, at which point the Makefile or any other piece of the build that you execute can do whatever the shell script would have done

Part of the problem with this is that since it's a bootstrapped compiler, and the only one for the language so far, "downloading source" mean you need a binary to compile it with, which devolves to the same problem.

Rust was bootstrapped with an OCaml based compiler. Alas I don't think it has been kept up to date, so you won't be able to use it to compile the v1.0 source. Not sure how many generations in between the last OCaml compilable rust and the current rust you'd need to compile to bootstrap, probably quite a few.

Very, very, very many. https://github.com/rust-lang/rust/blob/master/src/snapshots....

I've still thought about doing it.

A while back, somebody got Cargo running on an unsupported platform, but bootstrapping was a major problem. The compiler had to bootstrap newer versions of itself tens of times, and that was only for a few weeks of breaking changes …

Reply on news.ycombinator.com