This was not an objective test, this is just an approximation that I hope will encourage readers to be more aware of the consequences of their abstractions, and their exponential growth as more layers are added

Eh, [citation needed] on the exponential growth bit. Lots of what’s being measured here is fixed start-up costs that are negligible in a Real Program. If you want to claim these costs accumulate exponentially (or even linearly), how about a plot of syscalls as you increase the number or statements printed?

The “Hello World” article is simplistic to the point of silliness. It’s essentially just chucking stuff like garbage collection in the “other crap” that makes stuff “hard to debug”-bin.

I’m fairly sure the author understands these kinds of trade-offs because he frequently uses languages like Python and Go, which do “other crap”.

Of course, writing an article that deals with these kind of nuances is hard and time-consuming, whereas writing an article with simplistic benchmarks and silly generalisations is easy. 🤷‍♂️

I find it mildly interesting that the author includes Perl, which does moderately well on this “benchmark”, finds the time to include a “nudge nudge isn’t it funny” cheap shot:

Passing /dev/urandom into perl is equally likely to print “hello world”

but can’t be bothered to note the version of Perl used.

Interestingly, I have a pattern of LEDs reading “Hello, world!” that require none of the bloat of microcontrollers, modern integrated circuits, a full general purpose computer, or anything of the sort.

Latency to “Hello, world!” is microseconds when you throw the switch, rather than the eons it takes for this guy’s machine to boot, compile, and execute. A warning for those of you who rely on abstractions like software.

Any true optimizer would generate this machine and not that machine.

Here are the results for OCaml, which I think are pretty interesting!

$ cat hello.ml
let () = print_endline "hello world"

With a dynamically linked glibc:

$ ocamlopt -o hello hello.ml

• Resulting binary size (after strip): 279K
• Syscalls: 69, Unique syscalls: 17

With a dynamically linked musl:

$ ocamlopt -cc musl-gcc -o hello hello.ml

• Resulting binary size (after strip): 219K
• Syscalls: 24, Unique syscalls: 13

With a statically linked musl:

$ ocamlopt -cc musl-gcc -ccopt -static -o hello hello.ml

• Resulting binary size (after strip): 262K
• Syscalls: 23, Unique syscalls: 12

These results are pretty close to the numbers for C (!), so I guess that would put OCaml somewhere between C and Rust in the blogpost table…

Beat me to the punch in a way far better than I could.

I do disagree with this point (in the sense that it may be worded a bit strictly for the general case):

Computers are fast - a lot faster than we can possibly perceive. By some estimates human beings perceive two events as instantaneous at around 100ms. To Drew’s point, this is an eternity for a computer. In that time a modern CPU could execute 10 billion instructions.

One of the points I wanted to drive home was we really should care about these death-by-a-thousand-cuts sometimes incurred via these abstractions (imo necessary for security and productivity), when they often are the same cut repeated a few hundred times. Users are penalised for this when applied repeatedly (imagine a 100ms delay after pressing a button throughout the lifetime of a program). Of course if you read further along, for program start-up, this delay sure is often worth it.

–

In a sense we should be focusing a lot more on program optimisation for the sake of preserving energy. We should be designing our languages so that they’re conducive to optimisation (looking at you C, for the pointer alias semantics which arguably killed Itanium).

Ironically, one of the benchmarks that I found was that printing Hello World a thousand times uses half the syscalls in Electron (a pretty large hammer for the nail that is ensuring multiplatform UI consistency) as compared to C. :)

Nice comparison, here’s a one liner to do it for several shells

$ for sh in dash bash zsh mksh; do echo $sh; strace -c -- $sh -c 'echo hi' 2>&1 | tail -n 1  ; done
dash
100.00    0.000000                    40         3 total
bash
100.00    0.000000                   131        12 total
zsh
100.00    0.000000                   915        18 total
mksh
100.00    0.000000                    61         3 total

The third column is the number of sys calls (the fourth is the number of errors).

