> I think that we can all agree that when it comes to Go, simple code is preferable to clever code What even is "simple code"? The problem I have with Go is wh

> I think that we can all agree that when it comes to Go, simple code is preferable to clever code What even is "simple code"? The problem I have with Go is when you need to do anything non-trivial the intent of the code quickly becomes lost in lots of for loops. You can try to abstract that away so that your program reads better, but in my experience that has always been a poor decision. I get the impression Go wants me to write big for loops that do lots of work and have lots of scope and that it doesn't want me to break my problems up into steps (like I might in a functional style by separating each stage of the computation). Go wants me to have mutable variables and mutable references. State management in Go is questionable and really left up to the programmer (mutable references and data hiding are too easy compared to functional languages where immutability generally forces you to think harder about your data's structure). Sure, this is usually going to lead to a more performant end-result, but it's not going to lead to the "simpler" result (in my eyes) There's a lot about Go that I do like - the toolchain and docs are particularly good, and the standard libs are modern yet succinct. It is low-level enough when I want it to be and relatively high-level (nits above aside). The support for concurrency and distributed systems is also good. I can see how "simple" is exhibited there If I had to guess at what "simple" means to Gophers (well, the Golang team at least) it would be using the fewest number of language primitives/features to get done what you want to get done. There are a lot of peculiar ways channels are used for example where other languages might prefer things like condition variables. The range keyword is overloaded and used different in several contexts but it does keep the number of keywords low. Most Go tends to look the same (low-to-the-ground, verbose) Go is great until it isn't and when it isn't you have little choice but to brute force around some of Go's clunky pieces. Extracting high-level meaning out of Go source can be difficult because of how verbose it can be. I'm glad it's around and it's a good choice for a lot of projects, but I really wish we could have simple things like generics so we can write cleaner code In short, Go as a language may be simple (and I think it is) but I need to solve complex problems - either Go helps me with that complexity or it leaves me on my own. Go has chosen the latter of those options and I'm not convinced that our Go code can be simple for many non-trivial applications