[kwlug-disc] Zig's guy interview

[D. Hugh Redelmeier]

> From: William Park via kwlug-disc <kwlug-disc at kwlug.org>

>    $ zig build-exe hello.zig
>    $ ./hello
>    Hello, World!
>    $ du -h hello
>    8.3M    hello
> 
> Good thing, storage is cheap!

I assume that the problem is that, by default, Zig binaries are statically 
linked.  That means that every program carries its own copy of each 
library that it uses.

As I understand it, static linking is the default for Rust and Go too.

This strikes me as a terrible idea.

- so many copies of the same code stored on disk and loaded into RAM.

- so many programs needing to be rebuilt whenever a bug is fixed in a 
  library.  How do you even find which programs?  Whose job is it to find 
  them?

Shared libraries have been working well on UNIX since the 1980s.  Linux 
copied UNIX fairly early on.

Of course you can do shared libraries poorly: the DLL Hell of Windows.  As 
far as I could tell, this was due to bad discipline, either by the program 
vendor or Microsoft.

I admit that not all libraries should be shared:

- if library specifications are mutating rapidly, the advantages of 
  sharing disappear and the disadvantages multiply.  This is most likely 
  in young libraries: perhaps libraries should graduate to shared when 
  they are thought to be stable.

  This idea should affect library design.  For example, printf format 
  strings are usually interpreted an run-time so the compiler doesn't 
  know which kinds of formatting are not used.  (This example is a bit 
  naive: I've used ancient C compilers that inferred that if floating 
  point isn't used, floating point formatting doesn't need to be 
  supported.  Decades ago, I wrote a C compiler that did peer into printf 
  format strings (usually possible)).

- if you have good whole-program optimization, it can get more traction 
  when it sees the libraries.  It should also be able to eliminate much 
  of a library as dead code.  Clearly that did not happen in this Zig 
  example.

- at the lowest level, shared libraries involve roughly another level of 
  indirection on each call, so there is a slight additional cost to each 
  call.  For security reasons, Address Space Randomization has been widely 
  adopted and that can also increase the overhead.

- if a library isn't getting monotonically better, your dynamically linked 
  program may grow new bugs.  The more programs share that library, the 
  sooner such bugs are found and fixed.

- Certain kinds of bugs in your program may manifest themselves when a 
  library improves (bugs are fixed or features are added).  Personally, I 
  like my bugs to manifest so that I can fix them.