So zsh is in the range of Python (slow), bash is in the range of Rust; dash is is in the range of C.

(Oil doesn’t fare well because of embedding the Python the interpreter; that’s one reason among many I’m working on translating it to native code )

I appreciate your work and the data you collected. But I have to complain about the style.

Most languages do a whole lot of other crap other than printing out “hello world”, even if that’s all you asked for. a decent metric for how much shit is happening that you didn’t ask for

Please do not talk about the „additional“ (beyond that two) instructions as „crap“ or „shit“. Authors of the compilers and runtimes have not added them just for fun or to slow down your software. Their work makes sense and was requested by someone and there are reasons for such „additional“ instructions. Nobody (in real world) optimizes for „Hello world“ programs.

If you think that you can make something faster or less memory or disk demanding, feel free to contribute to given project.

P.S. I would also recommend milliseconds as a unit for such measurements.

When an issue is a complex multi-dimensional trade-off, presenting a dry benchmark on one dimension is underhanded.

Number of syscalls or constant overhead in an executable may be a sign of bloat, but it also may be:

• the best choice for literally every program bigger than hello world (e.g. initializing a heap)
• sensible choice for predictable performance (the startup prepares environment ahead of time, so that it doesn’t have to do it lazily later)
• necessity for good security (e.g. setting up guard pages)
• necessity for compatibility or to be a good citizen on a platform (e.g. dynamically linking with OS libraries)
• price paid for richer standard library that improves productivity.

Out of interest, how does Rust with MUSL does? rustc --target x86_64-unknown-linux-musl -C opt-level=s, this will result with statically linked libc. Additionally it would be interesting to see it with -C lto enabled.

EDIT:

On macOS I have went down quite significantly:

[nix-shell:~]$ rustc -C opt-level=s test.rs 

[nix-shell:~]$ ls -la test
-rwxr-xr-x 1 hauleth staff 233968 Jan  4 19:33 test

[nix-shell:~]$ rustc -C lto -C opt-level=3 -C panic=abort test.rs 

[nix-shell:~]$ ls -la test
-rwxr-xr-x 1 hauleth staff 189164 Jan  4 19:33 test

[nix-shell:~]$ strip test; ls -la test
-rwxr-xr-x 1 hauleth staff 160508 Jan  4 19:34 test

About 20% size reduction after LTO, opt-level 3, and aborting on panic. 40% when we also strip. Both have used 30 sys calls on macOS though.

He mostly missed the point of why people hated his article, but this line kind of bugged me.

So far as most end-users are concerned, computers haven’t improved in meaningful ways in the past 10 years, and in many respects have become worse.

The huge leaps in graphics, web accessiblity and design (in a way thank f for Web 3.0; no more Flash player or ActiveX or Silverlight!), processing speeds… hell, using GNU/Linux a decade ago could be a massive pain in the ass and today it’s simple as. Don’t get me started on the smartphone and the nearly unimaginable changes to the world they’ve introduced past decade. So much work done by so many brilliant people completely dismissed with some arbitrary complexity boogeyman.

Nice, number of syscalls is a pretty interesting indirect metric for how much STUFF is going on behind the scenes, even for a short-lived program. I don’t see this as a performance metric, just complexity. I want to play with the the Rust example sometime, and I want to see how Nim stacks up so I should try that too; anyone have any other suggestions for languages to try? Non-JIT implementations by preference, to keep apples to apples.

Is it only me who’s impressed that Zig has fewer syscalls than C?

To me, the article basically boils down to an argument that “everything is a compromise, and I agree with Go’s current position of compromise and don’t see a need for Go to improve”. Whereas Drew’s one kinda boils down to “I know everything’s a compromise, but geez, [language authors] guys, you’re getting freaking lousy in your compromising; enough of your wink wink nudge nudge, I’m checking your cards and you’re sooooooo bluffing; maybe, you know, it’s time to get your act together, for the sake of all things saint?”.

