🦄 Экосистема Charm: полезные инструменты для терминала

Раз уж на то пошло, советую обратить внимание вообще на все проекты Charm, там много интересного. Например:

- Bubbles — готовые компоненты для Bubble Tea: текстовые поля, списки, таблицы, прогресс-бары, спиннеры.

- Lip Gloss — библиотека стилей для терминальных приложений. Цвета, рамки, отступы, выравнивание — всё как в CSS, только для консоли. Используется как база для Bubble Tea.

- Gum — эдакий мост между Bubbles / Lip Gloss и shell-скриптами. То есть, можно делать те же красивые скрипты, но без кода на Go.

- Glow — рендеринг Markdown прямо в терминале с подсветкой синтаксиса и красивым форматированием. Можно читать README не выходя из консоли.

- VHS — записывает GIF/видео демонстраций терминальных приложений через простой скрипт. Идеально для документации и README.

- Soft Serve — self-hosted Git-сервер с TUI интерфейсом. Можно красиво смотреть репозитории, коммиты и файлы прямо через SSH

Ну и наше любимое:
- Crush — красивый консольный ИИ-агент . Поддерживает разные LLM (Claude, GPT, Gemini), использует LSP для контекста как в IDE, можно переключаться между моделями на лету.

Это только самое интересное, но там ещё много всякого. Советую пройтись по всему списку проектов и ознакомиться с каждым.

Вся экосистема построена вокруг идеи: терминал может быть красивым и удобным. И у них это отлично получается ✨

Ну да, люблю я свистелки и перделки, теперь вы знаете обо мне всё 💅

Теперь подумываю сделать большое обзорное видео про всё это. Будет ли вам такое интересно?

#cli #tui

⚡️ Concurrency Patterns. Fan In
В предыдущем посте мы немного напутали с определением такого многопоточного паттерна как Fan Out

На деле мы показывали Tee, который распространяет одно и то же значение V из канала-источника на N каналов-потребителей

Отличие Fan Out от Tee в том, что на N каналов распространяются разные значения из одного канала-источника. Тобишь, воркеры тянут значения из одного канала, борясь за них насмерть

Лирическое отступление закончено, наша совесть чиста, а сегодняшняя тема будет посвящена Fan In

Этот паттерн является обратным для Fan-Out. Мы собираем данные из нескольких каналов-источников и направляем их в один общий канал-потребитель


1. Default
Итак, что мы имеем?
— Есть воркеры — они кладут значения в N каналов и являются продьюсерами
— Каждый из этих N каналов будет получать значения от своего продьюсера. Назовем такие каналы "стоковыми"
— Есть один общий канал out, туда будет нужно отправить все значения из стоковых каналов
— Для этого мы запускаем N потоков, каждый из которых слушает свой стоковый канал, куда кладет значения продьюсер и редиректит все значения в out

Playground пример

Но что же будет, если какой-то наш продьюсер потух и больше не шлет никаких значений, а передаггый контекст не отменен? Как бы нам понять, что воркер не является активным и перезапустить его? — в этом нам поможет такой механизм как "Heartbeats"

Heartbeat — это регулярное сообщение от продьюсера/воркера, подтверждающее, что он жив и работает


2. Heartbeats
Приступим к рассмотрению этого чуда!

Основная идея проста:
— Имеем структуру, которая хранит в себе стоковый канал, используемый как пайп между воркером и стоком, и канал "сердцебиений"
— Функция Supervise ответственна за отслеживание "сердцебиений" и перезапуск воркера при их отсутствии по TTL
— Функция FanIn принимает на вход стоковые каналы и возвращает результирующий канал, из которого можно читать данные

Всмотримся в наши функции поподробнее

2.1. FanIn
— Не отклоняемся от цели: выкачиваем данные из стоковых каналов и перекладываем в out, реагируя на контекст и неблокирующе отправляя "сердцебиение" нашему супервизору, который пристально наблюдает за нашими воркерами
— WaitGroup здесь так же используется для того, чтобы дождаться конца работы наших стоков и отдать управление основному потоку
после дренажа всех "живых" значений

2.2 Supervise
— Создаем стоковый канал и канал "сердцебиений", агрегируем эти значения в структуре Source и возвращаем ее
— В отдельном потоке запускаем нашу рутину по отслеживанию и перезапуску воркеров

