Ronald de Man is such a hero

[Ras]

so you still don't understand what I wrote? or maybe you're just trolling?

Just re-read what I already wrote, and crucially, think.

surely the core API doesn't change much?

Point in case: compiling a binary on a newer Linux version against libc, and then it doesn't run on an older version. I had then with my Raspi engine binary. That's exactly what people have learnt from.

.NET Core is open source

Maybe you have not been around for long enough to know that it took MS pretty long to open source it. It wasn't intended this way originally.

JIT compiler and GC are essential for managed languages

If you had bothered to read and understand my point with "feature parity", you wouldn't have been astonished.

[mar]

so you still don't understand what I wrote? or maybe you're just trolling?

Just re-read what I already wrote, and crucially, think.

huh, let me repost the part you originally misquoted:

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.

is the context clear now?

surely the core API doesn't change much?

Point in case: compiling a binary on a newer Linux version against libc, and then it doesn't run on an older version. I had then with my Raspi engine binary. That's exactly what people have learnt from.

hmm, I stand corrected then. that's not cool at all. if libc doesn't care about backward compatibility, I should probably switch to static linking on Linux again.

.NET Core is open source

Maybe you have not been around for long enough to know that it took MS pretty long to open source it. It wasn't intended this way originally.

so this is your way of admitting that you were wrong?! you should start a new career as a politician

JIT compiler and GC are essential for managed languages

If you had bothered to read and understand my point with "feature parity", you wouldn't have been astonished.

huh? I was replying to this:

Moving bloat under the rug isn't eliminating it.

which you (again) handily removed from the quote
a typical fallacy.

so let's recap of how you argue:
- selective quoting out of context
- trying to twist what I wrote
- not addressing the actual topic
- one-liner "dismissals"
- parotting void sentences with zero actual content

and I thought you were a reasonable person... until now, that is

[Ras]

is the context clear now?

You asked why that was cheating. The answer is obvious: it's pointless to compare a dynamically linked executable written in C to a statically linked Rust or Go executable. If I link my engine statically under Linux, that adds a whole megabyte to the executable. It's not that C is slim.

hmm, I stand corrected then. that's not cool at all. if libc doesn't care about backward compatibility, I should probably switch to static linking on Linux again.

Backward compatibility works. You can compile on the oldest system that you intend to support, and it will run on newer ones. That's e.g. why the author of Free42 (a very nice HP calculator application) builds on Ubuntu 14 - in 2021. It's the other way around that doesn't work, and that's particularly bad if you have an evolving language like Rust.

so this is your way of admitting that you were wrong?!

That's my way of resting my point with a solid argument.

huh? I was replying to this

The point had been made with the huge Go executables if you care to read the thread, and besides static linkage, they are also huge because we're not talking language supported feature parity with C exetutables. That's not too difficult. And for the context - the thread as a whole is the context. Maybe you could try to see my quotes as specific points within the thread.

[mvanthoor]

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...

Rust keeps it's debug symbols, even in a release compile. (I.e., you can make a release compile that runs at full speed, and still debug it.) You can make it smaller:

Code: Select all

Marcel@WORKSTATION MINGW64 /c/code/rustic
$ ls -lha ./target/release/rustic.exe
-rwxr-xr-x 2 Marcel None 2.4M Mar 27 14:13 ./target/release/rustic.exe

Marcel@WORKSTATION MINGW64 /c/code/rustic
$ strip -s ./target/release/rustic.exe

Marcel@WORKSTATION MINGW64 /c/code/rustic
$ ls -lha ./target/release/rustic.exe
-rwxr-xr-x 1 Marcel None 863K Mar 27 14:13 ./target/release/rustic.exe

