"The difference between Camera.shoot() and Gun.shoot() can be important, and when you want to upgrade a library you need to know what you're implementing."
If I went looking, and if the archives are still there, I could probably find posts from myself on comp.lang.python complaining about "duck typing" for just that reason.
I was wrong. In the 10-12 years since I posted that, I've been programming in nothing but "duck-typed" languages, and I have never once encountered that problem. Not once. Not even a little. Not even close.
When theory conflicts with reality, I unapologetically side with reality.
HN and the internet being what it is, I'm sure someone can pop up here with some horror story about when it happened to them, but I would contend that it's still something so unusual as to not be worth planning for. Maybe just a twinge in the gut if you really did declare an interface with just a Shoot of no parameters and no return value, but... if nothing else, in the Go world, the odds of you having a Camera.Shoot() and a Gun.Shoot() method are low anyhow, and the odds of them conflicting even lower. First you have to declare an interface that both of them fully implement. If you have a .Reload method on your gun, but not your camera, you can't accidentally cross them. If you have a .Reload method on both, but the Gun takes an Ammunition argument and the Camera takes a Film argument, they can't cross. And from a pure software-engineering perspective, you have to a have a program in which you are using the same exact word for two completely different concepts, which can happen, but is bad practice and still takes some work.
Honestly, worry about it when it happens and not before.
"If you're using an injection framework in Go,"
I see no utility in using an injection framework in Go. You just inject things. People keep creating injection frameworks with ideas ported from Java and posting them on /r/golang, but they don't go anywhere because they have nowhere near enough utility to become self-sustaining. There's a pattern more useful than an injection framework that I often use: http://www.jerf.org/iri/post/2929 (For the purposes of this conversation, I highlight the part of that post that comes after "But Go does have two attributes that make it easier than many other imperative languages.")
Go has a much lower paperwork load than Java. Superficially, on paper, they seem like very similar languages. In practice, I find using Go to be only slightly more painful than Perl or Python, with the pain generally paying me back on the order of single-digit days anyhow (when I start doing aggressive unit-testing-backed refactorings that are unsafe in scripting languages). It isn't anywhere near as paperwork-ridden as Java.
(That's probably why I've come to grips with the lack of generics. Yes, it causes me pain, but it comes up less than you think, and in general the rest of the language is still pretty slick. It's not like it's as complicated and paperwork-ridden as Java, and then they took away generics.)