This is a thinking error I see extremely frequently from golang proponents, and it has never made any sense to me. If it were true, it would mean that forth would be a great programming language to work in to keep complexity low - after all it is an even lower complexity language.
Having an, as I'll rephrase it, anaemic language really just means that people will either limit the scope of what they write in it to low complexity things, or, more frequently in my experience, will simply not bother handling the potentially complex details of what they're trying to do, because it's simply too painful and laborious. Corner cases don't get handled (can you really justify the extra 200 lines to handle that case?), user-facing edges don't get smoothed off (can you really justify the extra 200 lines to be able to handle float inputs to that option?), things generally just get dropped on the floor. And I don't blame people - I get to the end of a day and the idea of having to write yet another for-loop makes me just want to go home instead.
The hair-shirt philosophy of golang is not one I subscribe to.
I think the word "simplicity" needs some quantification, because I think often people mean it's easy for beginners = simple. And that doesn't ring true for my definition of simple.
What I'm more interested in where it is "simple", is that it allows logic that doesn't need to be entangled to remain cleanly seperated so that changes to one need not require you knowing about any other parts of it, and are not at risk of breaking anything else.
And similarly, that if I were to build something with inherent complexity the language would add minimal additional complexity above it.
Does Go meet that definition of simple?
Of course this language simplicity means that programming in the language is much harder. To me that’s almost tautological: things the language doesn’t do for you become things you have to do yourself.