"I feel like writing about the Go programming language (or 'Golang') today, so instead today's topic is computer stuff. For the record, the language I've programmed the most in has been Python, so that’s the perspective I'm analyzing it from." Some good and bad things about Go.

"Um... I haven't given any personal preferences. I'm just defending Go because someone has to in order for a debate to occur."

So you are playing devil's advocate then? I certainly didn't get that impression, but ok.

"On the note of optional interface implementation. Is that really very different from just adding a comment?"

It's very different. It's like adding a comment to say the variable is a double precision float point versus an explicit declaration of a variable as double floating point which the compiler can enforce. In contract based team programing, it's often beneficial to *explicitly* declare the intention of a class to implement something and have the compiler strictly enforce it. Comments are not meaningful in contract based programming.

"Sure the compiler does stuff (like tell you that you need method X) but you'd run into issues anyways if you tried to use an object that didn't actually support the interface. And I'm pretty sure the error message would still make it clear what the problem is (object Y is not a Z.)"

It's logically better to throw the error at the point where the class is defined rather than where the object of a class gets used. You might think this is nitpicking, but in contract based programming it can be significant because the interface provider and consumers might be different developers from different companies in different timezones. For the consumer to get the interface implementation error when the provider is the one that needs to fix it is not helpful.

Of course you can blame the provider for not testing it (dang it why didn't the comment work?), but keep in mind that languages with explicit interface declarations have built in test cases for this such that the producer will get an error during compilation.

Edit: I wouldn't go as far as to say everyone needs explicit interfaces. In small/home projects, it probably wouldn't come up as often, but for large enterprise projects with hundreds of classes and code paths belonging to rarely used corner cases, it's probably best for developers to be able to explicitly state their intention - especially since they come and go over the course of the project. I think adding optional support for them would be a very good idea to please people of both crowds.

It's not quite devil's advocate. I like Go. The issues that have been brought up aren't actually issues when you start using Go. I've been trying to explain why that is, but I don't seem to be making any progress (then again Go isn't my #1 language; so it's a bit like me trying to explain why German capitalizes all nouns (English is my first language if that wasn't obvious.)) It may just be one of those things you have to try to understand why, but that's unfortunate since those I've been debating with are unlikely to try Go because they are hung up on a minor issue (that doesn't really exist.)

It's not quite the same as your floating point example. It would be more like if the declaration is guaranteed to be a double, but you declare it as one anyways.

In your second example, I could imagine that being an issue. However, the same sort of issue occurs if the provider explicitly labels the object but doesn't include one you want (that the object does support.)

So better then optional would be "guarantee signatures." Which would say "this object MUST implement x, y, and z; but it may implement any others that the object has the right signature for"