I have thought before that if Java's interfaces worked like Go's did, with implicit satisfaction instead of having to declare explicitly, that there would proba

I have thought before that if Java's interfaces worked like Go's did, with implicit satisfaction instead of having to declare explicitly, that there would probably be no Go. If I could go back and change one thing about Java, that's what it would be. I know there's other more obvious pain points that most people would pick, but I think this is a subtle one that undergirds several of the more obvious ones. (To be clear, I am aware that Go and Java still have differences beyond that; my claim is that with this change Java would have been "good enough" that Go either never would have been spec'd or it never would have gotten any traction if it was. Java, however, has left a significant window open for Go because it has gained traction.) The problem with the way Java does it is that it forces a temporal dependency between interface and implementation, all to avoid a programmer error which on average will happen less than once per programmer career: http://www.jerf.org/iri/post/2954 http://www.jerf.org/iri/post/2954 This causes a lot of gyrations to be necessary to use them properly, which starts introducing the desire for heavyweight ways of autogenerating this, etc. and roll around that cycle a few times and that's how you end up with as much XML as code in your codebase. I think Java and Go are a really interesting case study for people interested in programming languages, because on paper they are virtually identical languages (especially if you ignore channels and select in Go), and it gives a clean demonstration of how even those not-very-large differences end up having a profound effect on how solving problems in those languages are best done.