In that case, the fault lies with the thing that put unrelated functions together and passed them to a thing expecting them to be related. I'm not claiming that structural typing will somehow prevent programmers from deliberately writing wrong things, because I mean, what type system can make that promise? My point is that it is in my experience very rare for something expecting "something that can write bytes" to be accidentally passed "something that can write novels" or something equally unrelated, and then the world blows up in a bad way (that is, not just an exception thrown, because that's just a risk of dynamic languages, but actual bad things happening).

Dynamic languages can at least still get what I said wrong; in Go it's even harder because as others have pointed out, Write([]byte) and Write(NovelInput) Novel still can't cross. But even in dynamic languages, this isn't a problem I had.

    func receiver(next func() bool, getItem func() Foo) {}

    type FooIter interface { Next() bool; Item() Foo }

    func receiver(iter FooIter) {}

Any interface can be implemented by something that's accidentally (or intentionally) stateful - there's nothing that prevents that in Go. And a interface containing more than one function almost certainly has an implicit relationship between those functions that an implementation could accidentally violate.

> and accidentally implementing an interface is itself vanishingly rare (I don't think I've ever heard of this happening in practice).

Accidentally implementing an interface must happen all the time - not in the sense of unrelated functions having a name collision, but in the sense of implementing a type that looks like another type and not explicitly looking through all the interfaces that other type implements and what expectations they carry.

> It doesn't make sense to me to take grievance with Go's interfaces (which offer strictly stronger protections than callbacks), but be okay with naked callbacks on the basis that "people tend not to use them in a stateful manner" (never mind the stateless scenario in which bare callbacks also provide weaker guarantees than Go's interfaces).

Naked callbacks make it clear what the expectation is and where the responsibility lies. It's the same as the idea that bad encryption is worse than no encryption at all, or a datastructure that is "mostly threadsafe" is worse than one that immediately errors when used from multiple threads.