You’re absolutely right. People advocating for it can’t seem to see beyond their nose.

Yes, the person who spent 15 years developing the Go language can't see beyond his nose.

More likely they're trying to solve real problems you just haven't hit yet.

The go team has explicitly said this is the past: “You just don’t understand because you’re not at Google’s scale.”

Where have they said this specifically?

What language change are you talking about? This is just a proposed construct to regularise and make efficient something people already do (as you says with “state”).

I’ve used iterators similar to what’s described in this article to avoid allocations in critical code paths, but this would make those much less awkward to use (particularly with the upcoming range iterator language change).

Perhaps language change was bad wording, I guess I meant paradigm change encouraging? Just look at this func signature and first line...

> func Pull[V any](push func(yield func(V) bool)) (pull func() (V, bool), stop func()) {

> copush := func(more bool, yield func(V) bool) V {

The main power of Go to me was always quickly being able to read and understand code. This type of coding has a lot of cognitive load to a reader, I feel.

The implementation of Pull may be a bit mysterious to the casual reader, but its usage seems clear enough to me from the function signature. Even without reading the docs I think it’s easy to guess what yield, pull, and stop should do (and how to implement yield). That’s what matters, imo.

Fwiw if you look at the source of some other idiomatic standard library functions you may find their implementation is of similar complexity. That’s the nature of good abstractions, though, they should make tricky things easy to use.

A dozen different incompatible iterator implementations (the current stdlib) isn't easier.

Channels are slow for no good reason when they aren't wrapping blocking operations.