ПРИМЕЧАНИЕ: Этот пост первоначально появился на мой блог
За мой чуть более чем годовой повседневный опыт работы с Go в качестве разработчика я до сих пор научился трем вещам :
- Я могу полностью изменить свое представление о том, как работает программирование, даже после более чем 12 лет занятий им в той или иной форме.
- Люди обвиняют Java по всем неправильным причинам
- Люди хвалят Go по совершенно неправильным причинам
Позвольте мне объяснить. Этот пост не о том, чтобы сказать, что “язык A лучше, чем язык B”, или наоборот. Речь идет о том, чтобы задать себе вопрос, почему вещи работают так, как они работают, и является ли их изменение плохим или потенциально хорошим поступком.
До прихода в Go camp я довольно много лет проработал разработчиком Java со всеми стереотипами, которые эта роль могла вызвать в чьей-либо голове. Я участвовал в разработке систем обработки данных для различных отраслей промышленности. Тем не менее, большая часть кода, который я написал, была просто шаблонной: передача данных из одного формата в другой или разработка сложных абстракций, лежащих в основе того, что на самом деле должно было быть просто вызовом функции и получением ее результата. Да, код был труден для понимания, но я гордился им именно по этой причине. Чем больше обручей я создавал, тем увереннее я чувствовал, что:
- Я делал то, что считал правильным
- Если бы люди не понимали код, им пришлось бы обратиться ко мне за советом, что еще больше повысило бы мое эго.
Язык в этом не виноват
Тот факт, что большая часть существующего кода Java полна бюрократии, не имеет ничего общего ни с самим языком, ни с его платформой. Наше сообщество разработчиков должно нести исключительную ответственность. Я могу заверить любого, что идеально функционирующие Java-приложения могут быть написаны без 90% церемоний. Они будут меньше и будут работать быстрее. Скорее всего, это тоже легче понять. И все же они не возьмут вас на работу ни в одну уважаемую компанию. Они просто не пройдут тест предубеждение разработчика . Я знаю. Я видел много элегантных решений и отверг их за то, что они недостаточно/идиоматичны/.
Go тоже не является серебряной пулей
По большей части по тем же соображениям, переход с корабля на Go только потому, что “это не Java”, никого далеко не заведет. Еще до того, как я начал писать Go, я слышал и читал много историй о том, как просто и быстро он все делает, как мало в нем церемоний по сравнению с Java, как он в конечном итоге убьет все другие языки и т.д. Все это бла-бла-бла. Несмотря на то, что все вышесказанное верно, вы должны сами открыть истину в каждом из них. Если вы подходите к языку из отчаяния с вашим нынешним способом работы, вы будете настроены на трудный путь.
Видите ли, если бы все, чего вы хотели, – это ускорить работу (язык названия по выбору), вы, безусловно, могли бы это сделать. Тем не менее, держаться за ментальный багаж вашего предыдущего опыта будет трудно и беспорядочно. Мой первый проект Go начинался как переписывание приложения Spring Boot, которое я начал ранее, поэтому я подумал, что просто организую его таким же образом. Короче говоря, давайте просто скажем, что это была впечатляющая катастрофа. Только после того, как я начал с нуля, это действительно начало набирать обороты.
Go – это язык без (с меньшим количеством) идиом
Давайте проведем наивный математический эксперимент. Представьте, что вы могли бы создавать допустимые программные выражения, комбинируя любые 3 ключевых слова из словаря языка программирования. Таким образом, если в языке всего 10 ключевых слов, максимальное количество возможных выражений равно 10 * 9 *. Напротив, язык, содержащий, скажем, 20 ключевых слов, в конечном итоге будет иметь 20 * 19 * выражений. Вдвое большее количество ключевых слов приведет к почти в 10 раз большему количеству выражений!
Языки, как правило, поощряют создание и использование идиом. При таком количестве возможных выражений это нормальное поведение для отдельного человека или группы людей – начинать ассоциировать и использовать выражения для определенных вещей. Проблемы обычно возникают, когда другая группа приходит со своим собственным способом выражения того же самого. И то, и другое совершенно справедливо, но у каждой группы будут проблемы с пониманием другой.
Это не значит, что Go, имеющий очень строгий и лаконичный характер, полностью лишен идиом. Это было бы невозможно. Это в нашей природе – пытаться ассоциировать и абстрагировать определенные понятия. Тем не менее, когда язык имеет намеренно меньший словарный запас, вероятность того, что разные группы случайно найдут несколько способов сделать одно и то же, меньше. Это очень помогает общению между людьми, но имеет очень очевидный недостаток. Код (или любое письменное выражение, если уж на то пошло) без идиом очень, очень многословен.
Итак, тот, кто сказал вам, что Go не является многословным языком, вероятно, либо намеренно солгал вам, либо на самом деле не видел никаких других языков программирования до этого момента. Но эй, мы же договорились, что многословие во имя общения и взаимопонимания – это на самом деле хорошо, верно? так что
Go – это тест для старших инженеров
Много было сказано о первоначальной концепции Go и о том, как идея заключалась в разработке языка для юниоров, только что окончивших колледж и не имеющих большого опыта программирования. Я думаю, что понимание красоты возвращения к истокам программирования может стать катарсическим опытом для многих опытных программистов.
Видите ли, младшие программисты начинают с небольшого багажа и предубеждений, поэтому, по их мнению, все, что можно сделать с кодом, справедливо и оправдано. В том числе, сжигание процессора или стирание диска из-за арифметической ошибки.
Где-то на середине карьерного пути начинает накапливаться куча принципов. Все они из желания опираться на то, что уже было изучено, и убедиться, что все идет гладко и безопасно без непосредственного надзора. Изучение и применение принципов – это здорово, потому что это обеспечивает постепенный путь вперед. Но для многих это становится догмой, которой они слепо придерживаются, не задаваясь вопросом, может ли быть лучше более простая альтернатива.
Проблема с принципами заключается в том, что они хорошо работают только в 80% случаев. Именно оставшиеся 20% могут иметь катастрофические последствия для проекта или для карьеры человека. Именно понимание того, где применять принцип, а где сознательно отбросить его во имя прагматизма, превращает инженера-программиста в старшего инженера-программиста.
Чтобы по-настоящему оценить Go, нужно научиться различать, что отличает его и его сообщество от остальных. Нужно пройти через фазу полного отвращения к языку, потому что ему “не хватает” определенной функции. Движение дальше, несмотря на желание вернуться на знакомую почву, привело бы к одной из двух вещей:
- Заставьте человека осознать, что на самом деле язык Go – это не то, что ему нужно или чего он хочет
- Научитесь ценить возвращение к истокам, а также когда отдавать предпочтение прагматизму, а не принципам
В любом случае, это был бы интересный опыт.
Оригинал: “https://dev.to/preslavrachev/reflecting-on-my-experience-with-go-one-year-after-nl8”