Put in a less snarky way, C is often way more low-level and tedious than you need.
The great thing about Go is that it lets you blend high-level and low-level programming in the same program, only getting low when you need to. It feels like a great mix of C and Pythonubyerlhphavascript.
I've given many talks on this, e.g. http://talks.golang.org/2014/gocon-tokyo.slide#1
Well, I wouldn't go there (C is antiquated/under-equiped like an abacus) if I was advocating Go.
After all, Go, just like an abacus doesn't have generics, or, besides channels and goroutines, most other facilities modern languages offer for that matter (GC and some basic data structures built-in is so 1980).
If you need mainly a large number of features in order to program, Go probably isn't for you. But from the perspective of a C/C++ programmer, this isn't likely to be an important point. Languages with more features than C have been available for 40 years (depends on what you'd count as a feature), so there were plenty of "better" choices in that regard available for said people.
For me, the lack of some "features" is a great asset for Go, I probably wouldn't have bothered to learn a new language if it had boasted the complexity of Rust or Haskell.
Where are map, reduce, select, filter, fold, zip ...?
I don't consider hand-rolling them in for/range as equivalent. Can I wind up with the same result? Yes. But I could do it with gotos too.
And I've seen "loops are the same as map/reduce etc" advanced as a serious argument by people who weren't, so far as I could tell, trying to tug on my leg.
What gets my hackles up is claiming that "it's just the same".
The same argument works for any language that satisfies the structured programming theorem, including assembler.
"If writing simple BNE $reg gets your hackles up, Assembler is not the language for you."
I look forward to seeing how I can chain multiple operations on a set into a single line of Go.
Also see the aforementioned "the answer is to write a loop".
It is not the same.
Saying "supports higher level and lower level" programming when you don't actually support most higher level programming primitives is also, from my point of view, untrue.
Go's design choices are what they are, which is fine. But I just see a lot of people who argue, in all seriousness, that a loop has the same level of abstraction as map, filter etc. It simply doesn't.
That languages are turing equivalent doesn't mean that they operate at the same level of abstraction; trying to pass one off as being "the same" as another is just silly.