To add to this, in the particular case of Go, as much as I like it, and appreciate it, and still use it as a favourite weapon of choice in many, many cases, I do feel a best friend’s good-willing sadness in how the runtime & compilers are drifting away from some of the original ideals. Most ironically, as far as commenting on the article above, it mentions dynamic linking as a space saving measure, whereas in the early days of Go, it was exactly the opposite which was being claimed; I understand Drew’s complaint about the magic incantation for static linking in Go as aiming exactly at this kind of dynamic.

Using cargo, Rust package manager, instead of directly calling compiler, produces more optimized binary even without any special switches or flags. Rust docs suggest users to use cargo instead of directly calling the compiler; this is the standard way to compile rust programs.

cargo build --release

This produces total of 95 syscalls, 20 of them or unique.

While not significantly better, it’s something.

Used cargo 1.40.0.

An interesting metric if you want to make a short-living utility with low latency to output.

Pretty useless if you are interested in throughput or latency of a long living process.

But regardless of what our computer is doing, if it takes less than 100ms to execute our program, we simply won’t be able to tell the difference between executing 1 instruction or all 10 billion.

I’ll be able to tell the difference energy-wise. It may also interest you to know that what takes 100 ms on your machine under zero load can be frustratingly slow on other machines.

It’s because statements like this that I frequently encounter 100 % CPU load for about a minute whenever I open ~10 Facebook pages in the background. (I do this instead of RSS. Also, 100 % means, in this case, that all 4 cores are fully utilized.)

I don’t have that problem with normal websites, of course.

I for one don’t support the idea that people should buy new computers and smartphones every year. I’m certainly not willing to make this a requirement (unless under very specific circumstances).

And don’t even try that “premature optimization” quote on me, because I’m sick of it. I have a reasonable grasp on tradeoffs between my time, machine time and code quality. But the way this statement is used today is incredibely retarded.

For example: I was working on a particular project that had to handle thousands of requests every minute and each request had to be handled as fast as possible (it was basically a proxy). I knew a specific code branch would be executed repeatedly and a lot, so I searched for some information regarding efficiency of something I intended to do. And there comes the StackOverflow with the exact same question as I had and retarded answers themed “premature optimization” and “always profile first!”.

No, fuck you. I’m experienced enough to tell what’s completely irrelevant in the overall picture and what could be the real bottleneck. Before I spend a few hours writing a code, only to measure and fully rewrite it as soon as I find out it’s intolerably inefficient, I’d like to take a look and spend a few minutes deciding what approach to use. It’s the same as with choosing algorithms or data structures. Is it a premature optimization too?!

I wish this were a github repo or such. I would love to contribute a bit more. Would be interested in seeing [idiomatic modern] C++.

Would be also cool to see the assembly output (where possible) of each.

Here’s Rust’s:

https://godbolt.org/z/uqFRP7

Looks like O3 does slightly better than Os

How is he counting syscalls? strace, or something else? I ask because I want to do a few more tests myself.

One note regarding Chesterson’s fence: it’s a useful heuristic for dealing with unknown unknowns that can’t be investigated, but as a programmer (especially one writing something new from scratch), it’s your responsibility to understand every layer below you in enough detail to make reasonable decisions. Chesterson’s fence definitely applies to dealing with black boxes in large existing applications – particularly if you’re under deadline – but when deciding whether or not to introduce a dependency (even if that dependency is essentially built into the language), you need to know that dependency’s cost. (This generally means being confident in your ability to roll your own version of any third party code you include – otherwise you will have a warped idea of how that code behaves in a variety of situations.)

The thing about programming languages is that general purpose ones don’t really exist. There are two kinds of languages: languages that are exceptionally well-suited to certain applications, and languages that are roughly equally bad at everything. When it comes to determining if overhead is worthwhile, the answer depends on whether the particular application is easier/better with the overhead or without it.

