Как я уже как-то упоминал, я веду небольшой канал с дайджестом статей, материалов и новостей из мира Go - @digest_golang. И вот в процессе подготовки материалов, наткнулся на интересную заметку, которой хочу поделиться: https://antonz.org/go-map-shrink/

Автор рассказывает о том, как сборщик мусора работает с базовым типом map. Если кратко, то все зависит от того, сколько места занимает тип, который хранится в map.
* Если тип занимает < 128B, и мы храним его без указателя, то Go не освобождает выделенную память даже после того, как мы явно удаляем все элементы в мапе:

type Client struct {
    id   uint64
    body [40]byte
}

...

m := make(map[int]Client)
for i := range 10000 {
    m[i] = Client{id: uint64(i)}
}

runtime.GC()
printAlloc("after create")

for i := range 10000 {
    delete(m, i)
}

runtime.GC()
printAlloc("after delete")

Вывод:

initial: heap size = 47 KB
after create: heap size = 1073 KB
after delete: heap size = 1073 KB

* в случае, если размер типа, сохраняемого в map больше, чем 128B, Go автоматически сохраняет его через указатели на куче, и после явного удаления память будет освобождена:

type Client struct {
    id   uint64
    body [1024]byte
}

// the same logic

Вывод:

initial: heap size = 42 KB
after create: heap size = 11581 KB
after delete: heap size = 331 KB

В случае, если вес структуры <128B, то можно явно сохранять в мапе все значения через указатели, и тогда место будет освобождаться.
Иначе, в примере выше порядка 1Mb памяти останется не убранной, что в случае сложной многопоточной логики может значительно увеличить количество потребляемых ресурсов и это стоит держать в голове. Плюс, эти знания могут пригодиться на собесе 🙂

Недавно выше я писал, что собираюсь подготовиться и попробовать пройти в американский или европейский бигтех.

Итак, что было сделано за первые 3 месяца этого года:
1. Прошел курс по system design от balun-cources.
Курс, в целом, неплохой. Очень много теории и практика под конец. Теория полезная, частично пересекающаяся с "Высоконагруженными приложениями"" Клеппмана, но с объяснением на кейсах из реальной жизни. В целом - курс стоит своих денег, хотя лично у меня изначальные ожидания были несколько выше. В любом случае, база получена, осталось попрактиковаться в изученных паттернах как на собесах, так и в реальной работе.

2. Начал проходить курс по алгосам от Влада Тена. С моим темпом прохождения и количеством свободного времени - думаю эта история затянется надолго, но я и не тороплюсь. Зачем вообще нужен курс по алгосам? Лично мне - для дисциплины. Решать задачки проходя курс мне сильно проще, в ином случае я просто забью на середине. А тут за меня уже кто-то продумал структуру задач, объяснил теорию и оформил все это в удобном виде.

3. Английский. Вот этого было действительно много. Зафиналил спринт на 30 занятий на lingoda, и параллельно 3 раза в неделю занимаюсь с нейтивом. Еще для себя обнаружил, что уровень сильно растет вверх от просмотра контента на английском, поэтому каждый день теперь смотрю какие-нибудь сериалы или видосы. В целом - становится лучше, надеюсь в таком же режиме довести его до конца года до того, чтобы проходить/проводить собесы на английском.

Еще из интересного - сходил тут, недавно, на собес. Я почти 2 года работаю в одной компании, пока не планирую ее менять и все эти два года не выходил на рынок. А тут меня позвали и я подумал - почему бы и да, и решил попробовать. Компания - большая, занимается мобильными играми и занимается этим лучше всех в Европе. Но с собесом у ребят, как по мне, большие проблемы.
Мне дали час времени, за который сначала попросили решить задачу, затем провести код ревью строк на 250, а затем написать кусок кода с довольно сложной конкурентной логикой. Задачи - в целом ок, но вот лимит по времени в час - это, конечно, сильно 🙂 За час я успел сделать все 3 задачи, но все 3 - не полностью, особенно код-ревью.
Для себя тут сделал вывод, что буду чаще ходить на собесы, чтобы понимать как сейчас дела на рынке и что там спрашивают.

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

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

Спойлер - они действительно упростили жизнь и где-то даже позволили оптимизировать потребление ресурсов. Я решил выделить паттерны их использования, которые мне показались удобными, и получилась новая статья - https://poltora.dev/iterators-in-go-ru/

Велкоме.

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

И я давно думал, что было бы очень круто, если бы была возможность объединить простоту и удобство генерации кода через LLM, доступное в Cursor и все фишки neovim, большинство из которых невозможно настроить в Cursor через сторонние плагины.

И как оказалось, такие проекты есть!
Я попробовал два самых популярных:
- https://github.com/yetone/avante.nvim
- https://github.com/olimorris/codecompanion.nvim

avante - самый популярный и имеет наибольшое количество звезд и контрибьюторов, но лично у меня он очень часто и много стрелял багами. Мягко говоря, ему далеко до генерации кода как в Cursor, хотя проект очень интересный и очень надеюсь, что его продолжат развивать.
А вот codecompanion мне понравился. В интеграции с моделями от anthropic качество кода, которое он генерирует - довольно неплохое, и количество багов в процессе работы сильно меньше, чем у avante.

Планирую в ближайшее время взять какую-нибудь более-менее реальную задачу и какой-нибудь проект с небольшим количеством контекста, и сравнить эти плагины на разных моделях (а заодно и chat-плагин для github copilot - https://github.com/CopilotC-Nvim/CopilotChat.nvim, он менее популярен и тоже имеет не мало багов судя по отзывам, но выглядит многообещающе, поэтому его тоже стоит попробовать).

Решил зачелленджить разработку через LLM и реализовать один пет-проект полностью через cursor, и сделал пару интересных выводов.

- Есть такая область разработки - написание парсеров. Я знаю нескольких людей, которые буквально весь свой доход аккумулируют этим занятием, благо на биржах до сих пор множество заказов на парсер того или иного ресурса. Так вот cursor написал мне парсер за несколько часов и пару итераций, который я сам писал бы несколько дней, а-то и неделю.
Алгоритм оказался максимально простым: я сбросил модели ссылку на ресурс, модель сделала curl, получила исходный код, и описала регулярки под все необходимые мне данные, которые мне оставалось только немного подтюнить.
- Оно как бы и очевидно, но убедился лично - если попросить cursor подумать о чем-то, что не связано с кодовой базой, которая в нем открыта - он сделает это сильно хуже, чем gpt4/5. Например, окончив очередную итерацию и убедившись, что часть фукнционала работает - я решил его задеплоить, и попросил проанализировать, где мне лучше это сделать, учитывая специфику проекта и мои лимиты по стоимости. Cursor выдал какую-то дичь, и спустя несколько промптов и вагон контекста так и не смог найти нужной информации. GPT-5 даже без контекста и понимания кодовой базы ищет и аккумулирует такую информацию сильно лучше. По-итогу я пришел к тому, что треть запросов я ищу/собираю через gpt-5, обычно в нескольких чатах внутри отдельного проекта, а всю работу с кодом делаю через cursor.

В целом, по итогам недели работы с LLM по вечерам, я написал кода столько, сколько сам бы писал в том же режиме недели 2-3. Но, несмотря на сильное ускорение, надо быть в контексте всего проекта и постоянно проверять логику - часто модель делает что-то или не оптимально, или неправильно, и в некоторых местах ее нужно поправлять.

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

Пока искал и отбирал статьи для 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 - велкоме, будем рады.
Разработчика определяют его навыки, а не количество лет в резюме.