"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’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)
I hoped the TL;DR item entitled "SameSite paints a target on your subdomains' back" would be enough to compel readers to get through the whole post... But I understand your criticism; the post is quite long...
By the way, one of the takeaways in the post is that even SameSite=Strict is powerless against (cross-origin) same-site attacks. I would certainly recommend using Strict wherever possible and practical, but Strict shouldn't be misconstrued as a drop-in replacement for anti-CSRF tokens.
AFAIK, there is no proposal to add a type of DNS record that would allow you to do that. And I don't think that this type of configuration should be done at the DNS level rather that at the HTTP one.
[...] for domains such as .co.jp or .github.io, just using the TLD of .jp or .io is not granular enough to identify the "site". And there is no way to algorithmically determine the level of registrable domains for a particular TLD. That's why a list of "effective TLDs"(eTLDs) was created.
If foo.github.io and bar.github.io were considered same-site, one subdomain could mount cross-origin same-site attacks against the other. I'm guessing that's why companies that have multiple tenants on the same domain (github.io, in this case) ask that the domain be added to the public-suffix list: for isolation purposes. Other examples of public suffixes are azurewebsites.net (Azure App Services) and repl.co (Repl.it).
You'd be surprised by how many organizations completely disregard the security of their non-essential subdomains. The point of my post is that one subdomain takeover (or some XSS or some HTML injection) on a different subdomain of the same site is enough to bypass the protection that SameSite provides to the origin of interest. And I feel that is something worth understanding well.