They're really not. You still have to have someone pass your type into something expecting an interface. It's no different than passing a string into something expecting a path when you pass it an html document... at some point the programmer needs to decide if passing the value into the method makes sense.
In the canonical example:
type Boat interface {
Launch()
}
func LaunchBoat(b Boat) {
// do some boat stuff
b.Launch()
}
type NuclearMissile struct{}
func (nm NuclearMissile) Launch() {
// launch nuclear missile
}
func main() {
rocket := NuclearMissile{}
LaunchBoat(rocket)
}
Sure, this compiles, but the code doesn't make any sense. Lots of things compile, that doesn't mean the code makes sense. At some point it's the programmer's responsibility to think a little.
You still have to have someone pass your type into something expecting an interface.
Yes, that's generally the case with type-safety problems, even with the type-safety problem existing, it takes an actual programming error for it to become a problem -- and that is, indeed, the standard response of people saying type-safety isn't important (usually, though, its not a reason people would say something isn't a type-safety problem.) And its not completely invalid -- there is a reason that in a world dominated by static-typed languages with limiting type systems, dynamic languages like Ruby and Python that don't offer type safety but do offer a lot of flexibility that the type systems of C++/Java/etc. made, at best, cumbersome to acheive.
OTOH, if you are choosing a language with the extra ceremony involved in static typing, its kind of a big step back to not even get the level of safety with interfaces that you'd get with C#/Java, much less a more modern, expressive static type system.
Comments
They're really not. You still have to have someone pass your type into something expecting an interface. It's no different than passing a string into something expecting a path when you pass it an html document... at some point the programmer needs to decide if passing the value into the method makes sense.
In the canonical example:
Sure, this compiles, but the code doesn't make any sense. Lots of things compile, that doesn't mean the code makes sense. At some point it's the programmer's responsibility to think a little.Yes, that's generally the case with type-safety problems, even with the type-safety problem existing, it takes an actual programming error for it to become a problem -- and that is, indeed, the standard response of people saying type-safety isn't important (usually, though, its not a reason people would say something isn't a type-safety problem.) And its not completely invalid -- there is a reason that in a world dominated by static-typed languages with limiting type systems, dynamic languages like Ruby and Python that don't offer type safety but do offer a lot of flexibility that the type systems of C++/Java/etc. made, at best, cumbersome to acheive.
OTOH, if you are choosing a language with the extra ceremony involved in static typing, its kind of a big step back to not even get the level of safety with interfaces that you'd get with C#/Java, much less a more modern, expressive static type system.