4 ms·

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, tho

by przemoc 11y ago

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 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.

steveklabnik 11y ago
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.
- przemoc 11y ago
  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.
  - steveklabnik 11y ago
    There is actually preliminary support: https://github.com/rust-lang/rust/pull/24777 https://github.com/rust-lang/rust/pull/24777 Making this work well is a very high priority.
    - deleted 11y ago
      [deleted]
  - deleted 11y ago
    [deleted]
- jbrandmeyer 11y ago
  Alas, ARM describes a mutually incompatible family of related ISAs. Which ARM(s) is Rust tested on? V7-A, V6, V7-M, V4T?
  - steveklabnik 11y ago
    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-t 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.
    - sanxiyn 11y ago
      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.
  - dpc_pw 11y ago
    Works for me on ARMv8 (aarch64): https://github.com/dpc/titanos https://github.com/dpc/titanos , and I expect it to work on anything that LLVM supports.
evmar 11y ago
> 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.
- lambda 11y ago
  > 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.
  - geertj 11y ago
    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.
    - steveklabnik 11y ago
      Very, very, very many. https://github.com/rust-lang/rust/blob/master/src/snapshots.txt https://github.com/rust-lang/rust/blob/master/src/snapshots.... I've still thought about doing it.
    - Ruud-v-A 11y ago
      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 …

by przemoc 11y ago

steveklabnik 11y ago

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.

przemoc 11y ago
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.
- steveklabnik 11y ago
  There is actually preliminary support: https://github.com/rust-lang/rust/pull/24777 https://github.com/rust-lang/rust/pull/24777 Making this work well is a very high priority.
  - deleted 11y ago
    [deleted]
- deleted 11y ago
  [deleted]
jbrandmeyer 11y ago
Alas, ARM describes a mutually incompatible family of related ISAs. Which ARM(s) is Rust tested on? V7-A, V6, V7-M, V4T?
- steveklabnik 11y ago
  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-t 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.
  - sanxiyn 11y ago
    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.
- dpc_pw 11y ago
  Works for me on ARMv8 (aarch64): https://github.com/dpc/titanos https://github.com/dpc/titanos , and I expect it to work on anything that LLVM supports.

evmar 11y ago

> 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.

lambda 11y ago
> 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.
- geertj 11y ago
  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.
  - steveklabnik 11y ago
    Very, very, very many. https://github.com/rust-lang/rust/blob/master/src/snapshots.txt https://github.com/rust-lang/rust/blob/master/src/snapshots.... I've still thought about doing it.
  - Ruud-v-A 11y ago
    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 …