Agreed, I also didn't understand the real point the author was trying to make: if you hate it, say so and be done with it, don't wrap it in a 'I love you to dea

Agreed, I also didn't understand the real point the author was trying to make: if you hate it, say so and be done with it, don't wrap it in a 'I love you to death but..' kind of way. I think with 'go' as a language when you start with it, there's a lot to love: things are simple again; "Look ma, a real program that does something with almost no code and also no magic shit behind the scenes!". But things are always simple and nice in the beginning, when you are focusing on just a small part of the complete picture. The problem with 'simple' is that unless it abstracts away all complexity you'll ever need to deal with, you'll need to do a lot of work yourself: it's the typical RISC/CISC argument from yesteryear: do you want a small instruction set which is simple but results in a longer program, or a complex large instruction set which results in a smaller program? So, to be able to deal with all possible complexity in all possible scenarios, either the language has to be vast in its expressiveness (go isn't) or it has to come with a vast standard library which offers additional expressiveness through classes / methods / functions / subsystems or whatever the language is lacking, OR you have to write it all yourself. In the end, the net-result is the same: the system as the end result of your work is the combined complexity of the code written by the developer(s) and the complexity of the libraries used. Go doesn't change that, it just moves the divider between 'own code' and 'libraries' more towards 'own code', even if that's simpler to write because the language lacks things which some people might consider 'oh god this is complex, I'll never understand this'.