There are plenty of C family syntax languages that are more compact. The main reason why Go is very verbose is because it doesn't support generics (so you have to duplicate a lot of code) and no exceptions (so your code is littered with

    ok, err := Foo()
    if err { ... }

and then the caller has to do the same thing (basically reinventing manually what exceptions do for you).

Absent exceptions, for quick-and-dirty stuff I wish Go had a mode like Bash's 'set -e', which just aborts on any error return from any call. When the only thing you want to do on errors is abort the program, it's really tedious to write that same "if err, exit" after every function call. But perhaps the golang people's answer would be that for those kinds of quick-and-dirty programs, I should be using a shell script anyway, not Go? Or maybe Perl, which does require an explicit check, but uses a compact idiom for it, f() or die;

Yeah, I'd quite like an `or die;` equivalent, as I've run into the same thing as you: scripts that can't do anything if the chain of commands fails anywhere. I have written functions that do the same thing: xOrDie(), but it's a bit sucky.

As far as "Why Go for shell scripts?" I actually think Go is pretty well suited to shell scripts (aside from no or die): getting stdout/stderr pipes set up is pretty trivial with the exec package. There must be anecdotal law somewhere that states that all shell scripts tend to Turing completeness over time: what starts with "oh, a small shell script would do this" always ends up growing to a full blown 1000+ line program with multiple code paths. Writing the first script in Go is a piece of defensive programming so that when it inevitably grows, it's growing into a language that better supports its size (static typing, readability, libraries etc.) It's probably overkill for personal stuff, but it is probably the right hammer for the job over time when it comes to corporate work.