Rust's enums can carry data. You can write the same thing in C, but because it does not have the enum feature, you have to do it yourself. They're sometimes called "tagged unions" for a reason, you use a union + a tag when doing it by hand:
I haven't actually compiled this, but it should compile to almost the exact same, if not literally the exact same, machine code. Yet one is way more verbose than the other.
I'm not sure individual examples is the right way to go about this. A correlation isn't a guarantee for every instance and it's easy to concoct individual examples which tell any story you'd like them to.
To properly answer this you'd need to compare a large number of identical implementations written idiomatically in several languages and see if there is a correlation.
If I were to throw my 2 cents in I'd say "a very weak correlation" is probably right. Not because verbose languages HAVE to result in more bloated code but because it seems to me languages fine having a lot of bloat in the syntax also tend to be languages fine having a lot of bloat in the implementation or attracted to abstraction (which never does seem to actually compile away fully in large projects, even though it often largely does).
Sure, I did not think that one example is a full survey of all possibilities. I think that it's quite intuitive that this feels right:
> it seems to me languages fine having a lot of bloat in the syntax also tend to be languages fine having a lot of bloat in the implementation or attracted to abstraction
Which is why I chose an example of the exact opposite: a language not known for bloat, taking way more code to produce the exact same thing as one that's more succinct.
It's not as good as some sort of scientific survey of a wide variety of options, but if you can find examples in all directions, assuming there's no correlation until proven otherwise is a pretty solid bet, I think.
I read my parent ask asking a question: is there a correlation, or not?
I am saying that I do not believe there is a correlation between source code length and binary length. If that's what benced meant by their question, then yes, I agree :)
Fair point, I phrased that too broadly, and you are right about the loose correlation.
What I was gesturing at, badly, was more that Zig’s low-abstraction / explicit-by-default syntax tends to have you write more boilerplate-y code in general that are more annoying to write and maintain, while not buying you enough over a language with better tooling and ecosystem and compiler optimization like Rust.
I don't think you can draw the conclusion that source length and binary size are correlated. For example, in Rust:
Rust's enums can carry data. You can write the same thing in C, but because it does not have the enum feature, you have to do it yourself. They're sometimes called "tagged unions" for a reason, you use a union + a tag when doing it by hand:
I haven't actually compiled this, but it should compile to almost the exact same, if not literally the exact same, machine code. Yet one is way more verbose than the other.
I'm not sure individual examples is the right way to go about this. A correlation isn't a guarantee for every instance and it's easy to concoct individual examples which tell any story you'd like them to.
To properly answer this you'd need to compare a large number of identical implementations written idiomatically in several languages and see if there is a correlation.
If I were to throw my 2 cents in I'd say "a very weak correlation" is probably right. Not because verbose languages HAVE to result in more bloated code but because it seems to me languages fine having a lot of bloat in the syntax also tend to be languages fine having a lot of bloat in the implementation or attracted to abstraction (which never does seem to actually compile away fully in large projects, even though it often largely does).
Sure, I did not think that one example is a full survey of all possibilities. I think that it's quite intuitive that this feels right:
> it seems to me languages fine having a lot of bloat in the syntax also tend to be languages fine having a lot of bloat in the implementation or attracted to abstraction
Which is why I chose an example of the exact opposite: a language not known for bloat, taking way more code to produce the exact same thing as one that's more succinct.
It's not as good as some sort of scientific survey of a wide variety of options, but if you can find examples in all directions, assuming there's no correlation until proven otherwise is a pretty solid bet, I think.
2 replies →
I think you are saying the same thing as benced - just because Zig source code is verbose is no reason to assume the binary should be larger.
I read my parent ask asking a question: is there a correlation, or not?
I am saying that I do not believe there is a correlation between source code length and binary length. If that's what benced meant by their question, then yes, I agree :)
1 reply →
It required a little bit of messing with optimisation settings and library generation in Rust, but they emit very very similar x86-64 assembly:
https://godbolt.org/z/89W4srz4d
Nice, thank you for picking up after my laziness. Surely only a few bytes different in the binary, and much, much smaller of a delta than the source.
3 replies →
Fair point, I phrased that too broadly, and you are right about the loose correlation.
What I was gesturing at, badly, was more that Zig’s low-abstraction / explicit-by-default syntax tends to have you write more boilerplate-y code in general that are more annoying to write and maintain, while not buying you enough over a language with better tooling and ecosystem and compiler optimization like Rust.
Why? Python is terse but has large binaries because of the runtime overhead. C++ is fairly verbose but can make useful binaries in double digit kib.