Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Rust binaries smaller by default

kobzol.github.io

Post reply on HN
Print view View original

91–100 of 199 posts

Re: Making Rust binaries smaller by default

#91

Post by lieks »

skor wrote: post #81

> I can imagine a situation where a seasoned C or C++ programmer ... make fun of it on the forums Is this really a thing? Do C folks make fun of Rust?

Yes, we do, in some contexts.

Because despite its complexity, slow compile times, lack of a specification or more than one viable implementation and bloated binary size, people still tout it as a C replacement.

For application programming, Rust is fine, but for embedded and systems programming, nearly any of those on its own can be enough to eliminate Rust as an option, depending on the situation.

Except for complexity, they are all solvable and being worked on, for this very reason. But Rust can never replace C completely, because it's not simple, and there is a sizeable portion of primarily C programmers who are minimalists.

Re: Making Rust binaries smaller by default

#92

Post by lifthrasiir »

milianw wrote: post #39

I applaud this initiative. yet I wonder - the ideal situation would be to not throw away the debug info (ever), but rather it should be put into an external file. even Linux supports this for many years and nowadays we even have direct support with dwarf5/dwo. is trust taken any action towards that direction? after all: without debug info (which you do not want to ship to customers necessarily), you cannot do profili…

Cargo does support `split-debuginfo` [1] but it still has some rough edges in my experience. I do think that is the ultimate way to go in the future.

[1] https://doc.rust-lang.org/cargo/reference/profiles.html#spli...

Re: Making Rust binaries smaller by default

#93

Post by lionkor »

nindalf wrote: post #45
lionkor wrote: post #4

Initial binary size, like of a hello world, is a great indicator of how much abstraction the language has that youre also paying for. For example, java has to set up a constants pool, parse it from the classfile, run init and cinit, resolve references, allocatea a frame, and so on, just to get to the entrypoint. Compared to C without stdlib which needs to basically just run a few bytes to syscall write(). There are o…

It’s funny, because your claim that it’s a great indicator is contradicted by the article we’re discussing. Rust was widely considered to be “only pay for what you use” despite having 4MB hello world programs. And now that it’s 400KB that continues to be true. So in this case, 4MB wasn’t a good indicator was it?

Its still a great indicator, its just that indicators dont mean very much sometimes.

Re: Making Rust binaries smaller by default

#94

Post by dhruvrajvanshi »

tialaramex wrote: post #56
zozbot234 wrote: post #26

Earlier quoted context omitted.