In Rust, everything is linked statically. The philosophy is that, if you have an executable, it should run if the OS and CPU support it; no dependencies. (Except of course if you create DLL's and specifically load those.) The above executable contains the engine, but also everything from the standard library and third-party crates that the engine needs.

To compare, you would need to compile an engine like Maksim's BBC statically and see how big it is.

But you're right: no-one cares anymore. As an exercise to get to know some new stuff, I was once asked to create a C# API, which was used by an Electron+Angular front-end. Purpose: phone book / card system. Result: 1.4 GB application. A sub-1MB executable that is able to heat up a 5950X to as hot as it can go is an ultra-tiny and powerful application compared to that.

PS: Of those 863K, about 500K (!) comes from the CLAP command line parsing library. The reason I use this instead of programming something myself is because it takes a huge number of edge-cases into account with regard to how different terminals and different OS-ses behave. It also makes it extremely easy to add very complex command-line parameters (with built-in help) if you so want to. Maybe in the future, I'll replace it with something else; structopt maybe. I started out with CLAP because for command-line programs, it is the de-facto default in Rust-land; at least at this time.

[mar]

You asked why that was cheating. The answer is obvious: it's pointless to compare a dynamically linked executable written in C to a statically linked Rust or Go executable. If I link my engine statically under Linux, that adds a whole megabyte to the executable. It's not that C is slim.

Ok, so the problem originally stems from a misinterpretation then.
The OP (Dann) was praising RdM for small cfish (Windows I assume) binaries. part of this is because it links with (old) dynamic CRT (msvcrt.dll).
Lucas replied and called this cheating (we're still in the C context, speaking of C runtime). I addressed this in my post (to which you replied).
I was talking about libc (=crt on windows) in the context of C (at that point I thought libc was backwards-compatible to some extent).

I never mentioned Rust or Go or managed languages in my original reply, I simply stated that 1M+ hello world programs (in general) aren't cool.

so this is your way of admitting that you were wrong?!

That's my way of resting my point with a solid argument.

You were talking about vendor lock-in. I believe I proved you wrong.

[Wilson]

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

I would add that CFish is not even Ronald's greatest accomplishment.

[mvanthoor]

Backward compatibility works. You can compile on the oldest system that you intend to support, and it will run on newer ones. That's e.g. why the author of Free42 (a very nice HP calculator application) builds on Ubuntu 14 - in 2021. It's the other way around that doesn't work, and that's particularly bad if you have an evolving language like Rust.

Fortunately, Rust itself is compiled to run on anything that is newer than the latest LTS 2.6 kernel. Therefore you can install Rust outside of the package manager; it's just a shell script that downloads stuff, copies it into its own directory (in /home/user by default, but you can move it or install it system-wide), and puts that into the path.

Therefore you can run the newest Rust on very old systems. When running "file" on my own engine, I see a reference to kernel 2.6.

I'm not 100% sure about this, but here goes:

Rust is linked statically by default and has a "executable has no dependencies (except if you link to external DLL / SO's yourself)" philosophy. I would not be surprised if Rust itself is completely independent, and builds against the oldest possible versions of glibc/kernel etc... as it can manage, EVEN if you compile it on the latest Linux (i.e, it includes the old stuff to link against).

I would have to test it and see if a binary I build on Debian 10 will run on 8. At this time, I build my binaries on Debian 8 to be sure. If Rust manages to compile binaries as such that they run on Debian 8, even when running Debian 10, I can ditch the old VM.

[abulmo2]

In Rust, everything is linked statically. The philosophy is that, if you have an executable, it should run if the OS and CPU support it; no dependencies. (Except of course if you create DLL's and specifically load those.) The above executable contains the engine, but also everything from the standard library and third-party crates that the engine needs.

Not everything, just the runtime is statically linked:

Code: Select all

$ ldd rustic.alpha1 
	linux-vdso.so.1 (0x00007ffcb17f3000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f7658a64000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7658a42000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f7658a3b000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7658a20000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7658d35000)

[mvanthoor]

Not everything, just the runtime is statically linked:

Code: Select all

$ ldd rustic.alpha1 
	linux-vdso.so.1 (0x00007ffcb17f3000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f7658a64000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7658a42000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f7658a3b000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7658a20000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7658d35000)

So it could still be that an executable built on one version of Linux doesn't run on the other?! Then why does the Rust documentation make such a big point of the fact that static linking is the default "despite it not being the standard practice"? I'll have to look into this.

[Ras]

The OP (Dann) was praising RdM for small cfish (Windows I assume) binaries. part of this is because it links with (old) dynamic CRT (msvcrt.dll).
Lucas replied and called this cheating (we're still in the C context, speaking of C runtime). I addressed this in my post (to which you replied).
I was talking about libc (=crt on windows) in the context of C (at that point I thought libc was backwards-compatible to some extent).

Yes.

I never mentioned Rust or Go or managed languages in my original reply, I simply stated that 1M+ hello world programs (in general) aren't cool.

And that's where it's comparing apples to oranges because both are using static linkage. I just checked a hello world in C. Dynamic linkage: 16kb. Static linkage, with -O2 and -flto: 850kB. So it seems what you actually don't like (from a size point of view) is static linkage, independent of the language used.

You were talking about vendor lock-in. I believe I proved you wrong.

You didn't, but you need to look at quite a bit of history to see why. It started with Sun's Java. Microsoft came along and tried their usual "embrace, extend, extinguish" strategy. That backfired in court, and that's why MS came up with a Microsoft-Java that they couldn't legally call "Java", so it went by "C#". It was over a whole decade later that MS began to opensource it. That was because by that time, MS had understood that the desktop wasn't the relevant battlefield anymore. That doesn't change the fact that originally, it had been intended as vendor lock-in: a Java that would only run on Windows.