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

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

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

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

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

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

dev notes | golang digest