3 ms·

I don't have a horse in this race, but a programming language that prides itself on "zero-cost abstractions" and then generates a Hello World program that is 90

by gred 3y ago

I don't have a horse in this race, but a programming language that prides itself on "zero-cost abstractions" and then generates a Hello World program that is 90% wasted space doesn't leave a great impression.

lifthrasiir 3y ago
Most debugging informations are "useless" until they are desparately needed, and this "wasted space" was no exception. So as always, it's another trade-off: will you "waste" some bytes to ease yourself in the future? Cargo already has decided that uninformed people don't want them for the release mode, but it was found that this decision was not uniformly enforced and some debuginfo was still left there. So a new option was added and the default was changed. Happy ending!
- gred 3y ago
  True, but it sounds (nearly?) "useless" based on the description provided by the author: > For example, one thing that was noted is that if we strip the debug symbols by default, then backtraces of release builds will... not contain any debug info, such as line numbers. That is indeed true, but my claim is that these have not been useful anyway. If you have a binary that only has debug symbols for the standard library, but not for your own code, then even though the backtrace will contain some line numbers from stdlib, it will not really give you any useful context [...]
  - MrJohz 3y ago
    That's true, which is why it's now being stripped.
oblio 3y ago
> "zero-cost abstractions" Zero cost in terms of CPU and RAM usage during execution time.
- 0x000xca0xfe 3y ago
  Program size affects disk/file system load time, relocation time, cache utilization, zram speed, and probably many things more. Nothing is zero-cost if you look closely enough.
- pdimitar 3y ago
  I don't disagree with your premise but bigger binaries lead to significantly more CPU cache churn. (EDIT: or not, see elsewhere in this thread for clarifications)
pdimitar 3y ago
I don't judge by this but I have met programmers who do (as mentioned upthread) so yeah, I agree. It's a signal that is useful to many, and that signal should start being optimized sooner rather than later.
elteto 3y ago
I don’t see how zero cost abstraction has anything to do with binary size. It’s about runtime efficiency of language features. Optimizing binary size is a worthy and important goal because some people have uses cases where it matters. If you are not one of those people why fret about it?
- JohnFen 3y ago
  > I don’t see how zero cost abstraction has anything to do with binary size. But binary size is absolutely a cost. Whether or not it's a cost that matters to you is a different question, but it's still a cost.

by gred 3y ago

lifthrasiir 3y ago

Most debugging informations are "useless" until they are desparately needed, and this "wasted space" was no exception. So as always, it's another trade-off: will you "waste" some bytes to ease yourself in the future? Cargo already has decided that uninformed people don't want them for the release mode, but it was found that this decision was not uniformly enforced and some debuginfo was still left there. So a new option was added and the default was changed. Happy ending!

gred 3y ago
True, but it sounds (nearly?) "useless" based on the description provided by the author: > For example, one thing that was noted is that if we strip the debug symbols by default, then backtraces of release builds will... not contain any debug info, such as line numbers. That is indeed true, but my claim is that these have not been useful anyway. If you have a binary that only has debug symbols for the standard library, but not for your own code, then even though the backtrace will contain some line numbers from stdlib, it will not really give you any useful context [...]
- MrJohz 3y ago
  That's true, which is why it's now being stripped.

oblio 3y ago

> "zero-cost abstractions" Zero cost in terms of CPU and RAM usage during execution time.

0x000xca0xfe 3y ago
Program size affects disk/file system load time, relocation time, cache utilization, zram speed, and probably many things more. Nothing is zero-cost if you look closely enough.
pdimitar 3y ago
I don't disagree with your premise but bigger binaries lead to significantly more CPU cache churn. (EDIT: or not, see elsewhere in this thread for clarifications)

pdimitar 3y ago

I don't judge by this but I have met programmers who do (as mentioned upthread) so yeah, I agree. It's a signal that is useful to many, and that signal should start being optimized sooner rather than later.

elteto 3y ago

I don’t see how zero cost abstraction has anything to do with binary size. It’s about runtime efficiency of language features. Optimizing binary size is a worthy and important goal because some people have uses cases where it matters. If you are not one of those people why fret about it?

JohnFen 3y ago
> I don’t see how zero cost abstraction has anything to do with binary size. But binary size is absolutely a cost. Whether or not it's a cost that matters to you is a different question, but it's still a cost.