> not having as many whistles and bells prevents high complexity codebases. This is a thinking error I see extremely frequently from golang proponents, and it

> not having as many whistles and bells prevents high complexity codebases. 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.