5 ms·

Nobody wants to play with their compiler to get a small binary. Languages are typically judged by their defaults. If rust can produce small binaries, then it mu

Nobody wants to play with their compiler to get a small binary. Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries.

vbezhenar 7y ago
If big binary works faster, I would prefer big binary any day. Nobody cares about disk size.
- na85 7y ago
  >Nobody cares about disk size. Embedded people care.
  - Koshkin 7y ago
    To be fair, “embedded people” do not use disks.
    - pjmlp 7y ago
      They do when they embedded device happens to be a phone, tablet, POS, medical monitoring device, ...
  - carlmr 7y ago
    Depends on the system, embedded is a very large section of the market.
- shakna 7y ago
  And for most compilers, changing whether you care about binary size or performance, is a single switch away, not a series of enhancements you need to refer to a blog page to ensure you're doing it right.
  - steveklabnik 7y ago
    Rust does have the same switches C compilers have, that do the same things.
steveklabnik 7y ago
The point is to demonstrate what's inherently overhead and what isn't. Rust has effectively the exact same inherent overhead as C does; that's the point. > Nobody wants to play with their compiler to get a small binary... If rust can produce small binaries, then it must produce small binaries. Everything is a tradeoff. Smaller binaries may or may not perform better than larger ones. This is something you need to play with, just like in C. If one single setting made everything the best in all circumstances, it wouldn't be a setting. C compilers have these settings too. > Languages are typically judged by their defaults. As I mentioned, the defaults have also been adjusted to help out too.
deleted 7y ago
[deleted]
fluffything 7y ago
> Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries. Code size isn't the only axes that can be used to measure the quality of a binary, there are many others: like run-time performance, portability, debuggability, etc. No C compiler I know optimizes for size by default, in fact, I don't know of any C compiler that, by default, optimizes anything at all. Clang, GCC, MSVC, and all other mainstream compilers require users to enable optimizations (O1, O2, O3, Ofast, etc.) and none of these are code-size optimizations. Only relatively recently have compilers grown the ability to optimize for size, and you have to go way out of your way to do it (enable Oz, disable debug information -g0, enable LTO -flto, ...). Optimizing for size over anything else by default is one of the worst trade-offs a compiler can make. It's a bad trade-offs for most programs, and it is a bad-tradeoff for most compiler users.

Nobody wants to play with their compiler to get a small binary. Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries.

vbezhenar 7y ago

If big binary works faster, I would prefer big binary any day. Nobody cares about disk size.

na85 7y ago
>Nobody cares about disk size. Embedded people care.
- Koshkin 7y ago
  To be fair, “embedded people” do not use disks.
  - pjmlp 7y ago
    They do when they embedded device happens to be a phone, tablet, POS, medical monitoring device, ...
- carlmr 7y ago
  Depends on the system, embedded is a very large section of the market.
shakna 7y ago
And for most compilers, changing whether you care about binary size or performance, is a single switch away, not a series of enhancements you need to refer to a blog page to ensure you're doing it right.
- steveklabnik 7y ago
  Rust does have the same switches C compilers have, that do the same things.

steveklabnik 7y ago

The point is to demonstrate what's inherently overhead and what isn't. Rust has effectively the exact same inherent overhead as C does; that's the point. > Nobody wants to play with their compiler to get a small binary... If rust can produce small binaries, then it must produce small binaries. Everything is a tradeoff. Smaller binaries may or may not perform better than larger ones. This is something you need to play with, just like in C. If one single setting made everything the best in all circumstances, it wouldn't be a setting. C compilers have these settings too. > Languages are typically judged by their defaults. As I mentioned, the defaults have also been adjusted to help out too.

deleted 7y ago

[deleted]

fluffything 7y ago

> Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries. Code size isn't the only axes that can be used to measure the quality of a binary, there are many others: like run-time performance, portability, debuggability, etc. No C compiler I know optimizes for size by default, in fact, I don't know of any C compiler that, by default, optimizes anything at all. Clang, GCC, MSVC, and all other mainstream compilers require users to enable optimizations (O1, O2, O3, Ofast, etc.) and none of these are code-size optimizations. Only relatively recently have compilers grown the ability to optimize for size, and you have to go way out of your way to do it (enable Oz, disable debug information -g0, enable LTO -flto, ...). Optimizing for size over anything else by default is one of the worst trade-offs a compiler can make. It's a bad trade-offs for most programs, and it is a bad-tradeoff for most compiler users.