"I mean, who doesn’t want to be simple ? And what better way to frame a debate as simple; good, complexity; obviously bad. Could we say then that simplicity will be Go’s lasting legacy ?"
I think this misses the point. Complexity isn't bad. Only Incidental complexity is bad. Inherent complexity exists in the domain itself and is unavoidable. If this inherent complexity is not expressible by abstractions in the core language itself. Then it must be expressed in libraries, or user code, or in the way end-users configure and use the program.
Go is interesting because it created abstractions for concurrency in the core language itself. Go is a more complex language because of it, but concurrent programs user code is less complex because of it.
(On a side note C++17 is getting a more abstract version of go-routines. Thanks Go.)
I think this misses the point. Complexity isn't bad. Only Incidental complexity is bad. Inherent complexity exists in the domain itself and is unavoidable. If this inherent complexity is not expressible by abstractions in the core language itself. Then it must be expressed in libraries, or user code, or in the way end-users configure and use the program.
Go is interesting because it created abstractions for concurrency in the core language itself. Go is a more complex language because of it, but concurrent programs user code is less complex because of it.
(On a side note C++17 is getting a more abstract version of go-routines. Thanks Go.)