Небольшое введение: N месяцев назад я подумал переместиться в фуллстек. Вообще, идеи эти у меня существовали давно, но после выхода на рынок труда оформились в конкретные действия.

В node есть ряд вещей, которые меня несколько раздражают: - Сборка. Современный фронтенд достаточно сложная штука. В первую очередь, потому что требования к современному фронтенду развивались быстрее, чем браузеры. И фронтендерам приходилось эмулировать (читай, костылить) недостающие функции. Отсюда появились зоопарки инструментов: сборщики, полифиллы, библиотеки для реактивности, разного рода анимаций, стилизаций и прочее, и прочее… Эти требования породили мощные и гибкие сборщики, за мощность и гибкость которых приходится платить довольно трудоёмкой их настройкой. - Управление зависимостями. Из предыдущего пункта видно, что современный фронт очень… нет, ОЧЕНЬ зависим от пакетного менеджера. При этом, какой бы пакетный менеджер мы не выбрали, всегда получим огромный node_modules на сотни мегабайт с тысячами файлов, которые файловой системе банально переваривать тяжело. Транзитивные зависимости часто дублируют пакеты разных версий, а порой просто ломают сборку. Механизм громоздкий, неповоротливый, не оптимальный. - Инженерная культура. Извините, коллеги, но из-за того, что вход в программирование через фронтенд был в своё время самым простым, средняя инженерная культура во фронте это ппц. Чего стоит один только FSD, поднятый многими отечественными фронтендерами на знамёна как “лучшая архитектура фронтенда”. Во фронте много крутых программистов и отличных специалистов, но хватает и тех, кто с трудом понимает, что вообще происходит в крупном приложении и об архитектуре приложения слышал только краем уха. - Магия. Определённое, небольшое количество магии в коде я в целом люблю, но когда её становится слишком много, управлять ей становится непропорционально тяжело. Инструменты экосистемы js очень тяготеют к магии. Это, конечно, круто, что инструменты стремятся снять с разработчиков рутину по производству низкоуровневого кода, но на мой вкус магии стало слишком много. Я предпочитаю, когда у меня больше прямого контроля над кодом, пусть за это и придётся заплатить большим количеством ручной работы. - Огромный энтузиазм сообщества по поводу создания инструментов. На эту тему на самом деле давно шутят. «Каждую минуту появляется новый фреймволк на js» или игра на выпивание «Придумай случайное слово и если с таким словом уже есть библиотека на js, выпей». Говорят, с ней вечер кончается быстро…

Прикинув всё это к носу, я понял, что в бэкенде мне хотелось бы использовать другой стек. Самый большой спрос сейчас на go разрабов, поэтому в первую очередь я посмотрел именно на go. И мне очень нравится, честно говоря. В первую очередь, куча инструментов из коробки: единый пакетный менеджер, форматтер, тесты. Единый, унифицированный подход ко всему, это кайфово. Во вторых, утиная типизация интерфейсов классная штука. Очень удобно. Ну и, в третьих, у меня есть выбор между магией в коде и контролем. Я могу взять какой-нибудь beego или goframe с готовыми абстракциями над роутингом, orm и middleware, а могу взять gin или даже голый net/http, прикрутить gorm или выбрать sqlc и сам организовать необходимые мне абстракции и архитектуру. И при этом не сильно проиграть в скорости разработки. Реактивный front без react/vue/angular/svelte сейчас разрабатывать невозможно. По крайней мере без катастрофического падения скорости разработки. Для целей обучения go код я пишу без использования LLM генерации.

Я понимаю, что погружение в go у меня пока что куда меньше, чем во фронтенд и всё же сейчас для меня переход в go backend выглядит куда интереснее, чем дальнейшие попытки найти работу фронтендером. По двум причинам: С go мне реально приятнее работать. Потребность в backend разработчиках куда выше, чем во frontend. Позже расскажу, что же именно я пишу, а то тут уже лимит символов…

PS: панамку приготовил. Накидывайте критики, буде появится на то желание.