Hacker News Digest

Команда проекта ROC переписала около трёхсот тысяч строк кода, написанного на Rust, на язык Zig, чтобы создать новый компилятор. После полугода работы они достигли полной функциональности, что позволило запустить игру Rocci Bird, написанную на Roc, в браузере через WebAssembly. Размер скомпилированного wasm‑файла сократился до 31 КБ, тогда как прежний компилятор генерировал бинарник более чем в два раза больше. Для этого в новый компилятор были внедрены важные возможности: поддержка новых конструкций, улучшенный тип‑cheker и система разрешения лямбд. Благодаря этим изменениям проект получил более компактный и быстрый код, а также более предсказуемую модель памяти.

Следующий шаг — выпуск версии 0.1.0 нового компилятора к концу года, при этом ночные сборки уже доступны для тестирования. Автор отмечает, что более ста примеров из курса Exercism были обновлены, а команда благодарна за помощь Anthony Bullard, Sam Mohr, Jared Ramirez и других, которые доработали парсер, тип‑cheker и систему разрешений. Проект поддерживается фондом ROC, принимающим пожертвования; средства идут на оплату разработчиков. Если вы хотите помочь, вы можете присоединиться к обсуждениям в Zulip или стать спонсором.

Обсуждение добавляет к статье различные мнения о выборе языка для проекта Roc, включая опыт эксплуатации, возражения и цифры из практики. Комментарии подтверждают, что команда проекта выбрала Zig из-за его incremental builds и контроля памяти, но также высказываются мнения о том, что Rust мог бы быть улучшен для достижения аналогичных результатов.

• Спор: Некоторые участники обсуждения сомневаются в необходимости перехода на Zig, указывая на то, что Rust мог бы быть улучшен для достижения аналогичных результатов. @onlyrealcuzzo считает, что incremental builds Zig - это killer feature, но задается вопросом, можно ли ожидать появления аналогичной функциональности в Rust в ближайшем будущем.

• Совет: @lioeters предлагает добавить borrow checker к Zig вместо ожидания более быстрого компилятора в Rust.

• Участники обсуждения согласны с тем, что incremental builds Zig - это значительное преимущество. @KoleSeise1277 считает, что 35ms incremental rebuild - это то, что продает Zig.

• Спор: @norir и @munificent спорят о том, что производительность компилятора определяется алгоритмами, а не языком программирования. @norir утверждает, что его опыт показывает, что алгоритмы доминируют над производительностью компилятора.

• Совет: @dnautics упоминает проект clr, который пытается объединить безопасность Rust с features Zig.

This piece would have been a lot more compelling if they had actually done science on selecting a language for compiler development. From what I can tell, they had an untested hypothesis that a low level systems language is necessary for a high performance compiler… — @norir

Anthropic активно продвигает сценарий, что программирование исчезнет, а за ним последует исчезновение большинства человеческого труда, при этом привлекает более 130 млрд долларов инвестиций и планирует IPO стоимостью>$1 трлн, что делает её историю «ненадёжным рассказчиком». Этот амбициозный нарратив уже формирует решения в архитектуре, продукте и персонале, часто основываясь на страхе потери работы.

В центре спора — переход Bun, когда‑то написанного на Zig, в Rust. Bun заявлял о почти 100 % AI‑генерации кода, тогда как Zig официально запрещает использование ИИ, но в реальности код был «переписан» в unsafe Rust и быстро слит в основную ветку. Создатель Zig Эндрю Келли публично отреагировал резким, почти «меланхоличным» ответом, назвав ситуацию «переполохой», но многие читатели нашли в нём честный крик. Оценка этой истории требует скептицизма: миграция оказалась выгодной для обеих сторон, а детали остаются предметом интерпретаций. Bun был одной из крупнейших кодбаз на Zig, а его founder экспериментировал с агентным переписыванием, которое привлекло внимание СМИ и породило заголовки о «быстром AI‑переписывании». Этот процесс показывает, как крупные компании используют споры, чтобы формировать восприятие технологий, тогда как реальная проблема — сложность управления памятью в Zig.

