I disagree that using channels is necessary for concurrency. Consider the following iterator based signature for your Map function:
func Map[A, B any](in iter.Seq[Try[A]], n int, f func(A) (B, error)) iter.Seq[Try[B]]Channels are many-to-many; many goroutines can write to it simultaneously, as well as read from it. This library is pitched right at where people are using this, so it's rather a key feature. An iterator is not. Even if you wrap an iterator around a channel you're still losing features that channels have, such as, channels can also participate in select calls, which has varying uses on the read and write sides, but are both useful for a variety of use cases that iterators are not generally used for.
They may not be "necessary" for concurrency but given the various primitives available they're the clear choice in this situation. They do everything an iterator does, plus some stuff. The only disadvantage is that their operations are relatively expensive, but as, again, we are already in a concurrency context, that is already a consideration in play.
The ability to participate in select statements is a good call out. Thanks for taking the time to reply.
that makes Scala look easy.
For context, here's the existing Map signature from the linked library:
func Map[A, B any](in <-chan Try[A], n int, f func(A) (B, error)) <-chan Try[B]
No, it was more of a general comment that once Go added support for generics, doing functional style programming starts to look as complex (or more actually) than languages that built support from the beginning.
Which part of the signature are you struggling with? Maybe I can help you understand.