14 ms·

I think one of the big issues with Rust is that it isn't as portable as C. Bootstrapping Rust is hard, doing the same for C is simple. I could create a simple

I think one of the big issues with Rust is that it isn't as portable as C. Bootstrapping Rust is hard, doing the same for C is simple. I could create a simple C compiler just to bootstrap the real C compiler, something I have actually done once or twice before. That's not something you do with Rust, at least from the limited experience I have with Rust.

jjnoakes 9y ago
I agree, and this is the only thing stopping me from putting rust into production. I have high hopes for something like https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
- steveklabnik 9y ago
  What architectures matter to you?
  - jjnoakes 9y ago
    Of all the architectures I contract for, I think AIX is the one furthest behind as far as LLVM and Rust support goes.
    - nickpsecurity 9y ago
      Is there an ISA call AIX or did you mean platform support for AIX operating system on POWER?
      - jjnoakes 9y ago
        I mean AIX on Power (BE).
    - steveklabnik 9y ago
      Cool thanks, always trying to hear what we need to work on.
infogulch 9y ago
Rust is based on LLVM so it can only support the architectures that are supported there (save maybe a reimplementation like sibling comment mentioned). What I don't understand is this whole thing about bootstrapping a new arch by building a whole new compiler on it, then compiling the source of an existing compiler on it (twice). Bytes of machine code don't have color, it's just a regular pile of bytes like everything else. Why does the compiler even have to run on the new arch? Just build a new backend for an existing compiler, then cross compile. It makes no sense to me why the machine code of a system must be assembled on that system. I don't mean to sound adversarial, I'm just very confused.
- cesarb 9y ago
  > It makes no sense to me why the machine code of a system must be assembled on that system. Assembling the machine code of a system on itself means it's independent of its "parent" system. If I can't run the compiler on my new architecture (including compiling itself), I'll forever depend on having another machine with a different architecture to compile things. Yes, usually it's done by writing a new backend for an existing compiler, then using the new backend to cross-compile the compiler itself, and finally running the resulting compiler on the new architecture; you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks. In the same way, when compiling a new version of a compiler, having the recently-built compiler build itself again makes sure it's independent of its "parent" compiler.
  - nickpsecurity 9y ago
    "Assembling the machine code of a system on itself means it's independent of its "parent" system." Far as a compiler, that doesn't really matter for most systems (esp embedded). You can cross-compile to any architecture you want with portable code and a new backend. The only tools you need for each architecture's CPU's/MCU's are something to load and test the code. Those already exist in embedded sector. Instrumentation for Rust code would be necessary but this doesn't involve doing the whole compiler on, say, an 8-bitter. "you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks." That's an SCM security problem. You'd need to trust every compiler developer, the repo it's stored in, the transmission process, and whatever you used to build it. Most supposed solutions focus on the last one almost exclusively when the first three were the source of most attacks historically. In any case, that's barely relevant to the discussion of using Rust on a new architecture as almost nobody will every be hit by that & most people wanting Rust backends aren't doing high-assurance security for stopping nation-states or something. Those people hand-verify the assembly anyway.
lloydjatkinson 9y ago
Rust is also 32bit/64bit. That's totally fine (obviously) for PC-like situations and servers and more powerful embedded systems, etc. But there are literally billions of 8bit and 16bit embedded systems out there, many of which have a C compiler.
- steveklabnik 9y ago
  There is some limited 16-bit support happening.
  - dbaupp 9y ago
    And AVR too: https://github.com/rust-lang/rust/issues/42450 https://github.com/rust-lang/rust/issues/42450
- nine_k 9y ago
  Are 8-bit systems still being used for new development?
  - ajb 9y ago
    There are still 24-bit systems used for new development.
  - ruste 9y ago
    Microcontrollers? Absolutely.
  - nickpsecurity 9y ago
    There's 8-bit MCU's all over the place. I tried to find some numbers for you with a quick Google. This 2014 Amtel report puts 8-bitters at $6+ billion a year. Even the 4-bitters are still making hundreds of millions a year. I include a bonus link on that if it perplexes you. http://www.atmel.com/Images/45107A-Choosing-a-MCU-Fredriksen_Article_103114.pdf http://www.atmel.com/Images/45107A-Choosing-a-MCU-Fredriksen... http://www.embeddedinsights.com/channels/2010/12/10/considerations-for-4-bit-processing/ http://www.embeddedinsights.com/channels/2010/12/10/consider... Far as future, Jack Ganssle of The Embedded Muse has a nice assessment of it summarizing various sides: http://www.ganssle.com/rants/is8bitsdying.htm http://www.ganssle.com/rants/is8bitsdying.htm
sadiq 9y ago
Worth pointing out an approach that Julia took, compiling LLVM to C might also work for Rust: https://juliacomputing.com/blog/2016/03/10/j2c-announcement.html https://juliacomputing.com/blog/2016/03/10/j2c-announcement....
pjmlp 9y ago
In 2017. C wasn't that portable in the 80's and 90's, with all its flavous across CP/M, MS-DOS, 8-bit home micros, mainframes, ...
- jeffdavis 9y ago
  The difference is that one could reasonably write a C compiler in assembly, and use that to bootstrap a better C compiler if desired. Writing a rust compiler in assembly might be challenging.
