Возвращение к Zig

Пост Анны Либерти (Anna Liberty) от июня 2026 года на gracefulliberty.com, где она описывает свой путь от Zig к Rust и обратно. Самое интересное здесь то, что ни один из переходов не определялся самим языком: ушла она из-за постоянных поломок между релизами, а вернулась из-за того, как проект Rust повёл себя в споре о правилах сообщества.

Почему она ушла

Она начала писать на Zig в 2020 году, перейдя с C после доклада Эндрю Келли (Andrew Kelley) Software Should Be Perfect. Явная и способная завершиться ошибкой аллокация, отсутствие скрытого потока управления, универсальная переиспользуемость - эти свойства стали тем, что она стала искать везде. О том, как это устроено в языке, см. zig, а о механизме, лежащем в основе понравившихся ей абстракций, - comptime.

Затем Zig стал регулярно ломать её код. Будучи студенткой, она могла месяцами не открывать проект, и каждое возвращение требовало непонятного рефакторинга просто ради того, чтобы проект снова начал собираться. Это было ещё до того, как anyzig упростил работу с несколькими версиями тулчейна на одной машине. Ситуация с библиотеками усугубляла проблему: пакетов мало, примеров для обучения мало, абстракции стандартной библиотеки менялись каждый раз, когда она думала, что наконец их поняла, а документация и сама была нестабильной.

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

Почему она вернулась

Её технические претензии к Rust привычны: сложный FFI, раздражающая кросс-компиляция, скрытые и непадающие аллокации памяти, а также охват платформ, ограниченный возможностями LLVM. В сноске от 2026-07-06 она несколько смягчает последний пункт после того, как читатели указали на реальную работу над альтернативными бэкендами.

Настоящей причиной возвращения стало управление проектом (governance). Она упоминает корпоративных членов Rust Foundation и влияние, которое эти деньги предположительно покупают, но спусковым крючком стал эпизод с политикой в отношении LLM. Zig запретил вклад сгенерированного LLM кода на корню - аргументация этого запрета разобрана в contributor-poker, а его заметная цена показана в simonw-zig-anti-ai. Rust провёл опрос, выждал время, а затем опубликовал предложение с правилом модерации, запрещавшим комментарии в PR на четыре темы: долгосрочные социальные и экономические последствия LLM, воздействие на экологию, авторские права на выдачу LLM и моральные оценки тех, кто их использует. После волны возмущения правило отозвали. Её позиция состоит в том, что сами по себе правила нормальные и рабочие, а вред нанесла попытка запретить обсуждение. Этот эпизод - ещё один пример паттерна, описанного в anti-llm-discourse, и относится к тому же классу проблем, что и maintainer-governance-ambiguity: люди потеряли доверие не к коду.

Zig в 2026 году

Язык всё ещё нестабилен, и она говорит об этом прямо. Примеры в сети для версии 0.16.0 уже устарели, когда она пыталась их запустить; ожидается, что 0.17.0 сломает систему сборки вообще во всех проектах. Взамен за терпение к этой нестабильности предлагается zig-incremental-compilation - пересборка за 50-70 мс, но только на ветке master или в 0.17 и только для x86_64-linux. Её рабочий подход - держать открытыми исходники стандартной библиотеки; она советует это как самый быстрый способ войти в рабочий ритм.

Две вещи стали лучше. Сам язык с 2020 года изменился мало, так что интуиция не подвела, а незнакомый код библиотек читался легко. Кроме того, появился пакетный менеджер, подтягивающий зависимости из git и тарболов с работающим вендорингом, что заменило памятные ей субмодули git. Официального реестра всё ещё нет, но она считает это осознанным решением, а не упущением.

Раздел о безопасности памяти

Она признаёт, что Zig не даёт гарантий Rust, и формулирует разницу как безопасность на уровне режима сборки (release mode), а не на уровне блока кода. ReleaseSafe падает при непрошедших assert'ах и инициализирует всю память; Келли предлагал пойти дальше и поставлять ReleaseSafe с чем-то вроде fil-c под капотом. Задуманный рабочий процесс состоит в том, чтобы тестировать и гонять фаззинг в ReleaseSafe, пока не вычистится всё некорректное поведение, а в продакшен отдавать более быстрый режим. В ReleaseFast проверки перестают быть проверками и превращаются в допущения, которые оптимизатор вправе использовать; выигрыш от этого есть только тогда, когда тесты действительно доказали недостижимость этих путей.

Её аргумент не в том, что такой подход превосходит аффинные типы, а лишь в том, что платить за сложность аффинных типов имеет смысл не всегда. И когда вы всё равно пишете unsafe Rust, Zig оказывается безопаснее из двух вариантов. В dayvster-manual-memory-management этот же компромисс сопоставляется для C, Zig, Odin, C3 и Rust; а в zig-functional-programmers показан обратный путь: приход в Zig не из C, а из Haskell.