As someone with the misfortune of inheriting a million plus loc Go project I disagree. Go is a nightmare from the duck typing to dependency management.
As far as "the nightmare of {using interfaces}" -- I have no clue to any controversy there. It is one of the most celebrated features of Go. Not sure where you were going with that. In Python, I do find duck typing to be a nightmare because you don't actually _know_ what you have. Can you change it? Try it and if it breaks you will know. Or you use it like a list but it is a string and that gives strange, unexpected behavior, so you end up doing things like `param=force_list(maybe_string_or_list)`.
So yes, you can change that string and you do know.
It's still better that it's optional and gradual - it's unnecessary overhead on smaller projects, spikes, notebooks, etc. which are what most big projects grow out of.
;)
As long as the type supports the same interface anything goes, even it actually supports another one, where the methods have the same name, with different semantics.
Go's verbosity is usually found in multiples (if err), not in long forms (int[] arrayOfIntegersWithValuesOneToFive = new ArrayFactory().createArrayWithSize(5).populateWithValues(1, 2, 3, 4, 5); ).
With huge projects that pull in packages i have seen the dependency management become a mess but most of the time its not that bad.