Опыт применения Go в продакшене Яндекса

Я к тому, что и там и там они есть.

Эта проблема, безусловно, решается, но все-таки хотелось бы иметь продуманную полноценную стандартную библиотеку. Сейчас она хороша только пока вы работаете с сетью, в остальном складывается ощущение, будто написана довольно хаотично и «чтобы было». Если посмотреть tech talk об истории языка, то не возникает ощущения, будто над многими вещами там и правда заморачивались.

Сторонние библиотеки пока сыры и плохо документированы. Обычные библиотеки документированы лучше, но чаще всего приходится лезть в исходники, чтобы понять, как оно на самом деле работает (например, редко когда по документации можно понять, как разобрать ошибку из кортежа). Но это — теоритически — еще можно поправить. А вот чего нельзя поправить, так это то, что со своими структурами зачастую нельзя работать как с теми, что идут вместе с языком. Хороший пример — это итерация.

В Go 4 разных синтаксиса для определения цикла for. Если вы итерируете стандартный срез, массив или мэп, то все ок. Но вот использовать те же конструкции для своих структур уже вряд ли получится.

Давайте пример:

type TreeNode struct {
	Value interface{}
	Left  *TreeNode
	Right *TreeNode
}

type BinaryTree struct {
	Root *TreeNode
}

Думаю, понятно, что здесь происходит. Структуры определили, давайте теперь попробуем прицепить к ним методы, чтобы можно было делать вот так:

for node := range tree.InOrder() {
	fmt.Println(node)
}

for node := range tree.PreOrder() {
	fmt.Println(node)
}

Думаю, понятно, что здесь должно происходить. Так вот, так делать нельзя. Вы не можете использовать range таким образом. Приходится явным образом доставать итератор и итерировать его вот так:

iterator := tree.PreOrderIterator()
for iterator.HasNext() {
	fmt.Println(iterator.Extract())
}

Или функция make. Отличная функция, инициализирующая неявные структуры, с которыми работают срезы или словари. О, мы только что написали свою суперкрутую структуру, довольно сложную в инициализации, хочется создавать ее тем же образом, что и тот же словарь (например, написали свой Set). Ничего подобного сделать нельзя.

Поэтому со всеми бибилиотеками контейнеров не получится работать всеми средствами языка, инициализировать аналогичным с теми же срезами или картами образом не получится. И это только один пример. А ведь еще есть отсутствие генериков, принуждающее (!!!) копипастить, еще есть абсолютно наколеночный go get, про который во времена PyPI, Gem'ов или npm'ов вообще говорить стыдно.

Какое в Go стандартное средство для dependency management'а? Так ведь нет его фактически. Роб Пайк сказал, что им и этого хватает, пускай коммьюнити пишет. Комьюнити написало Godep, GPM, еще какие-то поделки есть. Но единого способа, единообразной экосистемы в Go просто не существует. Зато есть вот такой костылина.