The builtin println does not return a value. As stated in the language specification: http://golang.org/ref/spec#Bootstrapping
rogerbinns is right, fmt.Println() does indeed return an error value. I still don't understand the argument. Println() can fail. That's why it is able to return an error.
You can choose to ignore it, that's fine. If it's something that you're worried about failing, then it's worth the "effort" to handle the error where and when it happens.
I guess ultimately, all of this stuff is such a non-issue. It's a cliched response to a lot of Go criticism, but acutally write something in it. Armchair critics would have you believe that exceptions and generics missing is the end of the world. Number one, it's not. Number two, these simplifications exist for a reason. One of Go's guiding principles is minimizing magic that is not visible or explicit. (That's why new/make exist, no exceptions, no generics). It eases development speed, code clarity and compile times.
No generics actually harms code clarity and destroys type safety.
The official stance on that issue is: yeah, but it's better than the hassle of supporting generics (compiler effort, object code size/slowness, and excessive high-level abstraction (a bad thing in the Go world).
I have a foot on both sides: I miss generics when I'm writing one-off low-scalability code, but it's nice to have the speed of low-level Go code, and perversely fun to actually spend some of my coding time writing all those low-level sorting and array-building routines that are the meat of programmer interviews.
Now, when a candidate asks "When will I need to write a method to sort the keys of a map?", I can answer "Every time you use a map[string]T for a novel T!"
I hate novel T now. (<-- This is also a design feature of Go, the passive pressure to not use large hierarchical types, and try to do your work with just maps and slices of primitives)
It's actually clearer as to what's going on since slices are a language primitive. They are simple and extremely transparent. This is absolutely not the case with Java's collections library or the C++ STL.
It wouldn't be a trade-off if there weren't situations where generics are really useful. But this rings more like an armchair criticism of Go than a criticism from someone who's written some Go programs. For my part, I wish languages like Java were less hostile to arrays.
If this is 'armchair criticism' why do Go's designers say they are considering adding generics support?
A canonical hello world program should have a non-success exit code if the "hello world" printing failed. This will happen automatically with exceptions and similar mechanisms.
The problem with Go's error approach is that you have to handle it where it happens. You can't delegate the error handling to a function 5 levels back in the call chain. So you end up having to write boilerplate code around every single call and intermediary layer, or just not be diligent, and that lack of diligence starts with hello world.
It is the boilerplate code I object to, and exceptions are just one pre-existing solution. For example Go could recognise code patterns and automatically run code that returns errors to the caller if not otherwise handled or marked as ignored, although this is a certain amount of magic.
Since there is no code for ignored errors, that means there is no code test coverage for them. For example coverage on hello world will always be 100% even though the case of println failing didn't happen. Multiply this by a larger program and there be gremlins.