> 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.

Depends how you're using your types. E.g. one pattern I often use is wrapping up a String as a type so that I don't confuse two different domain-specific Strings - so I'll have something like:

public class PhoneNumber {
final String value;
}
public class EmailAddress {
final String value;
}

(In Scala this is even easier, with @@)

This is a really useful distinction to draw (in many ways it's more important than when the two types support different methods, because it's easier to get the two confused), and as far as I can see would be completely impossible 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.")

I really think this is more a difference of culture than language. If/when the same kind of corporate environments that created the market for Spring start coding in Go, then we'll start seeing such frameworks becoming popular.

Implementing the same kind of injection by multiply-inheriting in a traditional OO language isn't as crazy as that article seems to think - in fact, it's exactly how the cake pattern works in Scala.

> 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.

Again, I really think this is just culture. If you write Java the way you write Go - ignore the JavaBean conventions, don't abstract things that don't need to be abstracted - you end up with very similar code.