Паттерн Конкурентного генератора в Go: Наглядное руководство

[Kuzuru]

Зачем это нужно, если в Go уже существуют нативные генераторы, в том числе и обобщенные (Generic)?

Не хочу задеть этим комментарием автора, но, по своей сути, изобретаем велосипед заново?

Или как их ещё называют range functions, которые в своей имплементации ничем не отличаются от представленного в статье примера

Взять то же самое семейство Seq0 из пакета iter:

type Seq[V any] func(yield func(V) bool)

Который можно использовать аналогично:

import "iter"

func GenerateNumbers() iter.Seq[int] {
  return func(yield func(int) bool) {
    someNumbers := []int{1, 2, 3}
    for _, v := range someNumbers {
      if !yield(v) {
          return
      }
    }
  }
}

И использовать их аналогично в for-range

[northartbar]

Я не берусь отвечать за автора, но выскажу своё мнение. В статье речь идёт о конкурентном паттерне “Генератор”, который знакомит с концепцией, лежащей в основе многих реализаций.

Автор предлагает конкретную реализацию, странно сравнивать паттерн и конкретный механизм (iter.Seq). Это похоже на спор о курице и яйце: iter.Seq — лишь одна из возможных реализаций генератора коих тьма.

Не совсем ясен поинт про “изобретение велосипеда”. Паттерн “Генератор” появился задолго до iter.Seq, так что сравнивать их напрямую некорректно.

На мой взгляд, в статье элегантно показано, как обычный генератор становится ленивым за счёт блокировок канала. Это и есть ключевая идея: канал сам регулирует поток данных, что естественным образом реализует ленивость и конкурентность одновременно.

iter.Seq, в отличие от этого подхода, не работает с конкурентностью — это просто ленивый итератор, но он не управляет параллельностью. Поэтому в контексте статьи он не заменяет, а лишь демонстрирует другой подход.

Цикл статей “Мастерство конкурентности в Go” посвящён именно конкурентному программированию, а iter.Seq из коробки не использует горутины и каналы.

Также непонятно, как с import "iter" можно построить конкурентный пайплайн. Генерация данных — это одно, но обработка последовательностей в параллельных потоках требует дополнительных решений, которые и раскрываются в статье.

[Kuzuru]

Понял вас. Возможно, я поспешил с выводами. Постараюсь чуть более глубже поисследовать эту тему. Спасибо за подробный ответ и понимание!