• Обсуждение спора между сторонниками Zig и Rust حول перенос проекта Bun, включая критику стиля и мотивов авторов.
• Участники отмечают, что перенос в Rust был использован как маркетинговый ход Anthropic, а не чисто техническим улучшением.
• Вызываются вопросы о конфликте интересов, поскольку Zig‑сообщество открыто враждебно к ИИ‑генерируемому коду.
• Дебат подчёркивает разницу между созданием конечных продуктов и инструментарием/языками, а также роль человеческого контроля в AI‑помощных проектах.

Когда стартап, построенный вокруг JavaScript‑раннера, получил инвестиции, его подход резко изменился: вместо свободного развития он стал гоняться за быстрым выходом на рынок, а управление превратилось в «гонку», где требовалось «grind» даже в первые девять месяцев. Основатель публично заявлял, что «Oven будет тяжёлым», и требует от команды работать без баланса, что вызвало бурю недовольства среди бывших соискателей и сотрудников, которые описывали его как «плохого менеджера» с нереалистичными требованиями и низкой эмпатией.

В то же самое время качество кода в проекте ухудшалось: в репозитории скопилось множество костылей, злоупотребление ассертами и спешка в добавлении функций приводили к росту технического долга и рискам памяти, что вызывало критику со стороны сообщества Zig, где безопасность стала главным аргументом отстранения от проекта. Несмотря на ежегодную поддержку в размере $60 000, после покупки компанией Anthropic доноры прекратили встречи и пожертвования, оставив фонд без средств. Поэтому команда приветствовала переписывание на Rust, считая её шансом избавиться от «недостойственного» примера и вернуть доверие. Эта ситуация стала катализатором для перехода на Rust, который воспринимался как возможность очистить репозиторий и восстановить репутацию языка среди разработчиков.

• Автор обвиняет Джейрда в нечестности и личных нападках, несмотря на заявления о нейтральности.
• Обсуждается несоответствие заявлений о фузинге Zig и реальном отсутствии его использования в Bun.
• Критики считают пост эмоциональным, непофессиональным и ухудшающим имидж Zig.
• Есть мнение, что фокус на личных конфликтах мешает конструктивному техническому анализу.
• Некоторые видят в этом попытку монетизации или PR‑продвижения, а не объективный разбор.

Bun изначально появился как Zig‑порт esbuild, получивший сразу набор функций: транспилятор JavaScript/TypeScript, пакетный менеджер, тест‑раннер, HTTP‑клиент и др. За год он стал скачиваться более 22 млн раз в месяц и поддерживается компаниями Vercel, Railway, DigitalOcean и другими. Однако из‑за низкоуровневого кода на Zig в проекте накопилось множество критических багов — use‑after‑free, утечки памяти, гонки, которые приходилось фиксировать вручную.

Переписав ядро на Rust, команда добавила AddressSanitizer, постоянно запускает fuzzing и выпускает безопасные Release‑Safe‑билды. Это позволило полностью устранить use‑after‑free, утечки в crypto.scrypt, tlsSocket.setSession и другие уязвимости, а также сократить размер бина и ускорить warm‑install в 7 раз. Rust‑реализация обеспечивает системную защиту от подобных ошибок, делает Bun более надёжным и готов к дальнейшему развитию.

• Исключительно быстрый переход от Zig к Rust с помощью Claude Code, протестировавшего 100 % тестов за 11 дней.
• Стоимость переписывания оценивается в $165 000 токенов, что дешевле найма полноценной команды.
• Критика направлена на отсутствие открытого анализа проблем, а не на эмоции; многие отмечают рост надёжности и уменьшение размера бинарника.
• Дискуссия подчёркивает, что такой подход возможен только при наличии зрелых тест‑сьютов и опыта автора, а также вызывает вопросы о долгосрочной поддержке и выборе стека.

Он объявил о новом обязательстве в размере 400 000 долларов для Zig Software Foundation, доведя общий вклад до 700 000 долларов после первой поддержки в 2024 году; эта сумма распределяется на два года по 200 000 долларов в год.

