> — Ни в коем случае. Если команде нужно еще 30 лет — пусть берут.

Да, я понимаю, что в сообществе Zig это норма. Но мне как человеку со стороны кажется странным выбирать язык, код на котором мне придется постоянно «чинить» и допиливать.

>> — Однако перспективы Zig 1.0 туманны, судя по форумам: самый оптимистичный прогноз на релиз, что я слышал — 2029 год.
> — Забавно, что вы видите это в мрачном свете, тогда как большинство считает это самым захватывающим событием в системном программировании прямо сейчас.

Вы меня не так поняли. Я говорил исключительно о шансах увидеть версию 1.0 в обозримом будущем.

> — Мне кажется, ваш комментарий написан с долей предвзятости (bad faith). Все крупные проекты на Zig говорят, что процесс обновления никогда не стоит во главе угла. Просто почитайте комментарии на HN или в других ветках — люди постоянно об этом спрашивают, и мейнтейнеры всегда отвечают.

Возможно, вы не слишком внимательно прочли мои слова. Это как раз та самая «защитная реакция» сообщества Zig, которая и заставила меня написать этот пост.

ВНУТРИ сообщества Zig считается нормальным, что обновления ломают код. Следовательно, это чистой воды **ошибка выжившего**: люди, использующие Zig в больших проектах, не считают это проблемой просто ПОТОМУ ЧТО ЕСЛИ БЫ ОНИ СЧИТАЛИ ЭТО ПРОБЛЕМОЙ, ОНИ БЫ НЕ ИСПОЛЬЗОВАЛИ ZIG.

Считают ли программисты «в массе своей» это проблемой — вопрос открытый, так как Zig еще не дорос до стадии общего принятия (когда на языке пишут потому, что *надо*, а не потому, что очень *хочется*).

Однако НЕВЕРНО утверждать, что отсутствие версии 1.0 дает карт-бланш на агрессивную поломку старого кода без внятных путей миграции (deprecation paths). К примеру, в Odin заменили старый модуль `os` на новый `os2`. Об этом объявили за полгода, и было вложено много сил, чтобы облегчить жизнь разработчикам: https://odin-lang.org/news/moving-towards-a-new-core-os/

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

Я хотел подчеркнуть, насколько это разные подходы. У зрелых языков правила еще строже, но ни C3, ни Odin еще не вышли в 1.0, и тем не менее они дорожат стабильностью, а их сообщества привыкают ожидать этого по умолчанию.

Так что поймите: когда вы говорите «это никогда не является основной проблемой», это просто классическая ошибка выжившего.

[…] I was able to make incremental compilation sort of work on the LLVM backend. It is now passing all of the incremental tests, so I have enabled them all for x86_64-linux-llvm.

I have also removed the warning which the compiler printed when using -fincremental in combination with the LLVM backend.

I have not tested this support extensively! It is possible that in practice, there are bugs when using -fincremental with the LLVM backend. If anyone encounters any, please do open an issue.

This release of Zig upgrades to LLVM 18.1.7.

This was the primary motivation for tagging the 0.13.0 release.

This release features 8 months of work: changes from 244 different contributors, spread among 1183 commits.
Perhaps most notably, this release debuts I/O as an Interface, but don't sleep on the Language Changes or enhancements to the Compiler, Build System, Linker, Fuzzer, and Toolchain which are also included in this release.

What we did need, however, was a Git server implementation that could run on Cloudflare Workers. It needed to be small, as complete as possible, extensible (notes, LFS), and efficient. So we built one in Zig, and compiled it to Wasm.