Go's crypto interfaces, in the standard library, don't hew to this "accept interfaces return structs" rule. NewAES, for instance, returns a cipher.Block.
It's in there in a footnote (click on one of the *):
> Of course there are subtleties that I am eliding. For example, context-sensitive code would benefit very much from taking interfaces and returning interfaces
Or to steal from Haskell's lexicon: when you do something in a monad.
Troll answer: but then where would people go if they want to show off their ability to talk in jargon like "applicatives", "arrow", "lenses"?
Serious answer: Not really. Monads are more abstract than just contexts. Monads are commonly used to represent context and contextual computation, but they can represent other things too.
I'd argue that there's no way to understand monads as a whole except by understanding the monadic laws. That is to say, I don't think there's some grand theory that unifies all monadic types. Rather, I think that certain types just happen to be monadic and, as a result, we can reason about and do certain things with those types that we can't do with other types.
What's the similarity between List, State, and IO? I'd argue that there is little similarity apart from the fact that we can define the monadic operations for all three. And, having defined those operations, we can then use more complex operations like `sequence`.
Monadic types sometimes represent data structures, sometimes represent contexts or, in the case of IO, sometimes represent nothing really at all. IO is arguably just a marker that imposes a linear sequence on what would otherwise be unsequenced computation.
In short: don't spend too much time trying to understand monads as a whole. Rather, try to understand why specific types, like List and State, happen to be monadic.
A lot of advice I've seen (such as this) postdates much of the standard library implementation by quite a bit. I could not, however, suggest that the current design for crypt is good or bad, for I have not used it often enough to offer a worthy opinion.
People seem to really click with the net/http design, and that does seem well done, but I imagine the standard library itself is a bit unevenly architected.
That's true, but the standard library also has strictures about backward compatibility that have ossified some bad choices. The crypto examples you give are arguably exactly this; even the later ones are probably a mistake, but are at least consistent with what can't be changed.
context.Context is an interface because it is known there are multiple implementers (several in the context package itself). The sql driver.Value is actually the other way around: the sql package is the consuming package (for the driver).