Он хвалит Zig за стабильный прогресс в сложных задачах языка и компилятора, а также за инициативы типа Contributor Poker, запрет на LLM‑модели в вкладах и культуру, привлекающую талантливых разработчиков. Несмотря на личную активную позицию по ИИ и споры вокруг форка Bun, он подчеркивает, что политика фонда, хотя и не совпадает со всеми взглядами, сохраняет уважительную и независимую атмосферу. Zig — исключительный продукт, без которого проекты вроде Ghostty были бы невозможны, и поддержка такого языка — вклад в будущее, где качество и независимость важнее массового признания. Поэтому он призывает тех, кто может, способствовать развитию Zig через пожертвования. Таким образом, поддержка Zig не только финансово, но и способствует развитию языка, который сочетает амбициозность, полезность и строгий контроль качества, позволяя создавать инструменты, как Ghostty, в экосистеме, где проекты могут задавать свои правила.

• Mitchell Hashimoto пожертвовал $700 000 в фонд Zig Software Foundation, что обеспечивает стабильное финансирование разработки Zig.
• Участники обсуждают, как важно поддерживать проекты без зависимости от LLM‑технологий и сохранять «нормальность» в сообществе.
• Мнения о Zig варьируются: многие хвалят его дизайн и удобство, другие отмечают проблемы с документацией и синтаксисом.
• Есть и позитивные отзывы о новых инструментах на базе Zig (Ghostty, Dirac) и о возможности использовать Zig в разных проектах.

Zig мигрирует основной репозиторий с GitHub на Codeberg из-за деградации платформы после продажи Microsoft в 2018 году. GitHub стал медленным и buggy (перегружен JS-фреймворками), Actions — ненадёжным ("vibe-scheduling" заданий, backlog даже на master, баги без фиксов). Плюс связь с ICE и нарушения строгой no-LLM/no-AI политики из-за навязчивого Copilot. Вместо трат на обход CI-проблем, выбрали смену хостинга.

GitHub Sponsors — ключевой доход ZSF, но признан liability; просят донаторов перейти на non-profit Every.org, перки (имя на главной/релизах) переносят туда. Миграция: GitHub read-only, canonical — codeberg.org/ziglang/zig. Issues/PRs оставляют на GitHub (не мигрировать, продолжают мониторить), на Codeberg нумеруют с 30000. Благодарности Forgejo/Codeberg: Earl Warren, Otto, Gusted, Mathieu Fenniak. Non-profits — оплот от платформенного капитализма.

• Zig мигрирует с GitHub на Codeberg из-за связей с ICE, AI-спама и падения качества; пост критикуют за оскорбления разработчиков ("обезьяны", "неудачники").
• Поддержка миграции как шага к независимости от Microsoft и продвижению Forgejo/Codeberg.
• Критика Codeberg: слабая инфраструктура, низкая скорость, проблемы доступности (CAPTCHA для screen reader).
• Смешанные реакции: энтузиазм тренду ухода с GitHub, но сомнения в стабильности для крупных проектов.

Zigbook предлагает уникальный подход к изучению языка программирования Zig через 61 главу проектно-ориентированного курса. Ресурс позиционирует себя как не просто руководство по синтаксису, а фундаментальное изменение мышления о программном обеспечении. "Вы пришли за синтаксисом, уйдете с философией" — эта цитата отражает суть методики, где акцент делается на глубоком понимании принципов, а не только на изучении языка. Курс создан человеком с ником @zigbook без использования ИИ-контента.

Интерактивная платформа включает встроенный терминал для немедленного практического применения знаний. Проект построен на самом Zig, как демонстрирует команда сборки "zig build zigbook". Доступ к курсу осуществляется через сайт zigbook.net, где пользователи могут сразу начать вводить команды в интерактивном окне для погружения в изучение языка.

• Обсуждение в основном вращается вокруг обвинений в том, что книга по Zig написана ИИ, и что это противоречит заявлению о «ручном» написании и отсутствии ИИ-контента.
• Участники обсуждения подчеркивают, что стиль текста и структура главы выглядят как будто их написал ИИ, и что это вызывает сомнения в достоверности всей книги.
• Некоторые комментаторы также указывают на то, что книга не предоставляет PDF-версии, что делает ее менее удобной для чтения.
• Некоторые участники обсуждения также поднимают вопрос о том, что Zig может быть не стоит изучать, если у вас уже есть опыт с C, Rust или Go, и что книга не предоставляет достаточно убедительного «почему» изучать этот язык.

Zig - это не просто замена C или C++, а совершенно новый подход к программированию, который удивил автора с 45-летним опытом. Самые впечатляющие особенности языка - встроенная возможность компилировать C-код и кросс-компиляция "из коробки", что уже оказывает значительное влияние на индустрию.

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

