Ronald de Man is such a hero

[Dann Corbit]

I just built CFish and the binaries are deliciously tiny (I have a script that builds three different versions):

Code: Select all

03/26/2021  10:58 PM           230,400 cfish-modern-gcc.exe
03/26/2021  10:58 PM           230,912 cfish-avx2-gcc.exe
03/26/2021  10:49 PM           232,960 cfish-vanilla-gcc.exe
03/26/2021  10:46 PM        21,022,697 nn-62ef826d1a6d.nnue

If Ronald de Man did not exist, we would be forced to invent him.

[abulmo2]

I just built CFish and the binaries are deliciously tiny (I have a script that builds three different versions):

This is the strength of the C language that comes with no bloated runtime, not Ronald I am afraid. Ronald de Man still deserves our congratulations for the quality of the code he writes.

[lucasart]

I just built CFish and the binaries are deliciously tiny (I have a script that builds three different versions):

This is the strength of the C language that comes with no bloated runtime, not Ronald I am afraid. Ronald de Man still deserves our congratulations for the quality of the code he writes.

To be fair, looking at the size of dynamically linked executable is cheating. Once you link it statically (against GNU libc and libm), the true extent of the GNU plague is revealed

Fortunately, there is musl, for those who care about bloat. A statically compiled c-chess-cli is just under 100KB on Linux with musl (gcc -Os).

Sadly, it seems that no one cares anymore, with hello world programs compiling to several megabytes in new programming languages like Go, and even Rust...

[mar]

To be fair, looking at the size of dynamically linked executable is cheating. Once you link it statically (against GNU libc and libm), the true extent of the GNU plague is revealed

Fortunately, there is musl, for those who care about bloat. A statically compiled c-chess-cli is just under 100KB on Linux with musl (gcc -Os).

Sadly, it seems that no one cares about bloat anymore, with hello world programs compiling to several megabytes in new programming languages like Go, and even Rust...

I mean, why would that be cheating? that's what dynamic libraries are for.
as a bonus the library code is actually shared in (physical) memory across processes plus you don't statically link bugs/security holes of version x.y of libc.

several mb hello world is a fail though

[Ras]

I mean, why would that be cheating?

Because it's comparing apples to oranges when one language can rely on its runtime already being on the system while another can't. With Go, we're not even talking feature parity because it's a managed language while C and Rust aren't.

[mar]

I mean, why would that be cheating?

Because it's comparing apples to oranges when one language can rely on its runtime already being on the system while another can't. With Go, we're not even talking feature parity because it's a managed language while C and Rust aren't.

read again or don't quote out of context. that remark was related to statically vs dynamically linking libc

as for other languages: who's preventing you from installing the runtime?
as for managed, with C# the "binary" is actually CIL, which is typically much smaller than equivalent compiled code, (on Windows .NET runtme is part of the OS)
either way the VM can be shared too, of course.

[Ras]

that remark was related to statically vs dynamically linking libc

Try to understand the context in this discussion.

as for other languages: who's preventing you from installing the runtime?

Dependency management, version hell, breaking changes, in particular when distributing binaries. It's a safe bet that the designers of Go and Rust had thought about different ways to deal with the runtime and didn't make their decision out of dumbness.

(on Windows .NET runtme is part of the OS)

Which is limited to OS vendor supplied languages, and their strategic objective is always vendor lock-in.

either way the VM can be shared too, of course.

Moving bloat under the rug isn't eliminating it.

[mar]

that remark was related to statically vs dynamically linking libc

Try to understand the context in this discussion.

is that supposed to be an argument? let me repeat for the third time: do you understand what my remark was related to?
or perhaps you fail to comprehend simple sentences?

[Ras]

is that supposed to be an argument?

No, a failed attempt to get you to comprehensive reading. Doesn't work though.

[mar]

so you still don't understand what I wrote? or maybe you're just trolling?
let me address the rest of your non-points and then I'm bailing out, because arguing with you is apparently a waste of time

as for other languages: who's preventing you from installing the runtime?

Dependency management, version hell, breaking changes, in particular when distributing binaries. It's a safe bet that the designers of Go and Rust had thought about different ways to deal with the runtime and didn't make their decision out of dumbness.

surely the core API doesn't change much? the JIT compiler can get better, bugs get fixed. so embedding outdated VM/runtime doesn't seem helpful at all, even if it may "just work".

(on Windows .NET runtme is part of the OS)

Which is limited to OS vendor supplied languages, and their strategic objective is always vendor lock-in.

.NET Core is open source, plus there is Mono, so your vendor lock-in is a fantasy in this case, nothing more

either way the VM can be shared too, of course.

Moving bloat under the rug isn't eliminating it.

A hilarious one-liner, kudos to you! again completely missing the point
JIT compiler and GC are essential for managed languages, your definition of "bloat" seems very odd in this case.