DM>Хм, вот так у него выглядит map, который он почему-то даже не назвал map, что уже говорит о многом.
DM>

func Apply(slice, function interface{}) interface{}

DM>Но это же позор совершенный и нетипизированный. Как void* везде, только хуже и медленнее. Так жить нельзя. А хочешь типизированно — пиши императивные циклы. Эх.

Слово "map" уже занято под встроенный тип данных. Кстати, стандартная функция с именем "apply" и такой же семантикой существует в Лиспе, так что ничего нового Пайк не изобрёл.

Пустой интерфейс всё же не так плох, как void*, поскольку попытка вытащить из interface{} не тот тип приведёт к описанной в спецификации panic-ситуации, в отличие от UB в C. Производительность обсуждать без конкретных бенчмарков нельзя, да и нет смысла: пока что программы на Go исполняются в разы медленнее эквивалентных программ на C.

Что касается нетипизированности, то это следствие отсутствия в Go средств типизированного обобщённого программирования (generics). Это вспоминают чаще всего, критикуя Go, но на практике без дженериков можно прекрасно жить (например, генерируя код внешними средствами).

В связи с этим вспоминаю свою прошлую попытку спрыгнуть с C++ на более человеческий язык (это была Java). Ранняя Java тоже не имела дженериков, и ничего. Попытка получилась неудачной в связи с тем, что в Web-проекте, в который я попал, программировали больше на XML, чем на Java . Сейчас пробую перебежать в стан Go. Кстати, хайп вокруг Go часто сравнивают с первыми годами Java. И действительно, философии и свойства этих языков во многом схожи. Но Java уже прошла долгий путь, наделав много ошибок, которых пытается избежать Go.