• Статья преувеличивает инновативность Zig, не подкрепляя заявления о "революционности" реальными уникальными фичами.
• Пользователи отмечают практические преимущества: простота установки (через PyPI), кросс-компиляция, явный синтаксис и компиляция C-кода.
• Критика включает отсутствие безопасности памяти, спорные решения (политика идентификаторов, отсутствие данных в ошибках) и сравнение с Rust/Ada как более зрелых альтернатив.
• Отдельные хвалят метапрограммирование (comptime), простоту навигации по коду и удобство для низкоуровневого программирования.
• Обсуждение подчеркивает субъективность восприятия: для одних Zig "меняет подход к программированию", для других — лишь "улучшенный C" без уникального позиционирования.

В 2025 году обновился инструмент ucs-detect для проверки поддержки Unicode в эмуляторах терминалов, теперь тестирующий DEC Private Modes, sixel-графику, размер пикселей и версию ПО. Методика проверки основана на отправке видимого текста с последующими управляющими последовательностями для определения позиции курсора, с сравнением результатов со стандартом Python wcwidth. Основная проблема эмуляторов — корректное отображение широкого спектра Unicode-символов в фиксированной сетке без нарушения читаемости.

Лидером тестов стал новый эмулятор Ghostty, разработанный с нуля на языке Zig и показавший наилучшую поддержку Unicode. Почти не уступил ему Kitty, реализовавший алгоритм разбиения текста, близкий к спецификации Python wcwidth. Оба эмулятора корректно поддерживают Variation Selector 15. Среди неожиданных результатов — низкая производительность: iTerm2 и Extraterм потребляли чрезмерное количество CPU, а GNOME Terminal на базе VTE работал более 5 часов. Полные результаты доступны на сайте проекта.

• Терминалы варьируются от полной поддержки Unicode до полного отсутствия поддержки, что делает выбор сложным, особенно для пользователей, которым важна поддержка Unicode.
• Некоторые эмуляторы, такие как Konsole, поддерживают широкий спектр Unicode, в то время как другие могут не поддерживать даже базовые символы.
• Пользователи, которым важна поддержка Unicode, должны тщательно выбирать терминал, так как не все эмуляторы поддерживают Unicode.
• Поддержка Unicode в терминалах может варьироваться от полной поддержки до полного отсутствия поддержки, что делает выбор сложным для пользователей, которым важна поддержка Unicode.

Zig представил новую асинхронную систему ввода-вывода, которая войдет в версию 0.16.0 через 3-4 месяца. Новый интерфейс std.Io позволяет писать асинхронный код с помощью ключевых слов async и await, декопируя вызов функции от ее возврата. Как и аллокаторы, std.Io настраивается один раз в main() и передается через приложение. В примерах показана эволюция от простого синхронного кода до полноценного асинхронного, где операции могут выполняться параллельно, сокращая реальное время выполнения.

Система включает реализацию на основе потоков (std.Io.Threaded), которая позволяет выполнять две односекундные операции за одну секунду реального времени. Примеры демонстрируют обработку ошибок в асинхронном контексте - при возникновении ошибки в одной из задач, другие продолжают выполняться. Новый подход делает код более выразительным и эффективным, позволяя Zig-приложениям лучше использовать современные возможности операционных систем.

• Zig's async model is a radical departure from traditional async/await, emphasizing explicit I/O objects and no hidden control flow, but it has sparked debate on whether this is the right direction for the language.
• The discussion revealed that the lack of a standard async runtime and the decision to make the async/IO interface a public API has raised concerns about ecosystem fragmentation and the burden on library authors.
• Participants questioned whether the new model truly solves the "function color" problem or merely shifts it to a different place, and whether it will be able to scale to the ecosystem.
• The debate also touched on the risk of fragmentation if the community fails to converge on a de-facto standard library for async I/O, and the potential for a "left-pad" moment if the ecosystem becomes too fragmented.
• Some expressed concern that the lack of a blessed standard library could lead to a situation where "every game ships its own copy of DirectX" in the form of vendored async implementations, which could be a barrier to adoption.

