The author makes a benchmark that compares a go program that explicitly buffers many "hello world" strings, and compares this to an assembly program that does n

The author makes a benchmark that compares a go program that explicitly buffers many "hello world" strings, and compares this to an assembly program that does not do this, then goes on to argue that this shows that high level languages can be faster. This can certainly be true, but this particular example is not a great way to show it, because the same optimization can be done in an obvious way in assembly, (just allocate enough space with brk or mmap2, write your strings and send the right memory address to ). This would of course be harder to do in assembly than in Go, but it is still quite straightforward to see what is the optimal way to do it. Furthermore, this would probably still outperform the optimized Go version by a wide margin. A better example could be where a compiler picks an obscure but faster parallelization operation, or unrolled a loop appropriately in a way that is both faster and unlikely to be written by a competent human, or a complex memory management scenario etc etc. I think this is not the point of the original article though. I think we all understand that abstractions can in theory bring great benefits, but we do need to scrutinize the cost they add. The hello world examples shows that even with the simplest program we can imagine, the result is extremely far from optimal in popular programming environments. If this is the case, why should we assume that these same compilers are doing an excellent job in situations that are actually hard?