Yes, less repetition and more
x, err := dostuff();
if err!=nil { return nil, err; }
y, err := otherstuff(x);
if err!=nil { return nil, err; }
z, err := morestuff(y);
if err!=nil { return nil, err; }
w, err := alsodo(x,y);
if err!=nil { return nil, err; }
Murray Hill gathered together people focused on solving real problems for the most distributed industry in the last 150 years. They had the opportunity to witness technologies and solutions that worked. And I quite sure that they suffer those that doesn’t.
From my humble point of view, Go is a compromise of what works in real life, the first time I see the go compiler, I traced it back to the good things of Limbo, C, object oriented programming and the adding of a simple syntax to create CSP concurrency made it a killer application.
Personally, I would love if the language design was a step closer to I.e. ocaml, especiall if I see the 'this is a struct, but only one of the fields should be not-null' hack to implement sum-types, or when I see how closely select over a channel resembles pattern-matching.
But the library ecosystem is good and 'just using forloops' is fine.
Hence, I think the first sentence of your question has no effect on the question. For the question of >why isn't it functional? I think current state of Go is performing enough for Google's problems.
I mean, I've returned functions from functions, and passed functions as parameters.. and there's no requirement that a function modify state anywhere.. what else is required to be purely functional?
"Purely functional" means that pure functions are not only possible, but that they are the only kinds of functions in the language.
While it might be theoretically possible to write purely functional code in Go, it doesn't have mechanisms for treating side effects as values, and the heavy reliance on arrays and channels and things would make it unnatural. Pure functions don't contain loops because a loop is only used to generate side effects. That would be hard in Go, but it's pleasant in languages that support pure FP.
If this explanation sounds weird, learn some Haskell to get an idea of what pure FP is like. It's fun stuff.
Functional programming is certainly better in a lot of ways, but Google wasn't trying to build a "good" language, they were trying to build a "good enough" language, which is why it doesn't really innovate, but merely pulls in familiar features into a simple package. Go isn't the best at anything, it's just good enough at several things, and very simple to learn, and that's exactly why Google uses it.
And the result is not "just good enough". It's actually quite good for their problem set.
1) Who said that what you "keep reading" about functional language is true?
2) Even if true, who said that what you "keep reading" about functional language is true in all cases?
3) Who said other factors don't come at play, and might be even more important?
4) Who said a language has to adopt functional principles wholesale, and isn't it enough that it has some (as languages increasingly get)?
5) Doesn't the IT industry always find some methodology to hype as the silver bullet, much akin to the diet industry? Maybe functional programming is one of them?
6) If you don't have personal experience with functional languages or can't personally appreciate whether they really do make "reasoning about code easier", why take what you read about them at face value? Perhaps they miss something?
7) To argue on the other side, who said that when a large company builds something, they get it right? Often it's the inverse.
8) Who said Go was built "by Google" in the strong sense? Go was a rogue project from a small team AT Google. It wasn't an official Google effort (the way Java was for Sun, .NET for MS, and so on) to make an official Google language. It's just that that group was concerned with "what language features would be a good fit for the work with do here at Google" -- but the inverse is not true, Google as a company/management/etc wasn't concerned with building such a language. They just went ahead with people devoting time to the project.
9) Who said the Go team has kept with the times (or even with older but still relevant PL research)?
What I write above are not answers and are not meant to be "the truth", they're meant to make one see the situation more critically.
Re 2 and 3: I think this is the big one. Functional language are great in some situations. Non-functional languages are great in some other situations. The problem is, someone who doesn't know functional languages gets into a situation where they're good, finds out about functional languages, starts using them, and a large number of their problems go away. They experience functional languages being wonderful. But they conclude "functional languages are wonderful" rather than "functional languages are wonderful in that situation", and they proceed to try to sell the world on how wonderful functional languages are. (Not just functional - ditto for other language styles and development techniques.)
The trick is, given the problem, to pick the right languages, tools, and techniques, rather than to have One Right Answer.
Re 9: I'd say, given Pike's background, that he almost certainly knew at least the older PL research. Ditto Kernighan (who didn't design the language, but did write the book).