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

Что вообще такое - “путь языка Х”?

Во многих программерских сообществах развивается некоторое чутье на то, соответствует ли код или решение “пути” этого языка. Сложно сказать, почему и как это возникло, но сегодня это довольно распространено. Причем, по моим наблюдениям, чем дальше этот язык от “cutting edge” технологического мира, тем меньше в нем разногласий по этому поводу.

Сама идея того, что у языка есть некий “путь”, и что разные решения одной и той же задачи могут в большей или меньшей степени соответствовать этому пути, не нова. Уверен, что подобные дискуссии имели место и пятьдесят лет назад, а то и раньше. Но с возникновением современных языков с высоким уровнем абстракции эта тема всколыхнула умы с новой силой.

В целом это все есть идиоматика языка - набор стилистических шаблонов и лучших практик, поддерживаемых сообществом. Плюсы у этого явления, конечно же, есть. Понятия о идиоматике позволяют писать более единообразный код - а значит, более легкий в поддержке. Кроме того, эти понятия со временем формируют некоторое “чувство хорошего тона”, которое подсознательно подсказывает программисту как лучше решить ту или иную задачу, используя средства языка с максимальной выгодой.

Но и без минусов не обошлось.

А что там у соседей?

Впервые с подобным понятием я столкнулся в языке Python. На зависть другим, Python имеет встроенное описание лучших практик - документы PEP 8 и PEP 20 - где описана идеология языка и практические указания по оформлению кода. Лично я с большим теплом отношусь к Python именно из-за этого: подобные правила позволяют раз и навсегда прекратить распри с другими разработчиками из-за эфемерных, но при этом раздражающих вещей. Более того, можно написать линтер на предмет соответствия этим правилам и требовать придерживаться ему на проекте. Красота!

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

Как дела обстоят в Go?

Golang - довольно уникальный язык. С одной стороны, он наследует множество низкоуровневых конструкций из C, приправляя их простой работой со строками и массивами переменной длины. С другой стороны, Go - достаточно высокоуровневый язык, который позволяет разрабатывать сложное ПО просто, и без необходимости изучать синтаксис на протяжении нескольких лет. С третьей стороны, язык из коробки дает удивительно удобную работу с конкурентными задачами, и набор очень полезных инструментов для этого. Конечно, все это уже где-то встречается, но ни в одном языке нет всего этого сразу.

Такой интересный набор порождает уникальные подходы к разработке в целом и написанию кода в частности. Не зря новичков, пришедших из других языков, часто критикуют за применение чужеродных подходов из своего опыта там, где они неуместны. Это все хорошо понятно, и наблюдается и в других языках. Но что же предлагается взамен?

Каков же путь Go?

Здесь узкое место состоит в том, что тема соответствия “Go Way” обсуждается в сообществе достаточно часто, но при этом сами понятия об этом самом “Go Way” крайне размыты.

Я общался со многими людьми на предмет того, как же правильно писать на Go, и не один их них не смог дать мне четко сформулированного ответа. Единственное, что было общим - “не так, как это привыкли делать в других языках”. Ну ок.

В целом, некий свод лучших практик, конечно же, есть. Но он очень сильно размазан между сайтом golang.org, статьями Дейва Чейни, несколькими опенсорс проектами на гитхабе, предлагающих стандартизацию подхода к тому или иному вопросу, и множество отдельных статей в блогах известных (и не очень) программистов. В итоге тяжело вообще понять, когда описанное можно считать хорошей практикой, а когда, личным мнением автора, который в попытке создания сложного ПО уже перешел на новую ступень ментального развития и потерял связь с реальностью. Нет единого и лаконичного свода правил о том, как стоит и не стоит делать, как лучше решать те или иные задачи, и о том, в чем вообще заключаются принципы и каковы основы “Go Way”.

А в чем проблема?

Проблема в том, что из-за нечетких понятий о идиоматике языка сообщество Go разработчиков наполняется токсичностью и негативом. У каждого в голове собственное понимание о том, как “правильно в Go”, а многие не стесняются учить других без приглашения. Любое утверждение или аргумент в споре бывает сложно либо невозможно подтвердить или опровергнуть, сославшись на какой-то авторитетный источник, потому что источники эти размазаны по всему юзернету в статьях в блогах и видео с конференций. В принципе, это все не так уж плохо, но хотелось бы нормально.

Как теперь жить?

Go - молодой язык (хоть он и берет корни из древнего Alef). Только недавно ему исполнилось 10 лет - а это очень мало рядом с такими мастодонтами, как C, Python или даже Java. Сообщество тоже молодое и активно развиваются, и многие инструменты только появляются - буквально недавно Go обзавелся встроенным инструментом для управления пакетными зависимостями (go mod). Я думаю, что в какой-то момент количество разрозненных материалов про лучшие практики в Go перейдет некоторую критическую точку, и они начнут оформляться в структурированный набор лучших практик, поддерживаемых ключевыми фигурами в сообществе. И что после этого не нужно будет вновь ломать копья о понятиях Go-way’ности того или иного подхода, а можно будет просто указать собеседнику на пункт в официальном документе.

Это могло прозвучать немного токсично или самоуверенно, но от подобных ограничений выигрывает все сообщество. Подобные вещи позволяют ввести статические проверки качества кода и соответствия ему общепринятым практикам (что уже сделано в Go в начальной стадии через go fmt). Такие проверки и единый источник правды позволят программистам более не тратить усилия в попытках писать “более идиоматический код”, а оставить это на откуп линтеру и больше внимания уделить решению своих повседневных задач.

UPD 04.01:

Dave Cheney добавил Zen of Go по аналогии с Zen of Python. Вместе с Go Proverbs это составляет некую точку бифуркации в процессе формирования явного предстовления о лучших практиках языка.