4gophers

Rune

#golang

Команда Unstable Build заопенсорсила свою нативную IDE Rune, написанную на Go.

Под капотом - GPU-ускорение, собственный терминал, REPL и расширяемое ядро, которое общается с расширениями по gRPC. Поддерживается, конечно, Go, а еще Rust и Zig.

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

Возможно, я даже попробую слезть с VS Code и наконец-то начать пользоваться хоткеями

А как она шикарно запускается!

https://kodikapusta.ru/news/1216-rune

Поддержать проект на boosty и читать в MAX

Прокси для базы данных

#golang

Автор пишет простой такой прокси на Go в учебных целях вдохновившись статьей Figma о том, как их команда баз данных построила DBProxy для перехвата SQL-запросов и маршрутизации их по разным узлам Postgres.

Он реализует проксирование TCP-соединений между клиентом и MySQL: перехватывает пакеты, находит команду COM_QUERY по структуре пакета MySQL и переписывает имя таблицы. В статье объясняется структура MySQL-пакета и демонстрируются базовые принципы, на которых строятся настоящие решения для шардинга, валидации запросов, безопасности и наблюдаемости

https://kodikapusta.ru/news/1208-proksi-dlia-bazy-dannykh

Поддержать проект на boosty и читать в MAX

У нас отмена!

#golang

Статья разбирает, как пакет singleflight в Go предотвращает лавину запросов к кэшу. Он прекрасно схлопывает одинаковые запросы в одну операцию, но есть нюансы

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

https://kodikapusta.ru/news/1197-u-nas-otmena

Поддержать проект на boosty и читать в MAX

Конкурентный сервер на Go

#golang #learn

Это восьмая часть серии о конкурентных сетевых серверах, в этот раз посвященная Go. В прошлый раз было про Rust

Автор показывает, как язык решает описанные ранее задачи. Статья начинается с последовательного сервера с state machine, затем показывает конкурентную версию с одной горутиной на клиента.

Для ограничения параллелизма предлагаются счетный семафор на канале и паттерн воркер пул, когда нужно сохранять состояние между задачами.

Логично, что в Go почти никогда не нужно прибегать к async/event-driven программированию, потому что конкурентность встроена в язык и рантайм. Но интересно смотреть в сравнении с другими языками

https://kodikapusta.ru/news/1203-konkurentnyi-server-na-go

Поддержать проект на boosty и читать в MAX

Интересные баги

#golang

Команда sigma star(хз кто это) нашла и исправила давнюю ошибку в рантайме Go, проявлявшуюся только на 32-битных встраиваемых Linux-системах.

Приложение периодически падало с ошибкой "runtime: netpoll: eventfd ready for something unexpected". Корень проблемы оказался в том, что Go хранит в 8-байтовом поле ev.Data два типа указателей - сырой указатель на event fd и тегированный указатель на pollDesc, а сравнение на 32-битных little-endian системах считывает лишь младшие 4 байта, из-за чего адрес event fd алиасился с fdseq. Как только долгоживущая программа накапливала миллионы пересозданных pollDesc, netpoll путал сокет с event fd и падал

Ребята прям недра залезли. Представляю как они все это дебажили

https://kodikapusta.ru/news/1198-interesnye-bagi

Поддержать проект на boosty и читать в MAX

GopherCon UK 2026

#golang #video

Видосы с GopherCon UK 2026 подоспели. Много всего интересного. Девид Чейни, Билл Кеннеди и другие широко известные в узких кругах докладчики.

И даже про AI есть вполне адекватные доклады

https://kodikapusta.ru/news/1196-gophercon-uk-2026

Поддержать проект на boosty и читать в MAX

Используем Datastar

#golang

В статье интеренсно про использование Datastar. Я вот первый раз про него услашал

Автор рассказывает, как построить веб-версию утилиты htop используя Go-бэкенд и, собственно, гипермедиа-фреймворк Datastar. Вместо фронтенд-фреймворка вроде React здесь HTML-патчи отправляются напрямую с сервера через Server-Sent Events. Вся интерактивность задается декларативными data-* атрибутами, поэтому клиентский код остается минимальным.

Системные метрики собираются библиотекой gopsutil, HTML шаблон вшивается в бинарник через go:embed, поэтому все приложение - это один бинарь

Кончено, Datastar не заменит React или Vue, но отлично подойдет для случаев, когда состояние живет преимущественно на бэкенде. В целом, это довольно интересный подход

https://kodikapusta.ru/news/1195-ispol-zuem-datastar

Поддержать проект на boosty и читать в MAX

На Rust после Go

#rust #golang

Автор, пять лет писавший на Go, сначала скептически отнесся к появлению Rust в его команде.

