1375
Пишу про Go, Vim, и про то, как я медленно ползу в сторону FAANG. Веду @digest_golang С предложениями: @junsenpub
Нерегулярная рубрика - плагины для neovim.
Когда нужно посмотреть текущие изменения в ветке перед тем, как коммитить их - раньше я пользовался плагином https://github.com/sindrets/diffview.nvim, и он неплохо работает - слева дерево файлов, для которых были изменения, справа показывает два окна - с твоими правками и с состоянием ветки без последних изменений.
Из минусов - не самый очевидный diff: подсветка не всегда показывает что ты удалил, а что добавил - часто и слева и справа измененные строки подсвечиваются зеленым или красным, из-за чего тяжело сходу понять, где окно с твоими правками, а где без твоих изменений.
Из плюсов - поддерживает git-conflicts режим с 3-им окном, где отображаются финальные изменения.
На reddit заанонсили новый плагин - vscode-diff.nvim, попробовал - и это топ.
Очень похоже на diff в vscode, о чем и говорит автор. Самое приятное - из коробки без дополнительных плясок с конфигом все работает - пишем :CodeDiff, и смотрим на дерево файлов и на явно выделенные цветом изменения с синхронным скролом, кайф!
Плюсы - сильно лучше и понятней diff. Минусы - нет git-conflict режима ☔️, но очень надеюсь, что автор его добавит - по-крайней мере, на reddit он ответил что это возможно, и рассмотрит этот функционал в следующих версиях.
https://github.com/esmuellert/vscode-diff.nvim
dev notes | golang digest
Antigravity, который я хвалил выше, конечно крут, но будьте острожней: тут на реддите появился интересный пост - https://www.reddit.com/r/google_antigravity/comments/1p82or6/google_antigravity_just_deleted_the_contents_of/, где автор пишет как агент в процессе работы решил дропнуть файлы на локальном диске, и успешно это сделал, без запроса разрешения на это.
При этом, модель заметила:
Нет, вы совершенно не давали мне разрешения на это. Я просматриваю журналы с предыдущего шага и с ужасом вижу, что команда, которую я выполнил для очистки кэша проекта (moth r), по‑видимому, ошибочно указала на корень вашего диска D:, а не на конкретную папку проекта.
Я тут совершенно случайно у знакомого увидел, как он работает с LLM - через консоль. Реакция моя была по-началу - пфф, парень, ты многое теряешь, тебе нужно попробовать открыть редактор.
Затем я скачал copilot cli, попробовал сам и выяснил, что он ничего не теряет (кроме красивого diff над файлами).
Года полтора назад я уже пытался так играться с консольным copilot, и результат был мягко скажем так себе: интерфейс тулзы работал плохо, некоторые команды, которые поддерживались в редакторе - не поддерживались в cli, и в целом интерфейс не блистал анимацией и плавностью работы.
Сейчас это стало капец как удобно. Просто попробуйте, опыт мало чем отличается от забрасывания промптов в курсор или в антигравити. Чего нет - так это интерфейса с правками, но учитывая, что я использую neovim - это не проблема, diff можно отобразить разными плагинами.
В общем, в сетап вернулся neovim и все это встало поверх ghostty, в который сам того не заметив я мигрировал пару месяцев назад - они все-таки продали мне их аппаратное ускорение, оно реально ощущается.
dev notes | golang digest
Запилил за последние дни в antigraviti два проекта на абсолютно разном стеке: плагин для анки на python (о нем выше, но с тех пор я сильно его улучшил - скоро релизну ссылку на репу), идея которого лежала в заметках больше года), и еще один проектик, который помогает мне вести канал с дайджестом по Go - @digest_golang.
Вывод простой: LLM на текущем этапе открывают перед нами очень интересное окно возможностей, которым странно будет не воспользоваться.
Сейчас модели работают так, что их возможностей хватает для построения прототипов, но работают они еще не настолько хорошо и требуют от того, кто пишет в нее промпты каких-то знаний: за ней нужно убираться, нужно проверять архитектуру, которую она напилила.
Долго ли эти знания модели будут нужны? Может быть всегда, а может быть через год-два модели станут писать код лучше человека.
Но пока это не так - у нас есть отличная возможность быстро запускать продукты (из последнего - посмотрите на пример https://x.com/softwarevlogger
и его Summit AI Notes, который был запилен агентами от и до - https://x.com/softwarevlogger/status/1988703390302630159) и монетизировать их, чем я и решил активно заниматься ближайший год 🤨
Но чтобы не забыть на этом фоне как писать код - фоном для себя начал разрабатывать вещи, в которых давно хотел разобраться, сейчас вот пишу свой очень урезанный аналог sqlite - https://github.com/vpoltora/poltoradb
Пока тут только парсер, и тот без AST, но я его обязательно перепишу, как разберусь с транзакциями, индексами, WAL и разными приколами из реляционной алгебры.
И знаете, писать что-то для себя, потому что ты в целом любишь писать код - куда веселее, чем писать что-то, что написать нужно. А вот с тем, что нужно будут как раз помогать LLM 😎
dev notes | golang digest
Free Software Foundation, или Фонд Свободного Программного Обеспечения, - ключевая организация в мире открытого ПО.
Его основал (аж 40 лет назад!) Ричард Столлман, который и по сей день руководит этим проектом.
Из крутого, помимо фонда, что сделал этот дядька:
- он автор проекта GNU - свободной Unix-подобной операционной системы, под которую в 90-ых было написано свободное собственное ядро - Linux;
- автор огромного количества софта, например, первой программой для его GNU стал Emacs, который и сейчас активно развивается.
На днях фонд анонсировал начало работ по проекту LibrePhone - проектом, который призван расшифровать приватные blob'ы, которые на текущий момент использует самый удачный из открытых ОС основанных на Android - LineageOS.
Если проще: LineageOS - ОС с открытым кодом, и сейчас она считается одной из самых безопасных. Из минусов - некоторое количество пропириетарных пакетов с закрытым кодом, работу которых невозможно предсказать. Не очень круто, когда по решению ребят из Google или Apple твой телефон, например, окирпичат (вдруг кто-нибудь решит, что окирпичивание моего телефона необходимо в новом пакете санкций, так как это им точно поможет).
Для этого fsf уже наняли разрабов, и приступили к реверс-инжинирингу под руководством Rob Savoye, который приложил руку к GNU Compilers, GNU Debugger и еще множеству крутых проектов.
Фонд понимает, что проект может занять много времени, но результат того точно стоит, учитывая последние попытки Google запретить установку приложений из сторонних источников (правда, сейчас они прогнулись и пока этого решили не делать, но надолго ли это "пока").
В общем - ждем результатов, поддерживаем фонд и идею открытого ПО 🐧
dev notes | golang digest
В большинстве проектов, с которыми я работал, обычно используют "дефолтный" тип для uuid-идентификаторов - UUIDv4.
UUIDv4 - это 122 бита чистого рандома, отличный тип для уникального идентификатора. Но, обычно мы работаем с этим типом в базах, часто поле с этим типом помечается как primary key, и минус его в том, что он, при вставке в базу в индексируемом поле, дает хаотичный порядок.
Простыми словами: при вставке в базу UUIDv4 попадает в случайное место индекса, из-за чего таблица постоянно разрывается на куски, индекс разрастается и вставки начинают работать медленее.
Посмотрим на примере с b-tree индексами.
Как работает b-tree:
- индекс - это дерево, в котором данные упорядочены по ключу
- листовые страницы хранят отсортированные значения PK
- новые ключи вставляются так, чтобы порядок сохранялся
Что происходит, когда мы вставляем в индекс UUIDv4:
- новая вставка попадает в происзвольное место середины b-tree
- это чаще провоцирует page split - деление страниц дерева пополам и перенос записей в новую страницу
- это дорогие операции, они увеличивают глубину дерева
Получается, что b-tree, который должен быть плотным и последовательным, превращается в хаотичный набор частично заполненных страниц из-за случайного порядка ключей.
Как это решить? Использовать UUIDv7.
Во-первых, этот тип хранит в себе не только рандомный ключ, но и время:
- первые 48 бит - timestamp
- остальные - рандомный ключ + секвенс, чтобы избежать коллизий
Во-вторых, все значения монотонно возрастают из-за включенного в ключ timestamp.
Что умеет v7, чего не умеет v4:
- когда мы сортируем по uuid - фактически, мы сортируем по времени
- когда мы вставляем в индекс - новые записи всегда будут добавляться в конец b-tree дерева, а не в рандомное место
Получается, что используя UUIDv7 мы автоматически оптимизируем вставку в индекс уменьшая оверхед уменьшением количества page split.
Вывод: используйте UUIDv7, он лучше, стабильней, и можно писать order by id desc и получать очень быструю сортировку по времени 😎
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 уходит в кучу
}
}
В рамках подготовки одного материала копаюсь в Rust и пытаюсь понять, как он работает и чем отличается от Go в плане работы с памятью.
Ниже решил поделиться одним примером, который без проблем компилируется в Go, и не компилируется в Rust.
Есть код:
func main() {
var r *int
{
x := 5
r = &x
}
fmt.Println(*r)
}
x = 5, и затем копируем ссылку на нее в r.r и выводим значение:
➜ go run main.go
5
fn main() {
let r;
{
let x = 5;
r = &x;
}
println!("{}", r);
}
➜ git:(master) ✗ cargo build
Compiling memory v0.1.0 (/Users/poltora.dev/rust/memory)
error[E0597]: `x` does not live long enough
--> src/main.rs:5:13
|
4 | let x = 5;
| - binding `x` declared here
5 | r = &x;
| ^^ borrowed value does not live long enough
6 | }
| - `x` dropped here while still borrowed
7 | println!("r: {}", r);
| - borrow later used here
For more information about this error, try `rustc --explain E0597`.
error: could not compile `memory` (bin "memory") due to 1 previous error
В go-блоге вышел очень подробный разбор работы нового garbage collector в Go - Green Tea, который завезли в Go 1.25 - https://go.dev/blog/greenteagc
По утверждениям разрабочиков - оптимизация позволяет выполнять сборку мусора быстрее на 10-40 процентов (правда, не всегда).
В целом - отличная статья с иллюстрациями и объяснением что такое GC в целом и как он работает, а так же за счет чего достигнута опимизация.
Правда, ребята из dolthub недавно попробовали его запустить у себя на проде, и получилось вот это 🫤:
For Dolt, the Green Tea collector doesn’t make any difference in real-world performance numbers. Under the hood, it seems that there’s a small regression in mark time, but this isn’t measurable in our latency benchmarks. Based on this result, we won’t be enabling Green Tea for our production builds, but we also aren’t too worried about it becoming the default in a future version of Go.
Тут сейчас активно обсуждают toon - https://github.com/johannschopplich/toon - либа, которая преобразовывает JSON в более компактный вид в целях экономии токенов при работе с LLM.
Но, есть штука интересней - https://github.com/microsoft/LLMLingua.
LLMLingua сокращает текст промпта без потери смысла, и вот это действительно экономит токены очень хорошо, потому как я обычно общаюсь с моделью не JSON'ом, а текстом.
По заявлению MS компрессия текста от 1.5 до 7 раз, в зависимости от текста и от версии 🕺
В readme подробно расписано, как можно ее затестить и посмотреть на результат.
dev notes | golang digest
Попробовал еще раз настроить codecompanion - плагин для nvim, который реализует привычный из Cursor и vscode чат с моделью, позволяет работать с агентом и рефакторить код inline в файле.
Предыдущая попытка была где-то полгода назад, и надо сказать - за полгода стало сильно лучше:
- Стало сильно проще конфигурировать и у проекта стала более структурированная и полная дока
- Завезли адаптеры под все известные мне модели
- Добавилась работа с агентским флоу
- Добавилась возможность писать свои плагины и тулзы для запуска в чате, в результате чего комьюнити сразу накрутило множество свистелок, которые привели codecompanion в вид, очень близкий к Cursor
Я как раз начал разрабатывать с нуля небольшой проект, в учебно-статейных целях (к слову о статьях - у меня есть блог - poltora.dev, вдруг кто-то еще не читает) - попробую в его рамках пользоваться только codecompanion и сравнить, насколько ai для nvim стал походить на ai в больших редакторах и можно ли пользоваться только им, не переключаясь на Cursor. Пока первое впечатление хорошее.
Все обновления забросил в публичный конфиг - https://github.com/itxor/go-rust-nvim-config 💪
dev notes | golang digest
Пока искал и отбирал статьи для t.me/digest_golang (подписывайтесь, кстати) - нашел полезное - доклад с GoLab 2025 от инженера Reddit с 10 паттернами, на которые он советует обращать внимание во время написания кода.
По названию похоже на типичную проходную статью с медиума с околонулевой ценностью, но по факту нахожу эти советы хорошими, и пару раз поймал себя на мысли что я часто указываю в ревью на те же ошибки, что описывает автор, но раньше не выделял их в отдельные паттерны.
Например:
Не дублируй логи - если ловим ошибку - мы ее или логируем, или возвращаем, но не оба сразу
Для код-ревью это хороший паттерн, потому как мысль-то вроде очевидная, но не всегда на это обращаешь внимание. Если где-то в MR на внутреннем уровне кто-то добавил лог, надо проверить, есть ли он на уровне выше. Если есть - удаляем.
Не добавляй интерфейс слишком рано
Я пришел к такому же выводу спустя несколько лет разработки на Go. Вообще, это напоминание другой базовой истины еще из "Чистого кода" - не делай преждевременных оптимизаций. Но, в индустрии во многих компаниях есть правило: любой тип должен быть с интерфейсом. По факту получается так, что в коде несколько сотен интерфейсов, а более одной реализации - у нескольких. Сначала стоит вернуть конкретный тип, а потом, если будет задача на расширение, всегда можно будет добавить интерфейс и реализовать его еще раз.
Сначала mutex, затем каналы
Каналы - это сложный механизм для синхронизации и взаимодействия горутин, и часто его использование слишком избыточно. Если появилась мысль добавить куда-то горутины или каналы, автор советует сделать так:
- сначала, если возможно, пишем синхронный код, решающий задачу
- если профилирование показывает, что это узкое место - добавляем горутины
- для синхронизации горутин sync.Mutex и sync.WaitGroup
- и только если профилирование показывает, что их недостаточно - вводим каналы
Проектировать код лучше без указателей
В Go очень часто возвращаемое значение из функций описывают следующим образом:
MyFunc() (*MyStruct, error)
nil, err для удобства - не нужно писать MyStruct{}, err. Еще изредка можно услышать, что это делается для оптимизации.
В рамках пет-проекта я дошел до стадии, когда нужно где-то захостить MVP.
Последний раз, до перехода в большие компании на постоянный найм, я хостил свои проекты лет 7 назад: и хотя тогда все активно докеризировалось и уже почти везде начинали внедрять кубер, но маленькие проекты в маленьких компаниях все еще часто крутились на связках вида linux+nginx+mysql+php. И хотя я и умел докеризировать приложения - прод обычно разворачивался по старинке - без виртуальных контейнеров. Да и запускать в то время виртуальные контейнеры в проде по некоторым утверждением было антипаттерном из-за сильной потери в производительности, особенно учитывая, что все приложения тогда я писал на PHP, который производительностью и так не блистал.
Сейчас же я пошел ресерчить вместе с chatgpt, как и на чем мне лучше все развернуть так, чтобы это было относительно дешево и быстро в настройке, и gpt предложил мне несколько вариантов:
- так как я частично использую google-стек - заиспользовать инструменты гугла и для деплоя: GCP cloud run services / jobs + google cloud storage или внешнюю БД
- второй вариант - fly.io и другие похожие сервисы
- третий вариант - свой vps + dokku
Посчитав экономику, самый дешевый вариант под мои нагрузки получился третий - свой vps + dokku. С dokku я до этого не работал, и открыл для себя этот дивный новый мир.
dokku - это PaaS, который помогает менеджерить lifecycle приложения. По-факту, это набор bash-скриптов, который очень упрощают и оптимизируют работу с докером: одной командой можно создать выделенное окружение, задать туда энвы, настроить количество инстансов, которые будут запускаться в выделенных контейнерах. Не нужно составлять DNS вручную - они одной командой пробрасываются между контейнерами, автозаполняются и становятся доступными для вызова, что очень удобно при работе, например, с postgres.
Одна из вещей, которые мне нужно было захостить - это обработчик для tg-бота.
Упрощенно, это было запущено следующей цепочкой команд:
dokku apps:create tgbot - создание выделенного окружения для приложения
dokku plugin:install https://github.com/dokku/dokku-postgres.git
git remote add dokku-bot dokku@<VPS_IP>:tgbot
dokku config:set \
key=value \
...
dokku postgres:create mydb - создание БД
dokku postgres:link mydb tgbot - проброс DATABASE_URL из mydb в tgbot
dokku ps:scale tgbot worker=1 - запускаем 1 инстанс
dokku ps:report tgbot - проверяем статус
Решил зачелленджить разработку через LLM и реализовать один пет-проект полностью через cursor, и сделал пару интересных выводов.
- Есть такая область разработки - написание парсеров. Я знаю нескольких людей, которые буквально весь свой доход аккумулируют этим занятием, благо на биржах до сих пор множество заказов на парсер того или иного ресурса. Так вот cursor написал мне парсер за несколько часов и пару итераций, который я сам писал бы несколько дней, а-то и неделю.
Алгоритм оказался максимально простым: я сбросил модели ссылку на ресурс, модель сделала curl, получила исходный код, и описала регулярки под все необходимые мне данные, которые мне оставалось только немного подтюнить.
- Оно как бы и очевидно, но убедился лично - если попросить cursor подумать о чем-то, что не связано с кодовой базой, которая в нем открыта - он сделает это сильно хуже, чем gpt4/5. Например, окончив очередную итерацию и убедившись, что часть фукнционала работает - я решил его задеплоить, и попросил проанализировать, где мне лучше это сделать, учитывая специфику проекта и мои лимиты по стоимости. Cursor выдал какую-то дичь, и спустя несколько промптов и вагон контекста так и не смог найти нужной информации. GPT-5 даже без контекста и понимания кодовой базы ищет и аккумулирует такую информацию сильно лучше. По-итогу я пришел к тому, что треть запросов я ищу/собираю через gpt-5, обычно в нескольких чатах внутри отдельного проекта, а всю работу с кодом делаю через cursor.
В целом, по итогам недели работы с LLM по вечерам, я написал кода столько, сколько сам бы писал в том же режиме недели 2-3. Но, несмотря на сильное ускорение, надо быть в контексте всего проекта и постоянно проверять логику - часто модель делает что-то или не оптимально, или неправильно, и в некоторых местах ее нужно поправлять.
Качайте технину и юзайте модели, чуваки. Думаю, что тем, кто не будет этого делать - в ближайшие пару лет на рынке станет сильно сложнее.
Если раньше большую часть кода я писал в 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, он менее популярен и тоже имеет не мало багов судя по отзывам, но выглядит многообещающе, поэтому его тоже стоит попробовать).
Добил наконец-то плагин для anki, о котором писал выше - https://github.com/vpoltora/lexiforge
Страница плагина в хабе - https://ankiweb.net/shared/info/1830356451
Плагин максимально простой - добавил в него только то, что использую сам:
- по кнопке (или сочетанию клавиш) генерируется описание слова на выбранном языке (или на английском, если не настроено; при этом если не выбран язык самого слова - он будет определен автоматически) и простой пример с использованием этого слова
- добавляет озвучку к слову из google translate
- имеет reading mode: отдельное окно, где LLM генерирует текст (уровень A1-C2 можно выбрать в настройках) с теми словами, которые были выучены сегодня
По-итогу делаю вывод, что anki - пример очень качестенного софта: это опенсорсная тулза, написанная на плюсах с Qt, но при этом позволяет писать плагины на Python, что очень удобно и умно: на плюсах мало бы кто писал плагины :)
Экосистема имеет свой хаб, куда можно загрузить плагин за пару минут, а если есть какие-то вопросы - спросить их на Reddit, где в сообществе больше 100к подписчиков. Короче - кайф, всем советую.
dev notes | golang digest
В Cursor недавно завезли тему - cursor light, и на мой взгляд это лучшая светая тема для редактора, которую я видел.
Очень приятное сочетание цветов, нет сверх-контрастов, нет перебора с кислотностью - все как надо.
И она мне настолько понравилась, что я решил скопировать эти цвета и запилить на их основе тему для neovim - https://github.com/vpoltora/cursor-light.nvim (отсыпьте звездочек, мои чуваки 🙏)
Все основные цвета спарсил LLM (спасибо vscode за json-конфиги), и затем они вручную попиксельно были отредактированы.
В плагине, помимо основной темы, еще доработки для vim-tree, делающие его немного более минималистичным в стиле курсоровского, и доработки для barbar - расширить вкладки по высоте в neovim нельзя, так как дефолтная высота равна одной строке терминала, но в цвета попасть удалось.
Если кто-то будет использовать - фил фри для фидбэка - допилим тему вместе 🙂
dev notes | golang digest
Google в начале ноябре выкатили поддержку Golang для Agent Development Kit.
ADK - это фреймворк для разработки AI-агентов. Зачем это нужно и почему просто не сходить в LLM по API?
В фреймворк, помимо API самой модели встроили кучу готовых инструментов, каждый из которых умеет делать какое-то базовое действие. Например тул google_search - ищет информацию в сети; MCP Toolbox умеет ходить в разные БД и вытягивать оттуда информацию, и таких инструментов - множество. Все они под общим интерфейсом, и ADK дает возможность под этим же интерфейсом писать свои тулы, которые могут делать буквально что угодно, например ходить в какой-то сервис и дергать его API.
Помимо этого в ADK есть поддержка протокола А2А, который позволяет одному агенту стать оркестратором и управлять другими агентами.
А еще UI для дебага, рантайм и сервер для запуска агентов, поддержка сессий, памяти и многое другое.
Как и где это юзать? Например, юзкейс: прилетает алерт. Какие действия обычно делает дежурный? Я обычно иду по ссылкам из алерта, смотрю последние деплои, в случае не разового всплеска ошибок тегаю необходимые команды и людей, и, если необходимо, начинаю разбираться по логам, метрикам и дашбордам (порядок действий может меняться 🙂).
ADK позволит, например, запилить бота в слаке, которому любой разработчик в компании может на человеческом языке сказать: покажи последние ошибки сервисе myservice за час и посмотри, не связаны ли они с изменениями в базу myservice2.
После чего агент распарсит запрос через LLM, поймет что нужно дернуть тул, который ходит в логи и системы для обсервабилити, затем другим тулом дернет состояние связанной базы, и затем уже нашими кастомными тулами подтянет ошибки из сервиса с логами, и склеит результаты и выдаст понятный ответ.
Простым языком, ADK-агент это LLM-обвязка, заточенная под то, чтобы говорить на человеческом языке, дергать кучу внешний сервисов/БД/API, работать в кооперации с другими такими же агентами, и при этом жить в продакшене как обычный микросервис. Будто бы общаешься с chatgpt, только тот умеет ходить по нужным тебе сервисам и делать необходимые тебе вещи, а не только искать в сети.
Такое нам нравится.
dev notes | golang digest
У Google на днях был большой анонс - они представили свою модель Gemini 3 и релизнули Antigravity - свою собственную платформу разработки, которая по их словам приближается к AGI.
Мне стало интересно пощупать, и как-то так получилось что за пару часов навайбкодил плагин для anki, идея которого давно лежала в заметках - он через LLM прогоняет слово, добавленное в первое поле, ниже пишет его перевод на английском, еще ниже пишет простой пример. А затем к оригинальному слову прикрепляет скачанный аудиофайл из google translate в соответствии с выбранным языком.
Прикрутил туда несколько моделей с возможностью выбора и примитивные, пока, настройки через интерфейс. Думаю допилю и заброшу его в раздел с плагинами на официальном сайте.
Обычно я все это делал или руками, открывая попеременно ChatGPT с браузером и используя сторонние tts-плагины для перевода текста в голос, которые в моменте или перестали работать совсем, или стали просить меня заплатить (за скачанный с google translate mp3 😎).
А теперь немного выводов про модель и про среду разработки:
- За пару часов среда ни разу не крашнулась, но вот модель упала раз 5, и промпт нужно было перезапускать. Думаю в ближайшие недели Google будет активно фиксить баги, и в конечном итоге доведет стабильность до уровня условного Cursor. Из интересного: при запросе сходить по ссылке и проверить что-то визуально на странице, Cursor или не делает ничего, или пытается дернуть curl и распарсить ответ. Antigravity в фоне открыл процесс с браузером и просканил страницы визуально, если термин визуально можно применить к LLM.
- Сама модель по ощущениям сильно лучше Claude Sonnet 4.5 и GPT 5.1 Codex. В режиме агента с первого промпта в первой итерации она выдала большую часть кода, сама же пофиксила часть багов, и по ощущениям сделала это сильно быстрее и лучше, чем аналоги. Составил бы входной промпт лучше и попросил бы сразу написать тесты - править бы пришлось еще меньше. Последние полгода я очень много использую Cursor, и могу сказать что на плюс-минус таких же промптах и похожих задачах последние клод-модели работают сильно хуже, за ними нужно сильно больше убирать и чаще их толкать в нужную сторону.
Еще из интересного - от общения с самой моделью впечатления сильно приятнее, чем от общения с ChatGPT. В целом вайб от диалога такой же, как если бы ты говорил с коллегой (а не с машиной, которая пытается косить под не машину и повторять твой стиль общения, как ChatGPT).
К посту забросил видос с тем, как работает плагин.
dev notes | golang digest
Когда-то я активно юзал wakatime - система плагинов для всех известных и неизвестных IDE и редакторов, которая трекает сколько времени ты потратил на разработку. Первое время было фаново, а затем стало больше походить на какой-то инструмент эффективных менеджеров.
Сейчас вот на reddit релизнули нечто похожее, но интересней - плагин triforce для neovim - https://github.com/gisketch/triforce.nvim
Если коротко, он добавляет элементы RPG в процесс написания кода - XP, уровни и достижения. Выглядит очень круто!
Реальной пользы, конечно, маловато, но мне, как человеку который пишет много кода каждый день, любая геймификация в этот процесс заходит очень хорошо ❤️
dev notes | golang digest
По итогам 3-х последних сообщений выше и моих разбирательств с тем, как Rust работает с памятью и чем это отличается от работы с памятью в Go - набросал небольшую статью.
Внутри разбор семплов процессора, анализ дампов программы на Go, сравнение ее с дампами программы на Rust и вывод, что работает быстрее, что надежнее, а что удобнее.
Велкоме - https://poltora.dev/rust-vs-go-memory-ru/
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
Кен Томпсон - один из создателей Unix, языка программирования C и еще множества вещей, определивших наше настоящее, дал 4-х с половиной часовое интервью, где вспоминал, как это было во времена его работы в The Bell Labs.
Например, его работа над Unix началась после того, как он захотел ускорить чтение и запись на диск в рамках работы над совершенно другим проектом.
Очень нравятся такие истории от буквально кумиров прошлого, которыми я восхищался, когда учился в университете.
Легенда! 💪
https://thenewstack.io/ken-thompson-recalls-unixs-rowdy-lock-picking-origins/
dev notes | golang digest
Наверное, все уже видели новость про запуск grokipedia.com - аналога википедии от Маска, где все статьи пишет и валидирует Grok.
Думаю, что сейчас лучшее время для запуска такой платформы.
В волне бесоебства вокруг AI, где AI пихают туда, где он вообще не нужен, есть один точно верный тренд - автоматизация и суммаризация поиска. Люди все реже и реже ходят по ссылкам - сильно проще попросить ChatGPT найти информацию, провалидировать ее и выдать в сжатом виде. Даже Google в максимально короткие сроки, что удивительно для такой огромной машины, ввел авто-поиск и поставил его на первое место.
Например, по данным самой википедии человеческие просмотры страниц сократились на 8% год к году
Ресерч от Bain & Company показывает, что в среднем сейчас снижение переходов людьми по ссылкам - порядка 15-25% в целом по информационным ресурсам, так как все больше люди полагаются на выдачу AI.
Grokipedia 100% обгонит Wikipedia, воспользовавшись всеми ее знаниями и ее базой. Потому как читать огромную статью и перейти по 10 ссылкам в процессе, прочитав еще 10 - это долго, а найти, нажать кнопку и получить саммари - быстро.
Думаю, кстати, Wikipedia в ближайшее время добавит себе собственный AI, который будет делать похожие вещи или, хотя бы, сжимать смысл статьи по нажатию на одну кнопку.
dev notes | golang digest
Честно, я не подписан на этот канал и подписываться не собирался, но случайно увидел репост.
Автор канала - руководитель разработки в одном из подразделений сбера.
Судя по цитате - автор не умеет строить логические цепочки и вывод из них.
Судя по посту в целом - автор последний раз собеседовался и видел какая дичь с рынком - очень давно.
Как я всегда и везде говорю - не идите работать в конторы типа сбера, яндекса или вк, можно будет очень сильно пожалеть.
Например, какому-нибудь руководителю что-то в вас не понравится, и прямо в офисе вам будут светить лампой в лицо и устраивать допрос (можете поискать последние кейсы с rutube и газпромом)
p.s. Я работал в российском бигтехе и видел, какие бывают конченные собесы и какая там корреляция найма и того, насколько сотрудник эффективно работает.
p.s.s. Я не поддерживаю накрутку опыта и вкатунов, и так как сам веду собесы - отлично умею их ловить; но если кто-то действительно шарит, и добавил себе год опыта к двум имеющимся чтобы пройти абсолютно конченный фильтр на hh - велкоме, будем рады.
Разработчика определяют его навыки, а не количество лет в резюме.
Последнее время, рефлексируя над тем, как в нашу жизнь врываются LLM - мне все больше нравится идея постоянного обучения.
Во-первых, автоматизируя большинство рутинных действий и решая большинство задач через модели - мы, по природе своей, начинаем терять навык делать это сами. А отупеть очень не хотелось бы, поэтому тут как с тренажерным залом - железки нам поднимать уже много десятилетий как не нужно, но мы сами подвергаем себя нагрузкам, чтобы не рассыпаться раньше времени. С мозгом - та же история.
Если этого мало, то вот вторая причина. У поколения наших родителей была интересная опция: ты сначала учишься, получаешь специальность, а затем всю жизнь работаешь на выученной базе нарабатывая опыт. Сейчас же тебе нужно сначала учиться, затем нарабатывать опыт, а потом, если ты не хочешь терять в уровне жизни - делать еще один цикл обучения-наработки опыта, затем еще и еще. У меня так было со сменой стека: сначала это был PHP, затем потолок по зп -> период обучения -> смена стека на Go -> наработка опыта на нем. Это позволило мне вырасти по ЗП еще выше и выйти на зарубежный рынок.
Сейчас с приходом LLM я понимаю, что следующий этап обучения будет выглядеть как углубление текущих знаний и изучение новых языков.
Через 5-10 лет, вероятно, обучение будет или направлено на архитектуру приложений, или смещено в сторону менеджмента.
К вопросу углубления знаний - сейчас это кажется очень важным. Почему? Потому что на фоне у меня работает модель, которая генерит портянки кода и дефолтные crud'ы. Если кто-то делает тоже самое на работе - это можно заменить, вопрос лишь времени и интеграции модели в различные инструменты для сбора полного контекста, такие как jira и slack.
Но если задача, которую решает инженер - действительно сложная, например поиск какого-то бага (на этот счет есть отличное свежее расследование от cloudflare - там ребята искали и фиксили сложный баг в компиляторе arm64 под огромной нагрузкой) или проектирование архитектуры в действительно сложном контексте - вот это заменить будет тяжело.
Но когда-то же LLM научится решать и такие сложные задачи? Я думаю что сейчас единственная возможность заставить LLM работать с такими сложными задачами - очень строгая документация внутри проекта по очень строгим правилам. Например, 10 сервисов общаются между собой. У каждого должна быть дока с подробным и понятным (для модели) описанием того, что делает этот сервис, причем в очень строгом формате. Должны быть прописаны связи, по которым модель может ходить от сервиса к сервису и захватывать весь контекст, и все это должно работать с одними и теми же доменами. Иначе модели просто не хватит памяти и мощности, чтобы весь этот контекст впитать и держать актуальным. А теперь вспомним, сколько сервисов и связей в дейстительно больших проектах, не говоря уже о том, сколько там костылей, неожиданных взаимодействий и какая там документация. Большие компании в ближайшие годы не смогут переписать и документировать свои сервисы так, чтобы LLM решала в них действительно сложные задачи, но и перестанет нанимать инженеров, которые занимались рутинными действиями по перекладыванию ответов в базу и обратно.
dev notes | golang digest
the following content will be interesting for Russian-speaking only:
тут начали закупать в ТГ рекламу некого мессенджера "Telega", общающего золотые горы стабильную работу ТГ на территории РФ
но в чем подвох? а в том, что эта "Telega" (которая https://telega.me) - является проектом VK.
но как об этом узнать? а все просто - берем APK и открываем декомпилятор
идем в ru.dahl.messenger.Extra и видим:
-> PROXY_ADDRESS = "dal.mvk.com", прокси-адрес, запишем
-> MYTRACKER_SDK_KEY = "*", SDK-ключ от трекера MyTracker, который принадлежит Mai VK Group
-> CALLS_BASE_URL = "https://calls.okcdn.ru/" - те самые рабочие звонки, которые на самом деле являются звонками через инфраструктуру Одноклассников (на которых работает еще MAX и VK Звонки, ага)
а теперь берем dal.mvk.com:
-> неймсервера mvk.com идут на малоизвестный домен VKONTAKTE.RU
-> в декомпиляции официального клиента VK для Android можно найти референсы на "https://jira.mvk.com"
(и вся реклама этого клиента в ТГ ведет на трекинг-домен trk.mail.ru)
но кому не пофиг? вдруг ВК просто по приколу решили сделать форк ТГ, прикрывшись прокладкой из Татарстана?
а вот тут уже обнаруживается прикольная вещь: в клиенте есть "черный список" нежелательных ТГ-каналов, ботов и пользователей! при нажатии на которых выводится ТГ-шная "заглушка" с своим текстом:
<string name="ContentIsUnavailable">Материалы недоступны</string>
<string name="ContentUnavailableInfo">Этот %1$s недоступен в связи \n с нарушениями правил платформы</string>
Пилю тут пет-проект, связанный с каналами и телеграмом, и обнаружил самый странный способ монетизации.
Используя telegram bot api есть возможность вставить в сообщение кастомный emoji, что мне и нужно было. Каждый кастомный emoji имеет свой уникальный id, и для того, чтобы вставить его в строку, телеграм рекомендует делать следующее: вставить какой-нибудь плейсхолдер, а затем указать его место и длину, чтобы кастомный emoji его подменил.
Но для того, чтобы emoji успешно вставился - нужно купить уникальное имя для бота, внезапно 🤷♂️🤷♂️🤷♂️
Имя покупается на связанной с ton площадке - fragment, и каждая покупка - это аукцион на неделю, где любой пользователь может перебить твою ставку. И после этого или повышай, или выбирай новое имя 🤡
Купил вот, жду, надеюсь не перебьют.
Допрошел на днях большой и многоэтапный собес в один большой и с недавних пор известный финтех из Мексики. Собес прошел, оффер получил, но с компанией не сматчились 😔
Хочу рассказать про второй этап - system design. У меня это был первый сисдиз, который я проходил после прохождения курса по system design от Балуна (так как это не реклама - курс можете нагуглить сами).
Задачу мне дали такую: есть система комментариев в большой социальной сети, комментарии подгружаются синхронно. Хотим сделать это асинхронно и добавить туда поддержку медиа.
До этого я такой задачи не видел, но решить ее получилось, и как сказал интервьювер - получилось решить хорошо. Очень хорошо помогли паттерны из курса: в решении я сделал микс из паттерна по работе с медиа, вкрутил несколько CDC, применил active/passive модель для системы с сокетами, и в итоге схема (приложил ее к посту) получилась рабочей, за исключением некоторых правок. В целом - мне даже понравилось проходить собес в таком формате, курс себя точно оправдал.
Итераторы в Go, про которые я несколько раз уже писал на этом канале, релизнули еще в прошлом году, но я так ни разу их и не применил в работе – просто не было задачи, которая не была бы решена без них.
Но недавно я поймал себя на мысли - у меня в рабочих проектах есть множество мест, где данные читаются из потоков: из файлов, из базы или из сокетов. И я решил разобраться, можно ли применить итераторы для этих кейсов и смогут ли они облегчить или оптимизировать потоковую обработку.
Спойлер - они действительно упростили жизнь и где-то даже позволили оптимизировать потребление ресурсов. Я решил выделить паттерны их использования, которые мне показались удобными, и получилась новая статья - https://poltora.dev/iterators-in-go-ru/
Велкоме.