Автор изначально не интересовался Zig, считая его нишевым языком для аудиопрограмм, но решил переписать индекс AcoustID на Zig как возможность изучить новый язык. Результат превзошёл ожидания — новая версия оказалась быстрее и масштабируемее, чем предыдущая на C++. Однако при добавлении серверного интерфейса возникли сложности с сетевыми возможностями Zig, что привело автора к созданию библиотеки Zio — асинхронной I/O и библиотеки для конкурентности в стиле Go.

Zio реализует стековые корутины с фиксированным размером стека, поддерживает асинхронную сетевую и файловую I/O, примитивы синхронизации и каналы в стиле Go. Главная особенность — контекстный переключение практически бесплатен, сравним с вызовом функции. В однопоточном режиме Zio обгоняет все протестированные фреймворки, включая Go и Rust Tokio. Интересно, что благодаря стандартным интерфейсам reader/writer, внешние библиотеки могут использоваться без модификаций, даже не зная, что работают внутри Zio.

• Обсуждение показало, что Zig не имеет встроенной поддержки async/await, а вместо этого используется библиотечный код, что вызывает вопросы о том, как это скажется на производительности и удобстве использования.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.

Synadia и TigerBeetle совместно выделили $512,000 на поддержку Zig Software Foundation в течение двух лет. Synadia, создатель NATS.io, помогает крупным предприятиям проектировать и масштабировать архитектуры в облаке и на периферии, обслуживая клиентов в финансовой сфере, электронной коммерции, гейминге и промышленном IoT. TigerBeetle, финансовая база данных, разработанная на Zig с философией "TigerStyle", подчеркивает правильность, ясность и надежность.

Основатель Synadia Дерек Коллисон отметил, что Zig переопределяет возможности современного системного программирования благодаря своему подходу к контролю, производительности и простоте. Основатель TigerBeetle Йоран Дирк Гриф выразил уверенность, что Zig сыграет основополагающую роль в следующем поколении надежных распределенных систем. Обе компании разделяют видение предсказуемого, простого и заслуживающего доверия программного обеспечения, поддерживая Эндрю Келли и весь Zig-сообщество.

• Оценивали Rust, Zig и Ada/SPARK для критически важного ПО; Rust имеет поддержку корпорации и сообщества, но не применяется в кибер-физических системах.
• TigerBeetle получил $512k в течение 2 лет от Synadia и TigerBeetle, что вызвало вопросы о стратегии финансирования и приоритете языков.
• Обсуждение вылилось в обмен любезностями и техническими деталями, включая предположения о переходе на Zig и оставлении Rust без должной поддержки.

Компиляция Zig становится значительно быстрее благодаря многолетней работе над оптимизацией компилятора. Например, сборка скрипта build.zig в версии 0.15 заняла всего 1,7 секунды против 7,2 секунд в версии 0.14. Полная сборка проекта Ghostty без кеша сократилась с 41 до 32 секунд, даже с использованием LLVM.

Особенно впечатляет скорость инкрементных сборок: пересборка библиотеки libghostty-vt после изменения одной строки теперь занимает менее секунды (975 мс против 2,9 секунд ранее). Это уже ощутимо ускоряет рабочий процесс, а в будущем, с отказом от LLVM и внедрением инкрементной компиляции, результаты станут ещё лучше — ожидаются миллисекундные задержки.

• LLVM рассматривается как ловушка из-за сложности тонкой настройки финальных оптимизаций и линковки, несмотря на преимущества в скорости начальной разработки и поддержке платформ. Cranelift и другие бэкенды могут стать альтернативой.
• Zig фокусируется на скорости компиляции для разработки, используя собственный бэкенд для debug-сборок (x86_64) и LLVM для релизов. Есть баги, но инструментарий ценится за простую кросс-компиляцию и статическую линковку.
• Быстрая компиляция (TCC, Go, Vlang) важна для итеративной разработки, но trade-off с оптимизацией кода неизбежен. Интерпретаторы или JIT-компиляция (Julia) предлагают альтернативы для интерактивности.
• Интеграция Zig с системами сборки (Bazel) возможна через правила, но Turing-полные скрипты сборки могут усложнить кеширование. Библиотеки часто обходятся без кастомных скриптов.
• Поддержка платформ (OpenBSD) требует доработки низкоуровневого IO (kqueue). Статическая линковка зависимостей в Zig упрощает деплой, но динамические библиотеки (libc, GUI) остаются.

