Go is more like "decades in hindsight", though. Literally the case with generics, just to give you one example - and for all the talk about how other languages aren't doing it right and they're waiting to figure it out, the resulting design is exactly the same as those other languages, except that now they had to bolt it onto the language that evolved without them for a decade, with all the inconsistencies this creates.
Different languages speak to different people. I feel the same way about Scala and most other functional languages. To me, they’re fun and all, but I wouldn’t build anything large-scale with them. My problem space is interesting enough that I don’t have to worry about Go being boring.
To be clear, I mean "boring" in the positive engineering sense of well-defined and reliable. The kind of work that I don't like to do in Go is "interesting" in the negative sense of lots of special cases, complicated branching based on combinations of data, complicated error handling... stuff where pattern matching and use of types like Option and Either shine (hell, even exception handling helps!) Basically the kind of stuff that good engineers would design out of existence if the product managers and salespeople would let us.
I would rather scratch my eyes out than use Go for the kind of code I write day-to-day, but Go looks amazing for the kinds of things where you can achieve high levels of boringness, which is what we should all be striving for.