Здравствуйте, Pzz, Вы писали:

N>>Не логично. Логично или строго по порядку, или по явно прописанным приоритетам (я бы предпочёл схему, как в DNS SRV записях — есть priority и есть weight).

Pzz>Я бы предпочел схему, в которой рантайм выберет первый попавшийся удобный ему case, потому что это дешевле всего. Только народ прочухает, в каком порядке рантайм выбирает варианты, и начнет использовать это для приоритезации.

FYI, правильно — "приоритизация"

Pzz>И если потом в рантайме алгоритм выбора варианта изменится, куча кода сломается. Поэтому они, назло всем, сделали случайный выбор.

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

N>>И ещё обязательно должна быть возможность таймаута. Её сейчас тоже нет.
Pzz>Просто добавляем в select case, в который таймер тикает. Это ничем не хуже какого-то отдельного механизма для таймаута.

Хуже. Делать отдельную горутину для таймера... я понимаю, что они дешёвые, но это всё равно костыль.
Заметь, в Erlang таймеры — отдельные процессы, но receive всё равно имеет вариант after.