Знакомство с Go, часть 2: пишем граббер изображений с балансировщиком и извращениями

[coocheenin]

Супер! Отдельное спасибо за пропорциональное содержание комментариев к коду (и наоборот).
Ну, и стиль повествования:) 5 дней с момента регистрации, а уже два полезнейших материала. Так держать!

[Xlab]

Если отбросить Go и требование «извращений», то в чём принципиальное преимущество перед моделью «пул воркеров + обычная очередь»?

[Stronix]

А если вместо балансировщика просто использовать буферизированный канал?

[Stronix]

как оповестить программу о том что достигнута последняя страница и ссылок больше не будет.

Можно закрыть канал. http://tour.golang.org/#66

[roman_kashitsyn]

Вот что мне не нравится в Go — так это необходимость писать кучу бойлерплейта при работе, например, с двоичной кучей. При реализации одной структуры данных нужно было три очереди с приоритетом с разными типами элементов, пришлось написать две страницы бесполезного кода. И так каждый раз. Либо писать свои обёртки с типонебезопасным интерфейсом.
Кстати, мне кажется, можно не проверять границы среза в Swap().

[RostislavDzinko]

Мы же, для простоты, дойдя до конца отправим в поток некую кодовую фразу, чтобы на другом конце поняли что пора закругляться.

Для простоты нужно закрывать канал.

Логично будет притормозить генератор, до тех пор пока не появится свободное место. Для этого предусмотрим в балансировщике реализацию технологии PMFC (Poor Man's Flow Control или «регулятор потока для бедных».

Достаточно создать буферизованный канал желаемого размера, в который генератор кладет урлы, а воркеры забирают.

Все остальное можно выкинуть за ненадобностью и эффективностью. И кода будет намного меньше, и работать эффективнее.

[baltazar_bz]

отчеты о процессе загрузки, продолжение с места окончания и прочие чисто технические и совсем не интересные для разбора в статье вещи

Ничего себе, неинтересные. Очень даже интересные! Маэстро, просим!
Ещё я бы с удовольствием почитал, как сделать из этого сервер/демон и прикрутить няшный веб-интерфейс на базе angular/bootstrap (или что там модно сейчас) с возможностью добавления новых заданий, просмотра прогресса и прочими поэтессами.

[Pyjamec]

А почему не использовали однонаправленные каналы? Любители Go утверждают, что так код получается читабельнее, видно намерение программиста. Вот, например, вопрос на стеке по поводу однонаправленных каналов — Stackoverflow

Еще хочу добавить, что слова «рабочий» очень режет текст статьи. Может проще написать задача или задание и переименовать структуру?

И еще одна ссылка на пример — Channels in Go