Hello World (drewdevault.com)

I agree that software bloat is a big problem, but trivializing that problem to printing a "hello world" to the screen, punishing all languages with runtimes by measuring the syscalls involved in their startup routines, disregarding the fact that many users are going to have a single system-wide runtime for e.g. C or Python or Julia and therefore the total-kB number does not scale linearly with the number of programs written in C or Python or Julia, ignoring the massively increased software development and debugging time for writing in low-level and memory-unsafe languages like assembly, static Zig, or C, and directly implying[0] that most problems with software complexity can be solved by writing in assembly, static Zig, or C rather than in Julia/Ruby/Java/all other languages from the bottom 90% of the list (and that's the vibe that this post gives me) is, for me, more about making a venting shitpost than creating something that provides even a part of an actual solution to software bloat in general.

The "more time your users are sitting there waiting for your program" statement is especially amusing to me. Your users are not going to wait shorter for your program because you and your team are taking another year to write, test, and debug it in assembly.

[0] "These numbers are real. This is more complexity that someone has to debug, more time your users are sitting there waiting for your program, less disk space available for files which actually matter to the user."

I feel it needs some kind of normalizing. I get that it is illustrating bloat but it doesn’t really illustrate where that’s coming from.

Maybe only the output of the JITs should counts, or the syscalls required to assemble the example should be included. Are musl and glibc really wasting cycles or are they doing something that the example is missing.

Fun to think about.

Edit: I'm just curious and don't know how to even start testinng this, not trying to promote/demote Node.js in any way.

I'm told that the story behind it, is that he was arguing with someone about the efficiency of an operation, and actually wrote that site to prove his point.

Nim:

  $ cat hello.nim
  stdout.write("hello, world!\n")

  $ nim --gcc.exe:musl-gcc --gcc.linkerexe:musl-gcc --passL:-static c -d:release hello.nim
  $ ldd ./hello
  not a dynamic executable

  Execution Time: 0m0.002s (real)
  Total Syscalls: 16
  Unique Syscalls: 8
  Size (KiB): 95K (78K stripped)

  $ nim c -d:release hello.nim
  $ ldd ./hello
  linux-vdso.so.1 =>  (0x00007ffc994b6000)
  libdl.so.2 => /lib64/libdl.so.2 (0x00007f7c88785000)
  libc.so.6 => /lib64/libc.so.6 (0x00007f7c883b8000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f7c88989000)

  Execution Time: 0m0.002s (real)
  Total Syscalls: 42
  Unique Syscalls: 13
  Size (KiB): 91K (79K stripped)

That gave me a good chuckle towards the end.

It'd be useful to break this out a little further as it'd have been interesting to see how small just the output is on the dynamically linked versions instead of just comparing static to whole dynamic bundle.

It's also a bit odd that e.g. zig gets optimized for size and stripped via the compiler, c gets optimized for speed and stripped via strip, and Go/Crystal just gets built standard with no stripping at all. I don't think it'd change the big picture just a bit odd.

.

Unrelated tangent/ramble, I played with Zig and Go as part of my yearly "take December off and tinker" break. Zig was really fun to work with but unfortunately still in a huge churn and development. Go was a lot better than I expected it to be (I had put off messing with Go for a few years now) and the size of the stdlib is just astounding. In the end it wasn't as "fun" as zig but it had very low friction and I definitely see myself using it for a few personal projects over the next year... and then seeing if Zig has less churn in December ;).

What is the point of this post? Yes, I fully expect a simple Hello World in assembly would be straightforward and fast. I still want the advantage of things like automated memory management, an interpreter or JIT compiler where warranted, a standard runtime environment, etc. For anything even remotely complicated.

I get it, over the past 30-40 years we've built layers upon layers of abstraction, so it's worth it to take a look back and ask "Are there some cases where we overdid it?" Still, let's not throw the baby out with the bathwater, or forget why we added those layers in the first place.

  $ cat a.c
  #define _GNU_SOURCE
  #include <unistd.h>
  #include <sys/syscall.h>

  void _start(void) {
    syscall(__NR_write, 1, "Hello world!\n", 13);
    syscall(__NR_exit_group, 1);
  }

  $ gcc -nostartfiles a.c -o a -static
  $ ls -l a
  -rwxr-xr-x 1 user user 9584 jan  5 00:07 a
  $ strip -s a; ls -l a
  -rwxr-xr-x 1 user user 9000 jan  5 00:10 a
  $ strace ./a
  execve("./a", ["./a"], 0x7ffd4d4f8250 /* 67 vars */) = 0
  write(1, "Hello world!\n", 13)          = 13
  exit_group(1)                           = ?
  +++ exited with 1 +++

  go build -ldflags '-s -w' -o test test.go

I chuckled.

38 bytes source code, 970 KB binary (782 KB stripped) 0m0.003s execution time, 139 syscalls (26 unique).

Seeing the list of syscalls is the most interesting part of this whole exercise; the number of milliseconds it takes to print "hello world" is not super relevant (except in the few cases where start-up time is painfully long).

  #![feature(start, lang_items)]
  #![no_std]
  #![no_main]

  #[link(name = "c")]
  extern "C" {
      pub fn puts(s: *const u8);
  }
  
  #[no_mangle]
  pub extern "C" fn main(_argc: i32, _argv: *const *const u8) -> i32 {
      unsafe {
          puts(b"hello world\n" as *const u8);
      };
      0
  }
  
  #[panic_handler]
  fn panic(_info: &core::panic::PanicInfo) -> ! {
      loop {}
  }
  
  #[lang = "eh_personality"]
  extern "C" fn eh_personality() {}