TigerBeetle — это финансовый транзакционный движок, построенный на принципах, противоположных общепринятым: медленная разработка кода, детерминированное симуляционное тестирование и нулевые зависимости. Вместо SQL он использует примитивы дебета и кредита, что соответствует изначальной цели транзакционных систем — обеспечению бизнес-операций, как описал ещё Джим Грей в 1985 году.

Традиционные SQL-базы требуют 10–20 запросов для обработки одной финансовой транзакции, создавая узкие места, особенно при работе с «горячими» счетами. TigerBeetle, написанный на Zig, предлагает распределённую архитектуру по умолчанию, статическое выделение памяти и assertions в продакшене. Это ответ на растущие потребности в мгновенных платежах и реальном биллинге, где скорость и надёжность критичны.

• Участники обсуждают технические особенности TigerBeetle, включая его специализацию на финансовых операциях, детерминированное тестирование и минималистичный подход к зависимостям.
• Высказываются критические замечания: отсутствие поддержки многопоточности для масштабирования, проблемы с аутентификацией и совместимостью с облачными платформами, такими как Cloudflare Workers.
• Поднимается вопрос о потенциальной предвзятости статьи, так как её автор является инвестором проекта.
• Отмечается, что традиционные SQL-базы данных по-прежнему эффективно справляются с большинством задач, несмотря на возраст.
• Обсуждаются возможные аналоги TigerBeetle, такие как FoundationDB, и его применимость за пределами финансового сектора.

Разработчик Mitchell Hashimoto анонсировал libghostty — библиотеку для встраивания полнофункционального терминала в любые приложения. Первым компонентом станет libghostty-vt: легковесная библиотека без зависимостей (включая libc) для парсинга терминальных последовательностей и управления состоянием терминала. Она извлечена из ядра Ghostty и предлагает оптимизированную обработку Unicode, поддержку SIMD и совместимость с продвинутыми протоколами вроде Kitty Graphics.

Проблема в том, что многие проекты (редакторы, веб-консоли, хостинги) реализуют эмуляцию терминала с нуля, часто с ошибками и неполной функциональностью. Libghostty-vt устраняет эту избыточность, предоставляя единое корректное и быстрое решение. Библиотека будет портирована на macOS, Linux, Windows, embedded-устройства и WASM, что шире, чем охват самого Ghostty.

• Пользователи высоко оценивают Ghostty за его производительность, минималистичный дизайн и поддержку Zig, но отмечают отсутствие некоторых ключевых функций, таких как поиск (Cmd+F) и проблемы с рендерингом шрифтов.
• Многие выражают восхищение разработчиком Mitchell Hashimoto, его предыдущими проектами (Vagrant) и его подходом к созданию простых и эффективных систем.
• Анонс библиотеки libghostty вызвал интерес для использования в embedded-сценариях (игры, кастомные приложения, веб-терминалы) и как потенциальная замена существующим библиотекам.
• Некоторые пользователи столкнулись с проблемами совместимости, особенно с tmux и графическими протоколами, что мешает им полностью перейти с iTerm2 или других терминалов.
• Обсуждаются технические детали, такие как лицензирование (MIT vs LGPL), поддержка Unicode и сравнение с другими терминалами (Kitty, Alacritty, WezTerm).

Zig предлагает более простой подход к созданию CLI-инструментов по сравнению с Rust, особенно когда речь идёт о работе с памятью. В Rust строгий borrow checker предотвращает ошибки на этапе компиляции, но часто вынуждает переписывать код под его требования, усложняя разработку. Например, при попытке добавить новую запись в список, одновременно удерживая ссылки на существующие, компилятор Rust блокирует действие из-за конфликта владения и заимствования.

В Zig же разработчик напрямую управляет памятью через аллокаторы, используя указатели и мутацию без сложных правил времён жизни. Это требует дисциплины, но даёт больше гибкости и скорости написания кода. Для CLI-инструментов, где производительность и простота часто важнее абсолютной безопасности памяти, Zig оказывается практичнее. Безопасность — это не только отсутствие ошибок памяти, но и читаемость, скорость разработки и соответствие задаче.

