I found it funny the first comment seemed to deride the use of function pointers, compare, map, and filter as too different than the for loop centric Go. Even C provides sort with a function pointer for compare...
People find a language/library too complicated, so they go on their own to write a simpler version, only to find out that they missed very important cases that prevents it from having the same qualities.
Grudgingly, they then gradually re-introduce what they initially strongly opposed against, but now they also have to work around their current design and bogus abstractions that wont let that happen easily.
That's going to create a lot of cruft, edge cases and API complications, to the point where a bystander might decide it's too complicated and, they too, go on their own write a simpler version.
Go hasn't learned a single thing.
There's a lot to love and learn from functional programming.
Borland first attempt to C++ "generics" was the initial release of Borland International Data Structures 1.0 (BIDS) around 1990, where they used the preprocessor to generate multiple copies, something like
#define LIST_T int
#define LIST_TYPE MyIntList
#include <bids/list.h>
Around 2005 it was common to use Eclipse EMF framework, alongside plugins to generate Java code (<= 1.4) that would create type safe subclasses from collections with Object.
So learning is a hard process, then again this was their point of view when C was created,
> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.
How do you explain the success then?
Go hasn't tried to be all things to everyone. There are lots of things out there that need simple solutions and Go provides for that with and nice middle ground of dev and computer performance.
If I want to read from one computer, write to another computer, concurrently, with low footprint, and speed, it's a great tool.
If Go has learned nothing, are Go programmers just picking something more difficult that performs worse? I've found it has dislodged services that were previously written in Node, Ruby, or a whole J2EE stack. Sure there are people out there trying to make it all things to everyone and it fails in some of those things, but it does great at others.
A megacorp funding 100 engineers to work on the compiler, libraries and tooling for 10 years
Go itself is not particularly simple, actually. It's simplistic, meaning that you have to jump through more hoops to do common things. For a concise example, consider adding an item to a slice in Go vs adding an item to a collection in pretty much any other modern language.
That's been in non-generic Go for a while (passing a closure for sorting): https://golang.org/pkg/sort/#Slice