rustybox, an experimental fork written entirely in Rust

[Harald van Dijk]

On 15/11/2019 00:29, Eli Schwartz wrote:
> On 11/14/19 5:33 PM, Markus Gothe wrote:
>> How do you think that fatso library aptly named librust would fit into any
>> modest embedded system? Well it doesn't and you never thought of that in the
>> first place which makes the rest of your assumptions more damaging than any good.
> 
> I was under the impression that rust programs don't depend on librust at
> all, due to being statically compiled. My instinctive reaction to
> porting anything to rust would instead first center around "is rust
> itself portable?"

The supported hosts and targets are listed at 
<https://forge.rust-lang.org/release/platform-support.html>.

> To which the answer is a resounding no. C compilers are everywhere, and
> busybox should be able to compile and run on any unix-like platform, one
> hopes,

busybox should be able to run on any Unix-like platform, and should be 
able to compile on any Unix-like platform with a C compiler. Building on 
one computer in order to run it on another, where the latter lacks a C 
compiler, is quite common. Whether a C compiler could be installed on 
that other computer is not relevant.

>        whereas rust is only available on platforms that the reference
> implementation of rust (the only implementation of rust) is available.

Like many C compilers, rust is also able to cross-compile to many 
platforms, regardless of whether a compiler is present on that platform 
itself.

> Rust is also written in rust so you cannot bootstrap it to new
> platforms.

You should be able to cross-compile rustc for another platform. This is 
exactly what you need to do with GCC in order to bootstrap GCC on a new 
platform as well. You cannot do that with another compiler either, 
unless you limit the number of supported languages: its Ada frontend is 
written in Ada.

>            Rust only has first-class support for Windows, Linux, and macOS.

GCC does not include Windows on its primary platforms list. 
i686-pc-cygwin and i686-mingw32 are secondary platforms. If I were asked 
"Does GCC work on Windows?", my answer would be an unqualified yes, I 
would not get into a discussion of how Windows issues are prioritised 
differently from Linux issues.

Rust does not include FreeBSD and NetBSD on its Tier 1 platform list, 
but does on its Tier 2 platform list, and provides rustc binaries for 
them. These platforms should be considered as well.

> That being said, the size of a statically compiled rust program is also
> of concern. A minimally viable hello_world.rs compiled with static musl
> libc, and stripped, is 248K -- a minimally viable hello_world.c compiled
> with musl-gcc -static is 16KB.
> 
> (At least it is not as bad as golang, where "hello world" is 1.4 MB,
> larger than the entire busybox suite with all the fatty options enabled
> for my desktop build.)
> 
> Also google-fu says you can "cheat" by embedding non-rust inside your
> rust, to reduce some overhead of using rust:
> https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html

Technically true in that it uses libc's "write" function, but that is 
just a thin wrapper around the underlying syscall. Other than that, I am 
not seeing what non-rust code is getting embedded. Could you elaborate?

> But on the whole it seems simpler to stick with what is known to work
> and has no known downsides.

C has known downsides as well. The fact that they are considered 
acceptable for busybox does not mean they do not exist.

I do not expect a Rust version of busybox to replace the C version, but 
a faithful translation into idiomatic Rust could be useful regardless: 
if someone wants to spend time on this and does it well, without 
completely rewriting bits of code, either it will reveal previously 
unknown issues in busybox that can then also be fixed in the official C 
version, improving the quality of busybox, or it will reveal that the 
issues that Rust is designed to prevent do not exist in busybox, 
increasing the confidence in busybox.

Cheers,
Harald van Dijk