For a language that _competes_ with C, caring about how semantics map to hardware instructions is absolutely within the domain of concern. It may not be a top priority, but if you _ignore_ it too long, you'll make uninformed high level decisions that prevent entire classes of important low level optimizations without extensive re-thinking. So just do the thinking upfront and save yourself and your community the hassle.

> caring about the assembly output is a spectacular case of premature optimization

I don't agree! at least for operating systems.

Consider that some operating system code may be run a million times per second, on a million different machines (e.g: block system IO on linux). We very much want our assembly to be pristine in this case.

I also like the idea of "optimality" brought forward by zig. In the post you link, there's an ideal hello_world in asm, can we have a higher level language that doesn't sacrifice this ideal achieved by assembly?

Consider that some network cards are now capable of 400Gibps, and modern OSes are not capable of handling these linerate. I strongly believe the bottleneck should be in the hardware, if the software can't max out your hardware then your software has failed.

I like that zig focuses on optimality.

> Consider that some operating system code may be run a million times per second, on a million different machines (e.g: block system IO on linux). We very much want our assembly to be pristine in this case.

I would believe that most of the time of a processor is dedicated to run userspace code, not OS code (regarding to the work that must be done). At the end of the day, the OS is "only" a scheduler to share hardware resources between unrelated tasks.

> I like that zig focuses on optimality.

Optimality isn't required in many real world businesses. Optimality is often a tradeoff : with optimality you lose in flexibility. An optimal program with SISD instruction set isn't optimal anymore when SIMD instructions are introduced. Your "optimal" asm program is still optimal on x86, but also totally obsolete because it cannot use the latest NEON instructions from ARM or 64bit instructions.

> I would believe that most of the time of a processor is dedicated to run userspace code, not OS code (regarding to the work that must be done). At the end of the day, the OS is "only" a scheduler to share hardware resources between unrelated tasks.

Yeah, that's true if the OS is well-written and has had continual and extensive performance work done. Passing 200 Gbit of network traffic in software with firewalling is non-trivial and the number of cycles you get per packet is pretty modest. These things do matter.

> Passing 200 Gbit of network traffic in software with firewalling is non-trivial and the number of cycles you get per packet is pretty modest

If that's the only function of the program, are we still talking about an "Operating System" ?

> ... caring about the assembly output is a spectacular case of premature optimization.

This is a hobgoblin. Assembly output of a compiler is the very baseline of performance. It requires no effort on behalf of the programmer (aside from learning a language).

Now, if you're skimming the assembly after every compilation and, say, fuzzing your implementation to coax the compiler to emit the best possible assembly... that's probably premature. If you're writing inline assembly before doing a higher level implementation, that's probably premature.

But choosing a language on the basis of its performance:effort ratio is downright pragmatic.

Assembly output is important when you are trying to understand an exploit, or to make sure none can be produced.

Can be important for kernel stuff.