‘Hello world’ is not merely a mediocre test case but an exceptionally bad one. It’s trivial to implement in nearly every language (exceptions being esolangs like malboge and brainfuck) so there’s no sensible case to be made for it being substantially easier to implement in one language or another (though it occasionally acts as a reductio ad absurdam for boilerplate-heavy languages like Java); it’s trivial to run in nearly every language too (malboge being the exception again) so there’s little point in comparing performance; there’s no practical application for it, so there’s no grounds to determine what level of performance is appropriate (OP’s suggestion that we should use human attention as the benchmark doesn’t make much sense because nobody’s running something to print a static string in a way that requires human attention – the closest actually-useful program in terms of functionality is the unix tool ‘yes’, which because it’s almost always piped into other tools & is the bottleneck for simple pipelines, is pretty highly optimized).

I’m sympathetic to complaints about languages having too much bloat, producing bloated applications. After all, I’m a cheapskate where it comes to computer hardware & that has always led me to situations wherein I notice unnecessarily bloated applications moreso than my peers. But no language forces people to write code as bloated as your average electron app (not even javascript, and not even DOM-manipulating javascript), & even if it did, choice of language is a design choice (you can make the argument that javascript is simply not an acceptable choice for interactive graphical applications). Language matters a lot (since it defines the boundaries of what we, as developers, can easily imagine implementing & therefore shapes implementation in subtle and pervasive ways), but it’s not generally the bottleneck. You can write prolog code that’s more performant than most professional applications are, if you’re sufficiently motivated.

Optimising for “hello world”, a program nobody except programmers ever runs, is definitely missing the wood for the trees.

Interesting. I would say that today a proper hello world should at least ensure it ouputs unicode/utf8 - and maybe do l10n.

I wonder why c99 w/puts is so bloated?

Not sure if this is the most useful metric, but I gave it a try for Inko:

$ cat hello.inko
import std::stdio::stdout

stdout.print('Hello, world!')

To not measure the overhead of the compiler, I compiled the bytecode first then ran the VM as follows:

$ strace -c -- vm/target/release/ivm -I \
  /home/yorickpeterse/.cache/inko/bytecode/release \
  /home/yorickpeterse/.cache/inko/bytecode/release/e8/8772ad6c437d3772b03418ac820625197d4a200.inkoc

This produces the following output:

Hello, world!
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 21,88    0,002214         105        21           clone
 16,86    0,001706          32        52           mmap
 13,56    0,001372           5       252         1 statx
 11,25    0,001138          37        30           mprotect
  8,88    0,000898          13        68           read
  8,74    0,000884         147         6         1 futex
  6,10    0,000617          11        55           openat
  4,10    0,000415           7        55           close
  1,94    0,000196          10        19           brk
  1,28    0,000129          43         3           munmap
  1,06    0,000107          13         8           fstat
  1,00    0,000101          12         8           lseek
  0,71    0,000072          14         5           rt_sigaction
  0,43    0,000044          14         3           sigaltstack
  0,39    0,000039          19         2           getrandom
  0,32    0,000032          16         2           prlimit64
  0,30    0,000030          15         2           sched_getaffinity
  0,27    0,000027          27         1         1 access
  0,25    0,000025          25         1           epoll_create
  0,16    0,000016          16         1           rt_sigprocmask
  0,15    0,000015          15         1           fcntl
  0,14    0,000014          14         1           set_tid_address
  0,13    0,000013           6         2         1 arch_prctl
  0,13    0,000013          13         1           set_robust_list
  0,00    0,000000           0         1           execve
------ ----------- ----------- --------- --------- ----------------
100.00    0,010117                   600         4 total

So that’s a total of 600 system calls in 10 milliseconds, which isn’t too bad considering not much of Inko is optimised at this point. Measuring the size of the program is more difficult. The bytecode file for the hello.inko file is only 2.13 KB, but if we include all other bytecode files compiled (= parts of the standard library used) the total size is around 434 KB.

Even if a “Hello World” benchmark exposes complexity and layers of abstractions, it falls short:

• it doesn’t distinguish between inherent complexity and accidental complexity,
• it looks at only one side of a multi-dimensional trade-off.