2.2.1 Смотрим на внутренности запущенного потока внутри Supervise
— Изначально происходит создание дочернего контекста с отменой для нашего воркера. Этот контекст будет рулить в тот момент, когда наш TTL пройдет и надо будет потушить воркера
— Создаем ticker, который будет слать ивенты, семантически значащие следующее: "в нашего воркера стреляли и он упал в лужу на..."
После получения ивента мы отменяем контекст и воркер окончательно "задыхается в луже"
— Первично запускаем работягу в отдельном потоке
— Если ловим ивент от тикера: производим отмену контекста, переназначаем этот же контекст и функцию отмены, сбрасываем таймер, и запускаем нового воркера в отдельном потоке
— В случае, когда из стокового потока нам пришло "сердцебиение" мы просто сбрасываем таймер и движемся дальше!

Стоит отметить, что воркеры должны "реагировать" на переданный контекст. Без этого мы получим утечку потоков и черт его знает, чем нам это грозит (профилированием и
устранением проблемы, которой можно было бы и избежать)

Таким образом, мы получаем более надежный Fan In, где все источники данных контролируемы и восстанавливаемы при зависаниях

Playground пример


Статью писали с Дашей: @dariasroom

Stay tuned 😏

🕵️‍♂️ Как Cloudflare нашли баг в компиляторе Go

- Источник
- Перевод

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

Заваривайте кофе или чаёк и устраивайтесь поудобнее, мы начинаем.. ☕️

Начало истории:

🟠Cloudflare обрабатывает 84 миллиона HTTP-запросов в секунду через 330 дата-центров. При таком масштабе даже самые редкие баги проявляются регулярно.

Один из сервисов начал спорадически паниковать на arm64-машинах с ошибкой "traceback did not unwind completely" — признак повреждения стека. Решили, что это редкая проблема с памятью и не стали копать глубже.

Но паники продолжились.

Первая теория:

- Все критические паники происходили при раскрутке стека
- Коррелировали с recovered panic
- В коде было старое использование panic / recover для обработки ошибок
- Есть похожий баг на GitHub

Убрали panic / recover — паники прекратились. Вздохнули с облегчением.

Но через месяц паники вернулись:

Теперь до 30 в день. Без recovered panics вообще. Никакой корреляции с релизами, инфраструктурой, или положением Марса 🪐

🕵️‍♂️ Расследование:

Все крэши происходили в (*unwinder).next — при раскрутке стека. Два типа:
1. Явная критическая ошибка от среды выполнения
2. SIGSEGV при разыменовании указателя

Заметили паттерн: все segfault'ы происходили при асинхронном вытеснении функции NetlinkSocket.Receive из библиотеки go-netlink.

Что такое асинхронное вытеснение:

До Go 1.14 планировщик был кооперативным — горутины сами решали, когда отдать управление. С 1.14 появилось асинхронное вытеснение: если горутина работает больше 10ms, среда выполнения отправляет SIGURG и принудительно вызывает asyncPreempt.

➡️ Так, для понимания этих деталей коротким ликбезом не отделаться, но у меня есть подробнейшие ролик и статья на эту тему. После них будете кристаллически ясно понимать суть, касательно планировщика, обещаю.

Прорыв:

Удалось получить дамп ядра и посмотреть в отладчике. Горутина была остановлена между двумя инструкциями в эпилоге функции:

nl_linux.go:779 0x555577cb287c ADD $80, RSP, RSP
nl_linux.go:779 0x555577cb2880 ADD $(16<<12), RSP, RSP
nl_linux.go:779 0x555577cb2884 RET

Вытеснение произошло между двумя ADD, которые корректируют указатель стека. Стек оказался в несогласованном состоянии!

Почему две инструкции ADD:

На arm64 непосредственный операнд в инструкции ADD — это 12 бит. Для больших значений компилятор разбивает на две операции: ADD $x, RSP и ADD $(y<<12), RSP. Если прерывание происходит между ними, RSP указывает в середину стека, а не на его вершину.

Простейшее воспроизведение:

//go:noinline
func big_stack(val int) int {
    var big_buffer = make([]byte, 1 << 16)
    // ... работа с буфером
}

func main() {
    go func() {
        for { runtime.GC() }
    }()
    for { _ = big_stack(1000) }
}

Функция со стековым кадром >64KB, GC в цикле для раскрутки стека, и бесконечные вызовы. Через пару минут — segfault!

Суть бага:

1. Асинхронное вытеснение между ADD x, RSP и ADD (y<<12), RSP
2. GC запускает раскрутку стека
3. Раскрутчик пытается прочитать родительский кадр по невалидному RSP
4. Крэш

Условие гонки в одну инструкцию. Невероятно редкий баг! 💎

Исправление:

Для стеков >4KB компилятор теперь сначала строит смещение во временном регистре, потом делает одну атомарную операцию ADD. Вытеснение может произойти до или после, но никогда не во время.

Исправлено в go1.23.12, go1.24.6 и go1.25.0.