Но появился проект, в котором нужны были низкое потребление памяти и mpmc-обмен сообщениями. Пожтому несколько CLI и сервисов решили переписать на Rust и это заставил его освоить язык всерьез.

Переход оказался непростым. Больше всего дались строгость компилятора, макросы и, главное, borrow checker(ну конечно) и async с лайфтаймами, которые он советует изучить в первую очередь. Теперь он ценит именно эту строгость.

В итоге автор рекомендует если Go справляется, то использовать Go. А Rust брать при реальных ограничениях по памяти, стабильности и близости к железу. Ну или если вы ебнулись и решили все переписать на Rust с помощью AI

https://kodikapusta.ru/news/1189-na-rust-posle-go

Поддержать проект на boosty и читать в MAX

tnk9x

#golang #gamedev #tools

Современный ремейк классической аркадной игры Battle City, написанный на Go с использованием движка Ebiten и запускаемый как нативно, так и в браузере через WebAssembly. Проект сочетает любовь к оригиналу с изучением Go и разработки игр.

Реализованы полный игровой цикл с защитой штаба, управление для двух игроков, разрушаемая местность, все пять типов поверхностей, четыре типа врагов и все шесть бонусов. Враги, кстати, на на Lua-скриптах реализованы

https://kodikapusta.ru/tools/43-tnk9x

Поддержать проект на boosty и читать в MAX

Поговорим про PGO

#golang

Profile-guided optimization (PGO) заменяет эвристические догадки компилятора реальными замерами.

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

Автор протестировал PGO в Go на трех JSON-документах, парся их стандартным encoding/json: прирост оказался скромным - лучший результат +4,7%, а большинство случаев в диапазоне 2–3%

https://kodikapusta.ru/news/1173-pogovorim-pro-pgo

Поддержать проект на boosty и читать в MAX

KV на S3

#golang

Статья разбирает, как построить key-value базу данных, у которой основным слоем хранения является объектное хранилище вроде S3, на примере движка IsleDB на Go, и почему наивная замена "файлов на диске" на "объекты в бакете" не работает. СУБД неявно полагается на атомарное переименование, дешевые случайные чтения и понятный ответ на вопрос "записалось ли?".

Ключевая идея в том, что LSM-дерево уже идеально ложится на объектную модель, а видимость состояния задается не перечислением бакета, а маленьким мутабельным объектом заголовком, который обновляется условной записью (используется CAS), дополняется токеном для защиты от "оживших" старых писателей и ограниченным маркером коммита для разрешения ситуации "запись прошла, но ответ потерялся".

Объектное хранилище вот совсем не убирает сложные проблемы СУБД. Наборот, концентрирует их в небольшом наборе протоколов публикации и жизненного цикла, которые и становятся настоящим "транзакционным движком"

https://kodikapusta.ru/news/1175-kv-na-s3

Поддержать проект на boosty и читать в MAX

Go идеален для AI

#golang #ai

В эпоху ИИ-помощников узкое место разработки сместилось с написания кода на его проверку, ревью и сопровождение

А какой язык просто читать? Конечно Go!

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

Ставка на читаемость и строгую стандартизацию делает сгенерированный код предсказуемым и легким для проверки человеком, а статическая типизация и быстрая компиляция позволяют отлавливать галлюцинации моделей еще до запуска в проде. Наконец, гарантия обратной совместимости, единый статический бинарник и встроенные инструменты модернизации обеспечивают долгосрочную поддерживаемость кода, который пишут люди и ИИ совместно

https://kodikapusta.ru/news/1172-go-idealen-dlia-ai

Поддержать проект на boosty и читать в MAX

paneru

#rust #tools

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

Интересный опыт

https://kodikapusta.ru/tools/41-paneru

Поддержать проект на boosty и читать в MAX

Typescript Defer

#golang

Автор экспериментировал с добавлением оператора defer из Go в компилятор TypeScript, реализовав парсинг, проверки и AST-трансформацию, которая оборачивает тело функции в try/finally и выполняет отложенные вызовы в обратном порядке (LIFO) с захватом значений на момент регистрации.

В процессе он столкнулся с принципиальными сложностями: ошибки в JavaScript - это поток управления, а не значения, как в Go, поэтому пришлось вводить политики агрегации исключений через AggregateError, последовательный await для асинхронной очистки и явный запрет defer await.

В итоге автор пришел к выводу, что defer плохо ложится на модель ошибок TypeScript/JavaScript, и рекомендует использовать нативный using из пропозала Explicit Resource Management как более идиоматичную альтернативу, что логично

https://kodikapusta.ru/news/1164-typescript-defer

Поддержать проект на boosty и читать в MAX

Go 1.27

#golang