For example, a JS VM allows to securely run an arbitrary program, on almost any computer, with pretty decent performance, and the JS programs are relatively easy to write. These are real achievements that required a lot of engineering, and there’s a lot of inherent complexity in solving all these problems at once. You don’t need all this complexity and abstractions for a “Hello World” program, but that’s not the kind of program that JS VMs were created for.

Rust and Go compilers could detect that a program doesn’t need threads and growable stack and trim the runtime, but they don’t, because it’s a trade-off: it adds complexity to the compiler, it adds to compile times, and it only marginally improves only some trivial programs. Resources are finite, an there are plenty of other things that compilers can do that improve more programs in more significant ways.

I think I see where Drew is coming from here, and I admire what he’s trying to do. It’s just that, as he himself admits, the way he presented the data and the inflammatory commentary around it is unfortunate.

I’m old. I started out on a 6502 based machine with 16K RAM. I am very keenly aware of the fact that Python, my language of choice, could easily be seen by someone who’s used to working in lovingly hand crafted C as ludicrously bloated.

And I do care about what’s happening at the syscall level, but ultimately I make the pragmatic choice that the problems I’m trying to solve make thinking about things at the level Drew is working at a waste of my time.

If nothing else, I think this could be a good case study in how good scholarship can be obfuscated past the point of utility by incautious language choices.

And while we’re talking about it, can we all agree that “bloated” is just the most flame-bait-y word in the English language? :)

Previous lobsters discussion on the original Hello World article, for those who missed it.

I think Drew’s main point was what you get by default…and how hard it is, to get the ideal. How come there can’t be a flag (-Os or whatever) in Rust or Go, that enables the binaries to be their most ideal size? I think that’s the point he was more or less trying to make.

Great response nonetheless.

Tried Nim 1.0.4 (on Linux amd64), with strace call borrowed from andrewk’s comment (also wish it was included in @ddevault’s article, would make runaway community comparisons easier):

$ cat hello_e.nim
echo "hello world\n"
$ strace -c -- ./hello_e 
hello world

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 24.60    0.000046          23         2           write
 20.32    0.000038           6         6           rt_sigaction
 18.72    0.000035           9         4           mprotect
 13.90    0.000026          26         1           munmap
  9.63    0.000018           2         9           mmap
  8.56    0.000016           5         3           brk
  4.28    0.000008           3         3           fstat
  0.00    0.000000           0         1           read
  0.00    0.000000           0         2           open
  0.00    0.000000           0         2           close
  0.00    0.000000           0         3         3 access
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           arch_prctl
------ ----------- ----------- --------- --------- ----------------
100.00    0.000187                    38         3 total

I tried adding a quit 0 to force it to emit an exit syscall, but still don’t see one (or is it the brk one? don’t know syscalls, sorry!). With the quit the number was also 38. Counting “unique syscalls” by hand gives me 13 IICC (If I Counted Correctly). Didn’t see any difference in terms of syscalls when I tried adding -d:danger or --opt:size (though I’m not sure if the names of syscalls used did not change; but both the total stayed at 38 and the uniques seemed to stay at 13).

As to size, with default debug build I got 92KiB, with -d:release 83KiB, with -d:danger or --opt:size 66KiB (as reported by ls -lh), edit: with -d:danger --opt:size I got to 33KiB. The name is hello_e.nim because I also tried a hello_w.nim with stdout.writeLine "hello world\n" — the syscalls were the same, but sizes were (to my surprise) slightly worse (maybe echo uses some shortcuts? no idea). edit 3: IIUC, for the size comparison to be correct, I should add glibc size, which is about 1.8MiB on my system, plus 159KiB for ld-2.23.so, I suppose? That puts it more or less where other dynamic glibc cases are.

