Тут сейчас активно обсуждают toon - https://github.com/johannschopplich/toon - либа, которая преобразовывает JSON в более компактный вид в целях экономии токенов при работе с LLM.

Но, есть штука интересней - https://github.com/microsoft/LLMLingua.
LLMLingua сокращает текст промпта без потери смысла, и вот это действительно экономит токены очень хорошо, потому как я обычно общаюсь с моделью не JSON'ом, а текстом.

По заявлению MS компрессия текста от 1.5 до 7 раз, в зависимости от текста и от версии 🕺

В readme подробно расписано, как можно ее затестить и посмотреть на результат.

dev notes | golang digest

В 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.

Я у себя на проектах и на работе пока экспериментировать с этим не буду - дождусь бенчмарков и тестов нового 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

В рамках подготовки одного материала копаюсь в 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

Давай теперь напишем тот же код на Rust:

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

Ну во-первых, компилятор Rust - мое почтение 😎. Очень подробный анализ ошибок (но это неспроста, ниже объяснение - почему).
А во-вторых, почему мы получили ошибку?

Все дело в базовой концепции работы Go и Rust с памятью. В Go компилятор имеет фазу escape-анализа, которая проверяет код и помечает, на стек или на кучу должна упасть та или иная переменная. Когда компилятор видит, что переменная r принимает значение из локальной области видимости (x) - он перемещает ее на кучу - в общую память процесса, с которой могут работать все потоки.
Затем, в процессе работы программы, параллельно с Go вступает в игру Garbage Collector, который дает нам гарантию, что все такие переменные, даже если мы про них забудем и не удалим их (а мы обычно этого не делаем) - будут освобождены. Скорость разработки в обмен на скорость работы программы.

У Rust нет Garbage Collector, но есть несколько концепций, которые гарантируют, что утечек памяти не будет, и одна из них - это фаза компиляции под названием анализ времени жизни. Именно он видит, что r принимает значение от объекта, время жизни которого закончится раньше, чем будет выведена r - и ругается. В случае с Rust компилятор заставляет разработчика больше думать о коде, но не запускает Garbage Collector. Сложность разработки в обмен на скорость исполнения.

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

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

Сейчас вот на reddit релизнули нечто похожее, но интересней - плагин triforce для neovim - https://github.com/gisketch/triforce.nvim

Если коротко, он добавляет элементы RPG в процесс написания кода - XP, уровни и достижения. Выглядит очень круто!

Реальной пользы, конечно, маловато, но мне, как человеку который пишет много кода каждый день, любая геймификация в этот процесс заходит очень хорошо ❤️

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

У 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

Запилил за последние дни в 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

В Cursor недавно завезли тему - cursor light, и на мой взгляд это лучшая светая тема для редактора, которую я видел.

Очень приятное сочетание цветов, нет сверх-контрастов, нет перебора с кислотностью - все как надо.

И она мне настолько понравилась, что я решил скопировать эти цвета и запилить на их основе тему для neovim - https://github.com/vpoltora/cursor-light.nvim (отсыпьте звездочек, мои чуваки 🙏)

Все основные цвета спарсил LLM (спасибо vscode за json-конфиги), и затем они вручную попиксельно были отредактированы.

В плагине, помимо основной темы, еще доработки для vim-tree, делающие его немного более минималистичным в стиле курсоровского, и доработки для barbar - расширить вкладки по высоте в neovim нельзя, так как дефолтная высота равна одной строке терминала, но в цвета попасть удалось.

Если кто-то будет использовать - фил фри для фидбэка - допилим тему вместе 🙂

dev notes | golang digest

Antigravity, который я хвалил выше, конечно крут, но будьте острожней: тут на реддите появился интересный пост - https://www.reddit.com/r/google_antigravity/comments/1p82or6/google_antigravity_just_deleted_the_contents_of/, где автор пишет как агент в процессе работы решил дропнуть файлы на локальном диске, и успешно это сделал, без запроса разрешения на это.

При этом, модель заметила:

Нет, вы совершенно не давали мне разрешения на это. Я просматриваю журналы с предыдущего шага и с ужасом вижу, что команда, которую я выполнил для очистки кэша проекта (moth r), по‑видимому, ошибочно указала на корень вашего диска D:, а не на конкретную папку проекта.

🙂

Ну такое, гугл, ну такое.

dev notes | golang digest

Нерегулярная рубрика - плагины для 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