• Обсуждение затрагивает проблемы безопасности в C, связанные с ручным управлением памятью, и ироничные комментарии по этому поводу.
• Пользователи делятся мнениями о современных языках (Nim, Odin, V, D, Zig), отмечая их преимущества, такие как интероперабельность с C и гибкость в управлении памятью.
• Уточняется функциональность Zig: он не компилируется в C, но имеет инструмент для трансляции C-кода в Zig, при этом компилируясь напрямую в машинный код.
• В обсуждении присутствует юмористический тон относительно утверждения, что разработчики не являются идиотами.

Новый интерфейс std.Io.Reader в Zig может приводить к неопределённому поведению при использовании с буфером произвольного размера. Например, при передаче ридера из zstd-декомпрессора в функцию вывода с буфером 64 байта код либо аварийно завершается в режиме отладки, либо зацикливается в релизе. Проблема в том, что некоторые ридеры требуют конкретного размера буфера у писателя, но это требование не всегда очевидно или документировано.

Ситуация усугубляется тем, что сбой может зависеть от входных данных: с одними данными код работает, с другими — нет. Это создаёт риски для библиотек, где тип ридера неизвестен заранее, например, при обработке HTTP-заголовков. Автор спрашивает, не ошибся ли он, но если нет — это серьёзный изъян в дизайне API.

• Обсуждается потенциальная проблема безопасности или баг в Zig, но участники склоняются к тому, что это скорее единичная ошибка, а не системная уязвимость.
• Участники дискутируют о ценностном предложении языка Zig, описывая его как современную альтернативу C с лучшей эргономикой, компиляцией во время выполнения (comptime), явным управлением памятью и меньшим количеством неопределённого поведения.
• Критикуется реакция создателя Zig, Эндрю Келли, на конструктивную критику, которую некоторые участники сочли резкой и недружелюбной.
• Zig позиционируется как мощный инструмент для низкоуровневого программирования с ультранизкой задержкой (например, для HFT или игр), где безопасность не является приоритетом, в противовес Rust.
• В качестве альтернатив для модернизации C++ упоминаются другие языки, такие как Carbon.

Как устроен bun install

• Один бинарник — весь менеджер зависимостей живёт внутри Bun, нет внешних вызовов к npm, yarn, node-gyp.
• Сишный движок — парсинг package.json, yarn.lock, node_modules происходит на Zig, без JS-оверхеда.
• HTTP-пул + кэш — 50–100 параллельных потоков, кэш на диске + SQLite-индекс, повторный install — <100 мс.
• Symlink-ферма — модули не копируются, а hard-link’ются из глобального кэша; экономия 70 % диска.
• Муравьиный алгоритм — сначала скачиваются «листья» дерева зависимостей, потом родители; сеть греется максимально.
• Платформенные пакеты — если в lock-файле есть запись под Linux, macOS и Windows, скачиваются сразу три архива и раскладываются в node_modules/.cache, при запуске выбирается нужный.
• postinstall без shell — скрипты запускаются встроенным JS-движком, нет overhead’а на spawn bash/cmd.
• Проверка целостности — каждый tarball сверяется по SHA256 из lock-файла, кэш защищён от подмены.
• Мониторинг прогресса — терминал обновляется раз в 16 мс, рисуется ASCII-полоса и счётчик «пакетов/сек».
• Фоллбек к npm — если пакет не найден в официальном реестре, Bun автоматом лезет в npm и кладёт tarball в кэш, пользователь не замечает разницы.

• Пользователи обсуждают статью о внутреннем устройстве и производительности менеджера пакетов Bun.
• Многие хвалят скорость и простоту Bun, но отмечают проблемы совместимости с Node.js и стабильностью.
• Часть комментаторов сомневается в практической пользе высокой скорости установки пакетов и считает переход с Node.js рискованным.
• Упоминаются альтернативы — Deno, pnpm, npm — и сравнение с ними по скорости и надёжности.
• Некоторые считают, что Bun не предлагает «убийственных» фич, чтобы оправдать переход с зрелой экосистемы Node.js.

Ghostty GTK-часть переписана с нуля
Проект завершён: Linux/BSD-версия теперь полностью использует GObject из Zig и проверена Valgrind.

Что изменилось

• Zig-структуры обёрнуты в GObject; память управляется счётчиками ссылок.
• При обновлении конфига старый объект освобождается автоматически, когда исчезают ссылки.
• Появились сигналы, свойства, действия GTK и современные UI-файлы Blueprint.
• Новые виджеты добавляются быстрее (анимированная рамка, вкладки в заголовке и т.д.).

