5 ms·

> Until Rust can solve its massive binaries, that is somewhere on their roadmap, it just isn't appropriate for use in the embedded world, where kilobytes still

• shakna 10y ago
  2 very big things. 1. > How big was it before compression? - CyberDiablo > Just over 200kb iirc - yupferris 2. Avoid the standard library is a whole lot of effort. With C, and code elimination with GCC or clang, using fairly standard optimisations that require next to no knowledge of the native code being produced, I can have the following libraries, without bloating the executable: <assert.h> <complex.h> <ctype.h> <errno.h> <fenv.h> <float.h> <inttypes.h> <iso646.h> <limits.h> <locale.h> <math.h> <setjmp.h> <signal.h> <stdalign.h> <stdarg.h> <stdatomic.h> <stdbool.h> <stddef.h> <stdint.h> <stdio.h> <stdlib.h> <stdnoreturn.h> <string.h> <tgmath.h> <threads.h> <time.h> <uchar.h> <wchar.h> <wctype.h> Though you are incredibly unlikely to use all of the above at once, and occassionally some are unavailable on more limited embedded hardware (e.g. threads), C and its current compilers are light years ahead of rustc in terms of optimisation, even more so when you look at the massive list of supported architectures: GCC [0], Clang [1] I love Rust, and I do look forward to seeing more of it, but avoiding libstd, or using a different malloc, and being forced to use a nightly, or any of the other little things you can do to mitigate large binaries are just not something that is easy compared to C, or easy to pipeline when making embedded software. Relying on executable compression not directly supported by the compiler, is asking for trouble. You can do the same insane things like no stdlib in C too [2], but it doesn't mean its a good idea. (See the IOCCC [3] for some truly crazy manipulations of the C language!) [0] https://gcc.gnu.org/backends.html https://gcc.gnu.org/backends.html [1] http://llvm.org/docs/doxygen/html/classllvm_1_1Triple.html http://llvm.org/docs/doxygen/html/classllvm_1_1Triple.html [2] http://ptspts.blogspot.com.au/2013/12/how-to-make-smaller-c-and-c-binaries.html http://ptspts.blogspot.com.au/2013/12/how-to-make-smaller-c-... [3] http://www.ioccc.org/years.html http://www.ioccc.org/years.html
  • steveklabnik 10y ago
    Don't forget, "losing the standard library" doesn't mean losing everything; it means losing libstd, but not libcore. A lot of those headers you're showing off would be in libcore, not in libstd, in Rust terms. > C and its current compilers are light years ahead of rustc in terms of optimisation, Given that we use LLVM, which is the part of clang that does most of the optimizing, we should be equivalent here, roughly. (That said, I agree that there's more we can do to make this easy.)
    • shakna 10y ago
      I really don't like that I lose anything, but sure. Rust isn't yet equivalent to clang in terms of LLVM, because of the overhead of some of the libraries that it needs. Like its own malloc implementation. These are acceptable costs to get security. I hope I haven't come across as disliking Rust, because I love it. Unfortunately, when it comes to embedded, bytes matter, and those overheads aren't easy to limit or abolish in a simple manner. So you lose out on the security, and have strange compression scripts, or you lose out on the security and use C. For now, the second is an easier sell to a manager. I am expecting there will be progress here, from a few of the issues I've seen open on GitHub. And I really like your work.
      • pcwalton 10y ago
        Rust doesn't need its own malloc implementation.
  • pcwalton 10y ago
    > Just over 200kb iirc - yupferris So just to be clear, is your position that the demo could have been better if it were written in C? That flies in the face of all the evidence (that, you know, that it won against all its competitors, and that 200kB isn't even large by C standards), but if so, you should be up front about that. > C and its current compilers are light years ahead of rustc in terms of optimisation, "Light years"? Come on! The backends are the same! This is totally contrary to my experience. Bringing up extra architectures supported by GCC/Clang is irrelevant to the discussion. Especially since rustc uses the same backend as Clang. And header files are not libraries! You get essentially all of these with libcore. Citing things like stdbool is especially irrelevant, because bool is builtin in Rust. Assert is a macro in Rust that expands to nothing in the binary. Most of math.h is covered by LLVM intrinsics, which you get with libcore. Using a nightly Rust is as easy as using GCC. Really. Just use rustup and switch to the nightly channel. In fact, compared to, say, setting up a GCC cross toolchain for embedded development, it's a breeze. Xargo makes cross platform package management incredibly easy; in fact there's nothing like it in C land. Using a different malloc is as easy as "extern crate alloc_system". I do it when testing Servo when I want to make use of the platform native malloc instrumentation. It's far easier than in C, in fact. Not using the standard library is hardly "insane". A lot of projects do it. It's a first-class thing. All of these problems are total non-issues. There are zero good reasons why, in 2016, a command line Web fetching tool should be written in C.