IIUC, as far as syscalls, this makes it worse than Zig, C static, and C musl dynamic, but better than C glibc dynamic or Rust (!). As to size, it’s not clear to me if Drew added the size of libc .so into the total (because it’s the runtime library) or not; if yes, no idea how to do that correctly. edit 2: With --passL:-static, i.e. statically linked with glibc, and still with -d:danger --opt:size, the size balloons to 912KiB. No idea how to quickly test with musl (do I even have it installed?), I don’t care that much to put the effort required to find out how to do this (with or without Nix).

Thanks for this.

That post was a pile of fuming garbage; I guess it did at least one thing right as it prompted this article to be made.

The comparison is a bit biased in favor of compiled languages because interpreters are always passed a file containing the source code. Passing the code as a command-line argument, for instance, reduces the number of syscalls.

For instance, on my machine, Lua (5.3.5) uses 80 syscalls if I pass the code as a command-line argument and 85 if I pass it as a file. Python (3.8.1) uses 944 and 969 respectively, Perl (5.30.1) 227 and 229.

Note that Lua still always fewer syscalls than the Rust example (which uses 95 on my machine with 1.40.0)…

Still lacking: actual steps done to get the values for syscall counts so we can fix/reproduce his numbers. If you’re going to complain about a metric, let people at least know how you gathered it so we can maybe do something about it.

As somebody who avoids premature optimization, I believe the more important metric here is lines of code required to write a simple “Hello world” program. In this case, Crystal, JavaScript, Julia, Perl, and Python are the clear winners. Accounting for both lines of code and syscall count, Crystal seems incredible.

As an aside, I wonder how AOT-compiled Julia fares. A lot of those syscalls are probably from the JIT compiler doing its thing, and cutting it out would probably move Julia much further up the list.

# dynamic
go build -o test test.go

I thought Go builds statically linked binaries by default.

minimal haircut for PicoLisp startup - http://ix.io/26uz

I think this misses the point of the previous article. I don’t think that the previous article is shaming languages for providing more features or anything like that. It highlighted the fact that a bunch of languages in their compiled form do additional things that are unnecessary to do what the code does. This is where the author misses the point. E.g when talking about stack traces, the author seems to not know that the Zig(safe) build does have stack traces using DWARF while only making 3 calls and weighing 11KB. Doing the “lets include repeating in the program” section misses the point again. This wasn’t any kind of a performance benchmark. It’s more of a compiler optimization benchmark. Then we go to excusing go. Yeah, sure, we want fast builds. But do we really need to have all of that stuff that is entirely unnecessary for the execution of the given code. So why have it? Do we use reflection in our code? Do we use multi-threading? Do we create any objects that would require error handling? Does the task benefit from knowing weather the streams block? Should this program care about signals? Do we need to know the executable path? No. No we don’t and this is additional code that complicates debugging. Now some might say it doesn’t complicate it, but if you need to debug a performance bug on startup, all of this different stuff just gets in the way, while not being necessary.

I like the writeup, but I’ll be in the minority here by actually agreeing with Drew (which I am loathe to do under other circumstances–or at least, by agreeing with my interpretation of what he may have written).

One of the common refrains here is “Well it’s a trivial task, this isn’t a real workload.” Okay, if it’s so trivial, it should be pretty easy to do it without obviously sucking. If a PhD graduate can’t make a peanut-butter and jelly sandwich, I’m not going to go “well PBJ is just this trivial cooking case, and think about how much they know about type systems!”. There’s a lot of handwaving over the “complexity” and extra neat features of runtimes, but it seems few are willing to admit that like, maybe, it’s super weird that copying a constant pile of bytes into a file descriptor is super inefficient in a lot of these languages.

I suspect that if there were some additional examples, say handling threading or file access or network access, maybe Drew’s grump would’ve been taken more seriously. That said, the man still has a point and we’d be poor engineers to overlook it.

would be cool to see measurements for myrddin

Looks like using MUSL with Rust produces 10 syscalls, 6 unique.

rustc -C opt-level=s --target x86_64-unknown-linux-musl hello.rs

I wanted to check D with the -betterC option and it compares quite well with the other entries in the table!

