Пока искал и отбирал статьи для t.me/digest_golang (подписывайтесь, кстати) - нашел полезное - доклад с GoLab 2025 от инженера Reddit с 10 паттернами, на которые он советует обращать внимание во время написания кода.
По названию похоже на типичную проходную статью с медиума с околонулевой ценностью, но по факту нахожу эти советы хорошими, и пару раз поймал себя на мысли что я часто указываю в ревью на те же ошибки, что описывает автор, но раньше не выделял их в отдельные паттерны.

Например:

Не дублируй логи - если ловим ошибку - мы ее или логируем, или возвращаем, но не оба сразу

Для код-ревью это хороший паттерн, потому как мысль-то вроде очевидная, но не всегда на это обращаешь внимание. Если где-то в MR на внутреннем уровне кто-то добавил лог, надо проверить, есть ли он на уровне выше. Если есть - удаляем.

Не добавляй интерфейс слишком рано

Я пришел к такому же выводу спустя несколько лет разработки на Go. Вообще, это напоминание другой базовой истины еще из "Чистого кода" - не делай преждевременных оптимизаций. Но, в индустрии во многих компаниях есть правило: любой тип должен быть с интерфейсом. По факту получается так, что в коде несколько сотен интерфейсов, а более одной реализации - у нескольких. Сначала стоит вернуть конкретный тип, а потом, если будет задача на расширение, всегда можно будет добавить интерфейс и реализовать его еще раз.

Сначала mutex, затем каналы

Каналы - это сложный механизм для синхронизации и взаимодействия горутин, и часто его использование слишком избыточно. Если появилась мысль добавить куда-то горутины или каналы, автор советует сделать так:
- сначала, если возможно, пишем синхронный код, решающий задачу
- если профилирование показывает, что это узкое место - добавляем горутины
- для синхронизации горутин sync.Mutex и sync.WaitGroup
- и только если профилирование показывает, что их недостаточно - вводим каналы

Проектировать код лучше без указателей

В Go очень часто возвращаемое значение из функций описывают следующим образом:

MyFunc() (*MyStruct, error)

с логичным намерением: если будет ошибка - мы возвращаем nil, err для удобства - не нужно писать MyStruct{}, err. Еще изредка можно услышать, что это делается для оптимизации.

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

Весь список с множеством полезных деталей можно прочитать тут - https://www.reddit.com/r/golang/comments/1oc5is8/writing_better_go_lessons_from_10_code_reviews/

dev notes | golang digest

Последнее время, рефлексируя над тем, как в нашу жизнь врываются LLM - мне все больше нравится идея постоянного обучения.

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

Если этого мало, то вот вторая причина. У поколения наших родителей была интересная опция: ты сначала учишься, получаешь специальность, а затем всю жизнь работаешь на выученной базе нарабатывая опыт. Сейчас же тебе нужно сначала учиться, затем нарабатывать опыт, а потом, если ты не хочешь терять в уровне жизни - делать еще один цикл обучения-наработки опыта, затем еще и еще. У меня так было со сменой стека: сначала это был PHP, затем потолок по зп -> период обучения -> смена стека на Go -> наработка опыта на нем. Это позволило мне вырасти по ЗП еще выше и выйти на зарубежный рынок.
Сейчас с приходом LLM я понимаю, что следующий этап обучения будет выглядеть как углубление текущих знаний и изучение новых языков.
Через 5-10 лет, вероятно, обучение будет или направлено на архитектуру приложений, или смещено в сторону менеджмента.

К вопросу углубления знаний - сейчас это кажется очень важным. Почему? Потому что на фоне у меня работает модель, которая генерит портянки кода и дефолтные crud'ы. Если кто-то делает тоже самое на работе - это можно заменить, вопрос лишь времени и интеграции модели в различные инструменты для сбора полного контекста, такие как jira и slack.
Но если задача, которую решает инженер - действительно сложная, например поиск какого-то бага (на этот счет есть отличное свежее расследование от cloudflare - там ребята искали и фиксили сложный баг в компиляторе arm64 под огромной нагрузкой) или проектирование архитектуры в действительно сложном контексте - вот это заменить будет тяжело.

Но когда-то же LLM научится решать и такие сложные задачи? Я думаю что сейчас единственная возможность заставить LLM работать с такими сложными задачами - очень строгая документация внутри проекта по очень строгим правилам. Например, 10 сервисов общаются между собой. У каждого должна быть дока с подробным и понятным (для модели) описанием того, что делает этот сервис, причем в очень строгом формате. Должны быть прописаны связи, по которым модель может ходить от сервиса к сервису и захватывать весь контекст, и все это должно работать с одними и теми же доменами. Иначе модели просто не хватит памяти и мощности, чтобы весь этот контекст впитать и держать актуальным. А теперь вспомним, сколько сервисов и связей в дейстительно больших проектах, не говоря уже о том, сколько там костылей, неожиданных взаимодействий и какая там документация. Большие компании в ближайшие годы не смогут переписать и документировать свои сервисы так, чтобы LLM решала в них действительно сложные задачи, но и перестанет нанимать инженеров, которые занимались рутинными действиями по перекладыванию ответов в базу и обратно.

dev notes | golang digest