vvanders 9y ago
You'd think this is the case but in practice it's actually pretty solid. Right now I've got a nontrivial(opengl + vm language + ssl + http) project with a mix of C/Rust I'm bringing up that runs on: x86_64-mscv x86_64-osx x86_64-linux armv7-android i686-android arm-linux-hf armv7-linux-hf Aside from needing a linker per-platform rustup takes care of all the LLVM stuff, it's really much simpler that I thought it would be.

jjnoakes 9y ago

I agree, and this is the only thing stopping me from putting rust into production. I have high hopes for something like https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc

steveklabnik 9y ago
What architectures matter to you?
- jjnoakes 9y ago
  Of all the architectures I contract for, I think AIX is the one furthest behind as far as LLVM and Rust support goes.
  - nickpsecurity 9y ago
    Is there an ISA call AIX or did you mean platform support for AIX operating system on POWER?
    - jjnoakes 9y ago
      I mean AIX on Power (BE).
  - steveklabnik 9y ago
    Cool thanks, always trying to hear what we need to work on.

infogulch 9y ago

Rust is based on LLVM so it can only support the architectures that are supported there (save maybe a reimplementation like sibling comment mentioned). What I don't understand is this whole thing about bootstrapping a new arch by building a whole new compiler on it, then compiling the source of an existing compiler on it (twice). Bytes of machine code don't have color, it's just a regular pile of bytes like everything else. Why does the compiler even have to run on the new arch? Just build a new backend for an existing compiler, then cross compile. It makes no sense to me why the machine code of a system must be assembled on that system. I don't mean to sound adversarial, I'm just very confused.

cesarb 9y ago
> It makes no sense to me why the machine code of a system must be assembled on that system. Assembling the machine code of a system on itself means it's independent of its "parent" system. If I can't run the compiler on my new architecture (including compiling itself), I'll forever depend on having another machine with a different architecture to compile things. Yes, usually it's done by writing a new backend for an existing compiler, then using the new backend to cross-compile the compiler itself, and finally running the resulting compiler on the new architecture; you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks. In the same way, when compiling a new version of a compiler, having the recently-built compiler build itself again makes sure it's independent of its "parent" compiler.
- nickpsecurity 9y ago
  "Assembling the machine code of a system on itself means it's independent of its "parent" system." Far as a compiler, that doesn't really matter for most systems (esp embedded). You can cross-compile to any architecture you want with portable code and a new backend. The only tools you need for each architecture's CPU's/MCU's are something to load and test the code. Those already exist in embedded sector. Instrumentation for Rust code would be necessary but this doesn't involve doing the whole compiler on, say, an 8-bitter. "you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks." That's an SCM security problem. You'd need to trust every compiler developer, the repo it's stored in, the transmission process, and whatever you used to build it. Most supposed solutions focus on the last one almost exclusively when the first three were the source of most attacks historically. In any case, that's barely relevant to the discussion of using Rust on a new architecture as almost nobody will every be hit by that & most people wanting Rust backends aren't doing high-assurance security for stopping nation-states or something. Those people hand-verify the assembly anyway.

lloydjatkinson 9y ago

Rust is also 32bit/64bit. That's totally fine (obviously) for PC-like situations and servers and more powerful embedded systems, etc. But there are literally billions of 8bit and 16bit embedded systems out there, many of which have a C compiler.

steveklabnik 9y ago
There is some limited 16-bit support happening.
- dbaupp 9y ago
  And AVR too: https://github.com/rust-lang/rust/issues/42450 https://github.com/rust-lang/rust/issues/42450
nine_k 9y ago
Are 8-bit systems still being used for new development?
- ajb 9y ago
  There are still 24-bit systems used for new development.
- ruste 9y ago
  Microcontrollers? Absolutely.
- nickpsecurity 9y ago
  There's 8-bit MCU's all over the place. I tried to find some numbers for you with a quick Google. This 2014 Amtel report puts 8-bitters at $6+ billion a year. Even the 4-bitters are still making hundreds of millions a year. I include a bonus link on that if it perplexes you. http://www.atmel.com/Images/45107A-Choosing-a-MCU-Fredriksen_Article_103114.pdf http://www.atmel.com/Images/45107A-Choosing-a-MCU-Fredriksen... http://www.embeddedinsights.com/channels/2010/12/10/considerations-for-4-bit-processing/ http://www.embeddedinsights.com/channels/2010/12/10/consider... Far as future, Jack Ganssle of The Embedded Muse has a nice assessment of it summarizing various sides: http://www.ganssle.com/rants/is8bitsdying.htm http://www.ganssle.com/rants/is8bitsdying.htm

sadiq 9y ago

Worth pointing out an approach that Julia took, compiling LLVM to C might also work for Rust: https://juliacomputing.com/blog/2016/03/10/j2c-announcement.html https://juliacomputing.com/blog/2016/03/10/j2c-announcement....

pjmlp 9y ago

In 2017. C wasn't that portable in the 80's and 90's, with all its flavous across CP/M, MS-DOS, 8-bit home micros, mainframes, ...

jeffdavis 9y ago
The difference is that one could reasonably write a C compiler in assembly, and use that to bootstrap a better C compiler if desired. Writing a rust compiler in assembly might be challenging.

vvanders 9y ago

You'd think this is the case but in practice it's actually pretty solid. Right now I've got a nontrivial(opengl + vm language + ssl + http) project with a mix of C/Rust I'm bringing up that runs on: x86_64-mscv x86_64-osx x86_64-linux armv7-android i686-android arm-linux-hf armv7-linux-hf Aside from needing a linker per-platform rustup takes care of all the LLVM stuff, it's really much simpler that I thought it would be.