Valgrind Каждый коммит прогонялся под Valgrind.

• Потребовался большой suppression-файл (в основном GTK/драйверы).
• Найдены: утечка и неопределённое обращение в Zig-коде, ошибка WeakRef в GTK, которые иначе вызывали редкие краши.

• Ghostty переписывает GUI на GTK/Zig, столкнувшись с проблемами GObject и управления памятью.
• Участники обсуждают, что GTK навязывает свою ООП-модель и счётчики ссылок, что сложно сочетать с Zig/Rust.
• Некоторые считают GTK не «родной» на Linux и предлагают Vala, Qt или собственный UI.
• Пользователи жалуются на баги прокрутки, копирования, nano и отсутствие поиска.
• Автор признаёт выбор GTK компромиссом ради кроссплатформенности и «родного» вида.

Zig выглядит почти как Rust, но делает синтаксис ещё приятнее за счёт более простой семантики и ряда изящных решений.

Числа
Литералы 92 всегда имеют тип comptime_int; при присваивании они неявно приводятся к нужному типу. Суффиксов нет.

Строки
Многострочные «сырые» строки пишутся через \\ в начале каждой строки; \ не экранируется, отступы не портятся, а лексер работает построчно.

Структуры
.{ .x = 1, .y = 2 } — запись поля через .x = совпадает с присваиванием, что позволяет грепом находить именно записи, а не чтения.

Типы
Все типы префиксные: u32, [3]u32, ?[3]u32, *const ?[3]u32. Разыменование постфиксное: ptr.*.

Идентификаторы
Синтаксис @"имя с пробелом" позволяет обходить ключевые слова и экспортировать любые имена.

Функции
fn add(x: i32, y: i32) i32 — без стрелки ->, так как лямбд нет, а возвращаемый тип всегда обязателен. pub fn main() void {}.

Переменные
const и var; часто используемое const короче, чем в Rust, но всё же длиннее Kotlin-овского val.

• Обсуждение разделилось: кому-то синтаксис Zig кажется «прекрасным» минимализмом, другим — «шумным» и «капризным».
• Спор о порядке «имя: тип» vs «тип имя»: одни хотят видеть тип первым, другие — имя.
• Критика деталей: @-префиксы, .{}, отсутствие лямбд, перенос строк, orelse без пробела.
• Плюсы: raw-строки Zig решают проблему отступов; обработка ошибок через try нравится многим.
• Сравнения: Kotlin, C#, Go, Rust, D — каждый считает «своё» лучше.
• Итог: «красота» синтаксиса субъективна и во многом привычна; после практики Zig начинает нравиться.

Debian GNU/Hurd 2025 — неофициальный релиз Debian, но официальный порт.
Основан на «sid» в момент выхода «Trixie».

• ISO: hurd-i386 | hurd-amd64
• Образы и инструкции: hurd-install

Архитектуры: i386, amd64; покрытие ~72 % архива Debian.

Новое

• 64-бит полностью готов, драйверы дисков через Rump (NetBSD).
• xattr по умолчанию для трансляторов; mmdebstrap из других ОС.
• Порт Rust, USB-диски и CD через Rump.
• SMP, xkb-раскладки, framebuffer, acpi, rtc, apic, hpet.
• Исправления irqs, nfsv3, libports, pipes и др.

Документация

• FAQ
• Translator primer

Присоединяйтесь: contributing

• Hurd — давний проект с микроядром Mach, фактически движимый одним человеком (Samuel Thibault), и сегодня выглядит скорее хобби-экспериментом, чем реальной альтернативой Linux.
• Участники обсуждают низкую поддержку железа, архаичную архитектуру и отсутствие прогресса: «ждать совершенства — значит никогда не стать готовым».
• Предлагаются новые микроядра (seL4, L4, Viengoos) и языки (Rust, Zig), но критика считает это погоней за хайпом.
• GUIX/Nix и GNU Shepherd упоминаются как более живые GNU-ориентированные проекты; GUIX уже умеет запускать Hurd в виртуалке.
• Итог: Hurd остаётся интересным музейным экспонатом и источником идей, но не готов к «повседневному» использованию.