Честно, я не подписан на этот канал и подписываться не собирался, но случайно увидел репост.
Автор канала - руководитель разработки в одном из подразделений сбера.
Судя по цитате - автор не умеет строить логические цепочки и вывод из них.
Судя по посту в целом - автор последний раз собеседовался и видел какая дичь с рынком - очень давно.

Как я всегда и везде говорю - не идите работать в конторы типа сбера, яндекса или вк, можно будет очень сильно пожалеть.
Например, какому-нибудь руководителю что-то в вас не понравится, и прямо в офисе вам будут светить лампой в лицо и устраивать допрос (можете поискать последние кейсы с rutube и газпромом)

p.s. Я работал в российском бигтехе и видел, какие бывают конченные собесы и какая там корреляция найма и того, насколько сотрудник эффективно работает.
p.s.s. Я не поддерживаю накрутку опыта и вкатунов, и так как сам веду собесы - отлично умею их ловить; но если кто-то действительно шарит, и добавил себе год опыта к двум имеющимся чтобы пройти абсолютно конченный фильтр на hh - велкоме, будем рады.
Разработчика определяют его навыки, а не количество лет в резюме.

Наверное, все уже видели новость про запуск grokipedia.com - аналога википедии от Маска, где все статьи пишет и валидирует Grok.

Думаю, что сейчас лучшее время для запуска такой платформы.

В волне бесоебства вокруг AI, где AI пихают туда, где он вообще не нужен, есть один точно верный тренд - автоматизация и суммаризация поиска. Люди все реже и реже ходят по ссылкам - сильно проще попросить ChatGPT найти информацию, провалидировать ее и выдать в сжатом виде. Даже Google в максимально короткие сроки, что удивительно для такой огромной машины, ввел авто-поиск и поставил его на первое место.
Например, по данным самой википедии человеческие просмотры страниц сократились на 8% год к году
Ресерч от Bain & Company показывает, что в среднем сейчас снижение переходов людьми по ссылкам - порядка 15-25% в целом по информационным ресурсам, так как все больше люди полагаются на выдачу AI.

Grokipedia 100% обгонит Wikipedia, воспользовавшись всеми ее знаниями и ее базой. Потому как читать огромную статью и перейти по 10 ссылкам в процессе, прочитав еще 10 - это долго, а найти, нажать кнопку и получить саммари - быстро.

Думаю, кстати, Wikipedia в ближайшее время добавит себе собственный AI, который будет делать похожие вещи или, хотя бы, сжимать смысл статьи по нажатию на одну кнопку.

dev notes | golang digest

К предыдущей теме про Go, аллокации и сбощик мусора.

Go дает нам легкость написания кода - нам не нужно думать о том, где будет лежать переменная - на стеке или на куче. Как я писал выше, тут есть очевидный минус - процессорное время. Чем сложнее структура данных, тем больше вероятность ее размещения на куче, и тем больше работы будет у garbage collector по сборке мусора.

Тут как раз вышла небольшая заметка от honeycomb по этой теме - https://www.honeycomb.io/blog/how-we-saved-70-cpu-60-memory-refinery
Ребята снизили процессорное время и затраты памяти почти в два раза, просто перестав анмаршалить весь blob в структуру, а разбирая только часть ее полей, и при этом заиспользовали низкоуровневое API tinylib/msgp, чтобы читать типы без аллокаций в памяти.
По-итогу подобная оптимизация позволяет сократить кластер нод почти в два раза без потери производительности.

Для очень хорошей оптимизации иногда не нужно внедрять сложные алгоритмы или параллелить нагрузку - достаточно открыть pprof и посмотреть, сколько аллокаций делает приложение и сколько потом работает GC, чтобы эти аллокации освободить :)

dev notes | golang digest

Пока копался во внутренностях Go и сравнивал его с Rust, нашел полезное.
Как известно, в Go фаза escape analysis решает, кто и куда будет аллоцирован - в кучу или на стек. Базовое правило простое: живешь в пределах функции - на стек, живешь дольше - на кучу.
И Go, как язык самостоятельный, иногда может решить аллоцировать на кучу то, что мы ожидали на стеке. Плюс в том, что Go сам умеет объяснять, почему он это сделал.

Достаточно запустить build с флагом -m:

go build -gcflags='-m' ./...

И компилятор выдаст подобный листинг:

./main.go:23:13: &user escapes to heap
./main.go:45:22: moved to heap: buf

Что это значит:

- escapes to heap - компилятор понял, что значение будет жить дольше функции и положил его в кучу - часто это происходит из-за того, что ты вернул указатель на локальную переменную или замкнул переменную в анонимную функцию:

func outer() func(int) int {
    local := 10
    return func(x int) int {
        return x * local // local уходит в кучу
    }
}

Иногда достаточно переписать сигнатуру или убрать лишний & - и аллокации исчезают, и это хороший способ выжать из Go больше перфоманса.

dev notes | golang digest

По итогам 3-х последних сообщений выше и моих разбирательств с тем, как Rust работает с памятью и чем это отличается от работы с памятью в Go - набросал небольшую статью.

Внутри разбор семплов процессора, анализ дампов программы на Go, сравнение ее с дампами программы на Rust и вывод, что работает быстрее, что надежнее, а что удобнее.

Велкоме - https://poltora.dev/rust-vs-go-memory-ru/

dev notes | golang digest