"Stateless" does not seem as strong as "pure", and purity is what I'm after. What about an iterator that maintains no state but prints to the screen? You could describe it as a "stateless", but not as "pure".
Your post does show that iterators are somewhat of a leaky abstraction, but I'm not sure I would go as far as calling some of their infelicities "bugs". Whether those infelicities matter in practice is a moot point.
I don't think any reasonable member of the Go community would claim that any aspect of the language and its standard library is perfect. The many open issues on https://github.com/golang/go attest to that.
One example, if I may: the errors.As function is far from ergonomic. It would have been much better if generics had come to the language before that function was added to the standard library. Modern alternatives exist: https://pkg.go.dev/github.com/jub0bs/errutil
I agree with those points but I don't think they mean that we shouldn't be promoting that header as a common solution.
> Server bound to an inaccessible network interface
This is a niche use case. Most sites don't have this problem.
> Distributed client-side brute-force attack against login
This is pretty easy to solve by adding checks on your login endpoint. But really you should have more robust solutions against login rate limit whether or not they can be triggered by clients on different sites.
I’ve just released jub0bs/cors, a new CORS middleware library for Go, perhaps the best one yet. It has some advantages over the more popular rs/cors library, including a simpler API, better documentation, extensive configuration validation, a useful debug mode, stronger performance guarantees.
Functional options is a creational pattern that remains divisive in the Go community: loved by some, loathed by others. However, the pattern can tremendously improve a library’s API design. Throw in a few twists and unleash the full power of functional options on your Go libraries!
(Talk given by Julien Cretel at GopherCon Europe 2023)
