4gophers

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

687 ГБ аллокаций #golang Автор профилировал свою многопоточную реализацию Redis на Go и обнаружил, что одна строка кода s.kvList[k] = append(v[popped:], s.kvList[k]...) за время бенчмарка суммарно аллоцировала 687 ГБ памяти. Реально приложение держало в памяти лишь около 4,58 МБ. В чем прикол? Проблема была в том, что LPUSH каждый раз создавал новый массив и копировал весь существующий список, давая O(n²) по аллокациям, тогда как RPUSH использовал штатную стратегию роста слайсов с амортизированным O(1). Замена на deque с двумя индексами, растущий от середины в обе стороны, ускорила LPUSH в 33 раза, а аллокации упали с 715 ГБ до 27 ГБ Нужно быть внимательным https://kodikapusta.ru/news/1136-687-gb-allokatsii Поддержать проект на boosty и читать в MAX

HTMX с Go #golang Автор детально описывает свои паттерны интеграции HTMX с Go. Почитайте, там много всего интересного. Но мне весь это веб всё еще не нравится. Любой HTML - это в первую очередь ебля со стилями. Я хотел бы, чтобы уже сделали как во Flutter или Qt, чтобы было очевидно, как выравнивать и форматировать блоки. А не вот это всё https://kodikapusta.ru/news/1135-htmx-s-go Поддержать проект на boosty и читать в MAX

GALA #golang #tools GALA (Go Alternative LAnguage) - статически типизированный функциональный язык, транспилирующийся в Go, который приносит в экосистему Go sealed-типы с исчерпывающим паттерн матчиг, монадический стек, иммутабельные коллекции и do-нотацию с накоплением ошибок через Validated и конкурентным выполнением через Future. Уже даже есть примеры проектов на GALA Кароче, ребята решили SCALA написать на Go https://kodikapusta.ru/tools/24-gala Поддержать проект на boosty и читать в MAX

Убираем ограничения #golang Автор разбирает продвинутый прием устранения проверки границ в горячих путях Go Когда компилятор не может доказать безопасность доступа к срезу, а программист может, на помощь приходит unsafe.Pointer с арифметикой указателей. Вместо binary.LittleEndian.Uint32(data[i:]) можно использовать *(*uint32)(unsafe.Add(unsafe.Pointer(unsafe.SliceData(b)), i)), что устраняет все проверки границ и на реальном бенчмарке brotli-компрессора даёт прирост ~10%. У автора в статье довольно много таких хаков Кроме очевидного сокращения инструкций и ветвлений в хотпасе, вы еще и работу кеша процессора улучшаете. Меньше инструкций, меньше мисов https://kodikapusta.ru/news/1129-ubiraem-ogranicheniia Поддержать проект на boosty и читать в MAX

Go конкурентность в C #golang #c Автор исследует, насколько близко можно воспроизвести конкурентную модель Go на чистом C с помощью только POSIX-потоков. Это делается для проекта Solod - строгого подмножества Go, транслируемого в C без рантайма и сборщика мусора. Реализация построена на двух примитивах - pthread_mutex_t и pthread_cond_t. Поверх них сделаны мьютексы, condition-переменные, пул воркеров с кольцевым буфером и буферизированные/небуферизированные каналы с рандеву-передачей значений напрямую со стека отправителя. Но без зеленых тредов и своего планировщика Бенчмарки показывают, что на крупных задачах пул pthreads уступает Go всего ~10%, а атомики и неподблокированные мьютексы даже быстрее, но как только поток паркуется в ядре, накладные расходы на wakeup-сисколлы дают проигрыш до 23 раз. Это, очевидно, плата за отсутствие отдельного планировщика и простоту кода в ~200 строк https://kodikapusta.ru/news/1128-go-konkurentnost-v-c Поддержать проект на boosty и читать в MAX

OpenTelemetry в комптайме #golang Разрабы OpenTelemetry объявили о первом стабильном релизе Go Compile-Time Instrumentation (v1) Новый инструмента otelc, который встраивает телеметрию в Go-бинарник на этапе компиляции через механизм -toolexec, без правок исходного кода и без отдельного кода в рантайме. В v1 поддерживаются net/http, database/sql, gRPC, Redis и метрики рантайма Go. Можно инструментировать кастомный код через специальные правила в конфиге. Инструмент заменяет go build на otelc go build. Но это необязательно, можно просто настроить GOFLAGS с указанием toolexec, а значит все уже совместимо с вашим CI/CD В будущем планируется реестр инструментаций, расширение покрытия библиотек и оптимизация Лучшее использование toolexec, которое я видел https://kodikapusta.ru/news/1127-opentelemetry-v-komptaime Поддержать проект на boosty и читать в MAX