(dmd-2.090.0)$ dmd -betterC -O hellobc.d
(dmd-2.090.0)$ ls -al
total 16
drwxrwxrwx 1 speps speps  512 Jan  6 21:09 .
drwxrwxrwx 1 speps speps  512 Jan  6 19:41 ..
-rwxrwxrwx 1 speps speps 8328 Jan  6 21:09 hellobc
-rwxrwxrwx 1 speps speps   97 Jan  6 21:04 hellobc.d
-rwxrwxrwx 1 speps speps 1816 Jan  6 21:09 hellobc.o
(dmd-2.090.0)$ strip hellobc
(dmd-2.090.0)$ ls -al
total 12
drwxrwxrwx 1 speps speps  512 Jan  6 21:09 .
drwxrwxrwx 1 speps speps  512 Jan  6 19:41 ..
-rwxrwxrwx 1 speps speps 6128 Jan  6 21:09 hellobc
-rwxrwxrwx 1 speps speps   97 Jan  6 21:04 hellobc.d
-rwxrwxrwx 1 speps speps 1816 Jan  6 21:09 hellobc.o
(dmd-2.090.0)$ strace -c -- ./hellobc
Hello betterC
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0         1           read
  0.00    0.000000           0         1           write
  0.00    0.000000           0         2           close
  0.00    0.000000           0         8         7 stat
  0.00    0.000000           0         3           fstat
  0.00    0.000000           0         5           mmap
  0.00    0.000000           0         4           mprotect
  0.00    0.000000           0         1           munmap
  0.00    0.000000           0         3           brk
  0.00    0.000000           0         1           ioctl
  0.00    0.000000           0         3         3 access
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0        10         8 openat
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                    44        18 total

Used the example from [1]:

extern(C) void main()
{
    import core.stdc.stdio : printf;
    printf("Hello betterC\n");
}

[1] https://dlang.org/spec/betterc.html

I think they’re both right, mostly. We pay in syscalls and startup time for stable APIs/ISAs (sorry, I just watched the 30 million line problem). Are they value-added, and added with purpose? (I think Caleb argues yes) Are we getting ripped off a bit? (I think Drew argues yes)

I think the article would be stronger if you consider the Go GC and its “downsides”. Automatic garbage collection has many benefits, sure, but also some downsides. These downsides are suprisingly minimal!! thanks to their work. If my mom were living in the dark “to save electricity” (b/c that was true -30yrs) I wouldn’t extol the virtues of lighting, I’d show her how cheap an LED bulb is (cents on the dollar). Go is maybe an outlier here: you might get sticker shock when you see the cost of, idk, the Perl 5 GC. Ruby 1.8 or something.

EDIT: thinking more, I think we have to be very specific about which runtimes are being wasteful/costly in what ways: it really doesn’t help to just say GCs are slow or any other “truism” (like I kinda do! above)

# static w/o cgo
GOOS=linux GOARCH=amd64
CGO_ENABLED=0
go build -o test -ldflags '-extldflags "-f no-PIC -static"' -buildmode pie -tags 'osusergo netgo static_build' test.go

Aside: it is getting way too goddamn difficult to build static Go binaries.

I’m pretty sure -extldflags is ignored when cross-compiling and/or CGO_ENABLED=0, although -buildmode pie implies dynamically linked executable unless you use external linker. Since go build run on linux/amd64 host, Go probably assumed that it can use external (host) linker.

Unless you need statically linked and position-independent executable, Go can compile programs using it’s own toolchain.

GOOS=linux GOARCH=amd64
CGO_ENABLED=0
GO_EXTLINK_ENABLED=0
go build -o test test.go

Note: GO_EXTLINK_ENABLED=0 forces internal link mode.

You can also build dynamically linked position-independent executable without Cgo runtime.

GOOS=linux GOARCH=amd64
CGO_ENABLED=0
GO_EXTLINK_ENABLED=0
go build -buildmode=pie -o test test.go