————

Очень люблю такие истории! ✨
Месяцы расследования, работа с дампами ядра, изучение внутренностей среды выполнения и ассемблера. И в итоге — баг на уровне компилятора, который проявляется только при стечении обстоятельств: arm64 + большой стек + асинхронное вытеснение + GC + луна в правильной фазе

#compiler #debugging

Они до сих пор не знают 😩

🧙 Тёмные стороны Go — Обсуждаем с разработчиком GoLand

Ну что, 18-й выпуск GoGetPodcast, да? 🙃

Трансляция будет 01.11 (в эту субботу), а через пару дней выйдет запись в хорошем качестве и аудиоверсия, как обычно..

🟢Не забудьте подписаться на новый канал подкаста, ему сейчас очень нужна ваша поддержка.

————

Недавно у нас был выпуск с Арсением, где он рассказал много интересного про разработку GoLand. Получилось очень круто, я даже сам потом пересматривал

Во время разговора выяснилось, что у Арсения есть много вопросов к дизайну Go. Не абстрактных, а самых что ни на есть конкретных — про те места, где разработчики регулярно стреляют себе в ногу спотыкаются: nil-указатели, замыкания в горутинах, слайсы с их коварным append.

Эти темы не вписались в тот выпуск, но они явно заслуживали отдельного разговора, который сулил стать новым крутым выпуском. Особенно если позвать Глеба и Диму — наших постоянных гостей, с которыми мы недавно обсуждали Go v1.25. Мало кто может так же глубоко ответить на такие вопросы.

Да, критики Go хватает, все темы давно изъезжены. Но кто обычно критикует? Сами Go-разработчики которые давно уже привыкли и приняли правила игры? Или разработчики с других платформ, которые Go знают поверхностно?

А вот у Арсения — уникальная позиция. Он опытный инженер, но пишет на Kotlin. При этом работает над IDE для Go, то есть погружён в язык глубже многих гоферов и видит, где они чаще всего наступают на грабли. Ведь его работа — помогать им этого избегать. При этом он сохраняет свежий трезвый взгляд и спрашивает: «А почему вообще так устроено?»

Идеальная комбинация: глубокое знание языка и независимый, непредвзятый взгляд.

Что будем обсуждать:

— Nil safety в Go: почему компилятор не защищает и где это стреляет в проде (кстати, в недавнем выпуске Арсений рассказывал про новую фичу GoLand, которая помогает с этим бороться)
— Слайсы: append выглядит как иммутабельная операция, но мутирует данные
— Замыкания в горутинах: почему они ловят переменные по ссылке и как это приводит к классическим багам
— Shadowing переменных: визуально не отличишь, а линтер не всегда спасает
— Data races при чтении слайсов — да, даже при чтении
— Практические советы: как жить с этим в реальных проектах
И другое

⚠️ Важно:
Это не подкаст про хейт Go и не холивар «Go vs Kotlin».
Это честный технический разговор о трейдофах в дизайне языка — о местах, где Go поможет выстрелить в ногу, и о том, как этого избежать.

Ведь хороший инженер спрашивает не «почему тупые авторы этого не предусмотрели?», он спрашивает «ради чего они решили пойти на эту жертву?».

Состав:

- Николай Тузов
- Арсений Терехов — JetBrains, 👩‍💻 GoLand Team
- Глеб Яльчик
- Дима Матрёничев

💁‍♀️ Во время трансляции можно будет задавать вопросы в чате. Если есть что спросить прямо сейчас — пишите в комментах, мы возьмём самые интересные вопросы в эфир.

————

Предупреждение: после этого разговора ваши код-ревью станут более параноидальными. Но это к лучшему 😩

Заваривайте кофе, будет интересно ☕️

#golang #gogetpodcast

🦄 Новый выпуск GoGetPodcast уже на канале

https://youtu.be/8vdBg8jlx2M

Уже не в первый раз это говорю, но.. Пожалуй, это один из лучших выпусков нашего подкаста (что поделать, выпуски становится всё лучше и лучше).

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

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

🟠Напоминаю, что у подкаста теперь свой отдельный канал на YouTube, которому очень нужна ваша поддержка — если вы любите наш GoGetPodcast, подписывайтесь, ставьте лайки и смотрите выпуски до конца. Это поможет с алгоритмами продвижения.

————

Этот выпуск вышел при поддержке AvitoTech 💙

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

Только благодаря им выпуски теперь будут выходить стабильно и регулярно. Больше никакого ожидания по полгода! 👍

Ребята также ведут свой блог на хабре и проводят митапы. Недавно я делился их отличной статьей про обработку ошибок в Go.