You can use the C ABI if you want something stable, and there are custom crates that will help with translating from the Rust to the C ABI. (This also helps because the resulting shared objects can potentially be FFI'd with from any language, not just Rust. They might as well be plain C libraries as far as anyone is concerned, only with the usual Rust safety requirements.)

Also, even in "the" C ABI provided by Rust out of the box there's a certain amount of "Well, this is probably what your C compiler does here, but there's no requirement" rather than an actual hard ABI document. A lot of the "We're ABI stable" claims in C and C++ are "We daren't change anything or stuff breaks" which isn't so much an ABI as it is paralysis and Rust is confident it doesn't want to do that .

> "We're ABI stable" claims in C and C++ are "We daren't change anything or stuff breaks" which isn't so much an ABI as it is paralysis and Rust is confident it doesn't want to do that.

For C++, yes sure, but I thought C usually has a pretty well specified ABI on most platforms, no?

Re: Making Rust binaries smaller by default

#95

Post by hoseja »

lieks wrote: post #91
skor wrote: post #81

> I can imagine a situation where a seasoned C or C++ programmer ... make fun of it on the forums Is this really a thing? Do C folks make fun of Rust?

Yes, we do, in some contexts. Because despite its complexity, slow compile times, lack of a specification or more than one viable implementation and bloated binary size, people still tout it as a C replacement. For application programming, Rust is fine, but for embedded and systems programming, nearly any of those on its own can be enough to eliminate Rust as an option, depending on the situation. Except for complexi…

You forgot the funniest part, the programming socks.

Re: Making Rust binaries smaller by default

#96

Post by whstl »

Voultapher wrote: post #88
irdc wrote: post #85

Earlier quoted context omitted.

What is this “C programmer” you speak of? Anyone who’s been doing this for long enough is a polyglot.

That mirrors my experience. I've hardly ever met really experienced people that are hardstuck on language flaming. Programming languages are tools, with general and situational up and downsides.

Same.

Reddit gave me some interesting insights into people like this. Whenever I come across a very radical opinion, I check their whole profile. It is often someone without much if any experience, and clearly doing it just for the sake of tribalism.

Re: Making Rust binaries smaller by default

#97

Post by dhruvrajvanshi »

flohofwoe wrote: post #60
alpaca128 wrote: post #49

Earlier quoted context omitted.

> nobody took the time to actually do it Because in the end almost nobody actually cares about it enough to create a fix. Small binaries are great, but people care mainly about how fast it compiles and how fast it runs, and in the few cases where the binary size is important it was already possible to shrink it significantly (more than with this new change). In my entire life I have never heard a user complain about…

What bothers me more than the actual binary size (yes ok, the remaining 400 KBytes may actually be justified as pointed out by @lifthrasiir) is that the additional 3.5 MBytes baggage of stdlib debug info was just dead weight. They could just as well have included 3.5 MBytes of noise in each executable.

As pointed out by the author, people who care could already strip the debug info.

C was created in a time when binary sizes used to be important for every program. These days, it only matters for a small subset of use cases.

If anything, the fact that no one fixed it for this long is an indicator that it doesn't matter much for the kinds of things people typically build with rust.

It's nice that there's a fix now, but would I care if Firefox or Chrome binary was 4MB bigger?

Re: Making Rust binaries smaller by default

#98

Post by bombela »

lieks wrote: post #91
skor wrote: post #81

> I can imagine a situation where a seasoned C or C++ programmer ... make fun of it on the forums Is this really a thing? Do C folks make fun of Rust?

Yes, we do, in some contexts. Because despite its complexity, slow compile times, lack of a specification or more than one viable implementation and bloated binary size, people still tout it as a C replacement. For application programming, Rust is fine, but for embedded and systems programming, nearly any of those on its own can be enough to eliminate Rust as an option, depending on the situation. Except for complexi…

For what it's worth, I was able to write Rust for the 8bit AVR microcontroller platform. 256 bytes of RAM and 1024 CPU instructions FLASH.

In this comment I describe what I did to remove the bloat: https://news.ycombinator.com/item?id=36394426

It's not the default and it took me some searching and reading to get there. I wonder if Cargo could have some vastly different default per target. As everybody said in this thread, defaults matters.

Re: Making Rust binaries smaller by default

#99

Post by [deleted] »

dhruvrajvanshi wrote: post #94
tialaramex wrote: post #56

Earlier quoted context omitted.

Also, even in "the" C ABI provided by Rust out of the box there's a certain amount of "Well, this is probably what your C compiler does here, but there's no requirement" rather than an actual hard ABI document. A lot of the "We're ABI stable" claims in C and C++ are "We daren't change anything or stuff breaks" which isn't so much an ABI as it is paralysis and Rust is confident it doesn't want to do that .

> "We're ABI stable" claims in C and C++ are "We daren't change anything or stuff breaks" which isn't so much an ABI as it is paralysis and Rust is confident it doesn't want to do that. For C++, yes sure, but I thought C usually has a pretty well specified ABI on most platforms, no?

[deleted]

Re: Making Rust binaries smaller by default

#100

Post by pdimitar »

It's really a shame that Rust includes the stdlib piecemeal in binary form, debug symbols and all, in every final binary.

I do love Rust but binary sizes have always annoyed me greatly and I always had this nagging feeling that part of all programmers don't take Rust seriously because of it. And I actually have witnessed, several times in the last 2-ish years, older-school programmers berating and ignoring Rust on that basis alone (so the author is quite right to call this out as a factor).

Looking at the https://github.com/johnthagen/min-sized-rust repo, final binary size of 51 KB when compilation / linking / stripping takes stdlib into account (and not just blindly copy-pasting the 4MB binary blob) is acceptable and much more reasonable. I wouldn't care for further micro-optimizations e.g. going to 20KB or even 5KB (further down the README file).

I also don't use nightly in my Rust work so I guess I'll have to wait several more years. :(

Post reply on HN