Tbf, it's a useful indicator whether a language follows the "simple things should be simple, complex things should be possible" principle. The vanilla 'Hello World' should always be an example of the "simple things should be simple" part.

The typical Hello World implementation tends to reveal very little about the language, because their print/println/printf/whatever implementations have failure modes that are either impossible to handle or easily ignored (e.g. panicking, throwing exceptions or returning error codes which you can implicitly ignore without compilation error) which they frequently use to effectively hide the complexity inherent to the problem. Some examples of this:

The C Programming Language includes a Hello World example that calls printf without checking the return value and returns a success code from the main function regardless.

The first example I find when googling "java hello world" simply calls System.out.println and neglects to call System.out.checkError to see if it was successful before exiting with a success code. Some Java developers won't even know what I'm talking about here because it has never occurred to them that printing may fail in a way that can only be discovered through this weird checking mechanism.

Go's example from their getting started guide simply calls fmt.Println while ignoring the return values which include any error that may have occurred, and the program exits with a success code regardless.

The example from Rust by Example is at least correct and thorough in that it will predictably panic upon error when invoking the println! macro, which is documented, but will through that mechanism not give you the option to actually handle the error except by using a different mechanism which front-loads more of the complexity (e.g. writeln!(io::stdout(), "Hello World")? for something equivalent to the Zig example).

Of course for something as basic as Hello World it might be easy to tell whether it was successful through a quick glance at the output, but consider some of these limitations in a larger program.

So maybe there is more inherent complexity to this problem than a typical Hello World implementation will reveal. Add to that the complexity of Zig's new swappable I/O models and their Hello World isn't so absurd.

It's really easy to make a C hello world program that forwards the success of printf:

    #include <stdio.h>
    int main(void)
    {
        return printf("hello, world\n");
    }

I just tested it in a Bash shell, and it works great, only adding a single word, with clear functionality, to the example.

This program will always give a non-zero return code. This is unconventional if not straight up wrong, if the goal is for main to indicate whether it was successful in printing.

I mean sure, from a purely 'is this program correct' pov you're correct, but then a hello-world is mainly about "how do I get some frigging text to show up on the terminal", and how likely is that to fail anyway (at least I never had the canonical C hello-world fail on me).

What's the point of showing an example if it's incorrect? If someone asks "how do I get some frigging text to show up on the terminal" and the answer is incorrect, it's bad advice as far as I'm concerned.

> and how likely is that to fail anyway (at least I never had the canonical C hello-world fail on me).

I don't expect to know how likely writing to stdout is to fail and I don't think any answer to that question other than 0 really warrants ignoring the potential error if the correct result of invoking your program depends on it. For what it's worth, at least in Unix-likes, stdout could be pretty much anything. Writing to stdout could fail because a switch at the user's ISP is rebooting.

It shows the bare minimum overhead needed to start a project and gives some insight into the readability.