Теперь про Go и Playdate доступен и на вквидео и на рутубе вквидео https://vkvideo.ru/video-228916121_456239441 рутуб https://rutube.ru/video/338ceeb9741a5f53acf04b58b1ddff3d/ ну и на ютубе тоже посмотрите https://www.youtube.com/watch?v=TH1q-Yt8Jwc Playdate — это компактная портативная игровая консоль от компании Panic и Teenage Engineering. У консоли черно-белый экран 2,7 дюйма без подсветки, необычное механическое управление крутилой кранком В этом видео научимся писать программы под playdate на Go и напишем приложение для чтения новостей с сайта kodikapusta.ru

Запилил ещё один видос. В этот раз рассказываю про программирование на Go под Playdate. Пока только на ютубе: https://www.youtube.com/watch?v=TH1q-Yt8Jwc

mmap или pread #golang Автор статьи - инженер из VictoriaMetrics. На примере реального движка хранения VictoriaLogs разбирает выбор между системным вызовом pread и отображением файла в память mmap при чтении байтов из файлов. Автор объясняет, что pread имеет заметную цену: каждый вызов - это дорогой переход из пользовательского пространства в ядро с копированием данных, и при миллионе мелких случайных чтений на один запрос теряется целая секунда процессорного времени только на пересечение границы ядра. Mmap превращает эти чтения в дешевый доступ к памяти, но у него есть коварная проблема именно для Go: обращение к "холодной" странице вызывает major page fault, который блокирует поток ОС незаметно для планировщика Go. При достаточном числе таких блокировок программа может застопориться. В итоге, оптимальное решение - это абстракция ReaderAt, которая через системный вызов mincore проверяет, находится ли нужная страница уже в оперативной памяти. Если да, то используется быстрый mmap-путь, а если нет - то безопасный pread. При этом результаты mincore кэшируются в битовой карте на срок до минуты. В статье еще разбирается целая куча самых разных тонкостей https://kodikapusta.ru/news/1120-mmap-ili-pread Поддержать проект на boosty и читать в MAX

TypeScript переписали на Go #golang Команда Microsoft с помощью AI переписала компилятор TypeScript 7.0 на Go, а не на Rust (шах и мат!). Команда добилась примерно десятикратного ускорения сборки, и автор использует это как повод доказать, что Go - оптимальный язык для эпохи агентной разработки с использованием ИИ. Go изначально спроектирован ради читателя, а не писателя кода. И это свойство идеально подходит большим языковым моделям, которые читают код гораздо больше, чем люди (что печально). Автор разбирает четыре накапливающиеся проблемы, которые Go решает лучше Python и TypeScript: медленная сборка, недетерминированное управление зависимостями, слабая обратная связь по ошибкам и постоянная нестабильность экосистемы. Вот видите, есть еще порох в пороховницах! Все на Go перепишем https://kodikapusta.ru/news/1119-typescript-perepisali-na-go Поддержать проект на boosty и читать в MAX

На 49% быстрее из-за выравнивания #golang Разбор неожиданной оптимизации в Go: сдвиг массива на 4 байта через добавление padding-поля ускоряет операцию обнуления на 49% на Intel и на 9% на AMD. Обнуляция - это что-то типо b.data = [words]uint32{} Но почему так происходит? Компилятор генерирует инструкцию REP STOSQ, чей механизм Enhanced REP (ERMSB) записывает целые кэш-строки без предварительного чтения, но только при 8-байтном выравнивании адреса - при смещении. Добавление 4 байт как раз выравнивает позицию массива по 8 в примере автора. Не уверен что вам это пригодиться, но мне нравятся люди, которы зелазют так глубоко в кишки к байтам и битам https://kodikapusta.ru/news/1114-49-bystree-iz-za-vyravnivaniia Поддержать проект на boosty и читать в MAX

Активация сокетов #golang Автор рассказывает, как с помощью сокет-активации systemd запускать Go-сервис только когда в него реально приходит запрос, чтобы не тратить память и CPU. systemd сам открывает и слушает сокет на нужном порту, а при первом подключении запускает сервер, передавая ему уже открытый файловый дескриптор вместе с переменными окружения LISTEN_PID и LISTEN_FDS. В Go это можно сделать вручную через net.FileListener, но удобнее использовать пакет coreos/go-systemd, который через activation.Listeners() сразу отдает готовый net.Listener. Можно наколбасить решение, которое сможет работать и без активации, при этом использовать фишечки systemd через daemon.SdNotify() и будет завершает работу после нескольких секунд простоя с помощью отдельной горутины с таймером. В итоге сервис будет стартовать по первому запросу и автоматически выключается при бездействии, освобождая ресурсы https://kodikapusta.ru/news/1113-aktivatsiia-soketov Поддержать проект на boosty и читать в MAX