Антон Жиянов делал интерактивные туры по Go с версии 1.22 по 1.26, но решил остановиться. Хесус Эспино подхватил эстафету и разбирает здесь огромный массив нововведений Go 1.27 - от обобщенных методов и профиля goroutineleak до нового пакета uuid и экспериментальной переносимой SIMD

https://kodikapusta.ru/news/1161-go-1-27

Поддержать проект на boosty и читать в MAX

SIMD в go

#golang

Будущее пришло быстрее, чем ожидалось: в go1.27rc2 пакет simd стал портируемым, и один Go-код разворачивается в Neon на Apple Silicon и в AVX2 на Intel. Это наборы векторных инструкций двух процессорных миров, ликбез по ним как раз в этой статье.

Автор проверит обещания портируемости на живом железе: один исходник, два дизассемблера, две пачки замеров. Ассемблер писать не будем, весь код запускается копипастой

Годная статья на Хабре. Аж не верится

https://kodikapusta.ru/news/1160-simd-v-go

Поддержать проект на boosty: https://boosty.to/kodikapusta

Swiss Tables

#golang

Статья подробно разбирает переход Go 1.24 от классической bucket-архитектуры мап к Swiss Tables - дизайну, позаимствованному из Abseil, который заменяет цепочки оверфлоу-указателей на плоское открытое адресование с компактными контрольными байтами и групповым probing'ом по 8 слотов.

Swiss Tables позволяют совершать меньше промахов кеша за счет отказа от «погони за указателями», увеличивается допустимая плотность заполнения, и фильтрация кандидатов становится более быстрой по h2-отпечатку до полноценного сравнения ключей.

На микробенчмарках доступ к большим мапам ускорился на 30–35%, итерация - до 60% на разреженных картах, однако на уровне приложений выигрыш скромнее, около 1.5% в среднем, а в сценариях с холодным кешем и очень большими разреженными мапами возможны регрессы.

Да-да, уже 100% раз читали про швейцарские таблицы. Но статью в закладки лучше добавить

https://kodikapusta.ru/news/1153-swiss-tables

Поддержать проект на boosty: https://boosty.to/kodikapusta

metago

#golang #tools

Инструмент метапрограммирования для Go на основе шаблонов: вы определяете переиспользуемый Go-шаблон в файле *.metago (синтаксис Go-темплейтов), а в исходном коде вешаете директиву //mgo:gen stringer на тип или объявление, и metago рекурсивно сканирует проект, находит все шаблоны и генерирует код в сайдкар-файлы meta.go рядом с исходниками.

Поддерживает встроенную генерацию через //mgo:inline ... //mgo:end, кастомные параметры, аргументы с дефолтами через metago.toml и встроенные стандартные шаблоны: std.stringer, std.enum, std.mock, std.serde. И один шаблон может собирать данные из всех директив пакета

Вот с этими //mgo:gen ... прям приятно работать

https://kodikapusta.ru/tools/29-metago

Поддержать проект на boosty: https://boosty.to/kodikapusta

Визуализируем GC

#golang

Статья наглядно исследует новый сборщик мусора Green Tea в Go 1.25/1.26.

Автор пишет визуализатор кучи, показывающий, как Go размещает объекты одного размерного класса рядом друг с другом и сравнивает его с C#. Он отмечает, что в отличие от C#, Go никогда не перемещает их при сборке.

Ключевое улучшение Green Tea в том, что вместо обхода указателей по мере их обнаружения со случайным доступом к памяти, GC теперь сканирует span целиком и сохраняет знания о найденных указателях в очередь на будущее и это подтверждается через perf.

В конуе автор демонстрирует главную слабость неперемещающего GC. После освобождения 90% объектов разряженные страницы не возвращаются системе, потому что выжившие объекты "закрепляют" span'ы. Для сравнения, компактирующий GC в C# справляется с этим автоматически, а в Go приходится вручную копировать выжившие объекты в новые слайсы

https://kodikapusta.ru/news/1147-vizualiziruem-gc

Поддержать проект на boosty: https://boosty.to/kodikapusta

Арены жалко

#golang

Go отказался от экспериментальных Memory Arenas - механизма, позволявшего выделять память крупными пулами в обход GC для снижения накладных расходов в высоконагруженных сценариях.

Автор считает это стратегической ошибкой. Формальной причиной стали проблемы безопасности, когда можно попытаться использовать память после ее освобождения. И еще никому не понравилась несовместимость с интерфейсами - пришлось бы добавлять аргумент *Arena в сигнатуры функций, и это раскололо бы экосистему на стандартный и arena-миры, подобно тому как context.Context когда-то "инфицировал" весь Go.

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

https://kodikapusta.ru/news/1137-areny-zhalko

Поддержать проект на boosty и читать в MAX