Приятно видеть, что эту проблему наконец-то решают. Это место в семантике языка годами было общеизвестным «костылем». В языке есть и другие скрытые странности, требующие внимания, например, семантика продвижения целых чисел (integer promotion).

Что касается стабильности: сообщество Zig уже привыкло к поломкам между версиями 0.x. В отличие от конкурентов вроде Odin или моего C3, здесь нет цели минимизировать проблемы при обновлении.

Это вопрос культуры: внедрить внятный процесс устаревания (deprecation) не составило бы труда, но в сообществе Zig это просто не ценится. Напротив, быстрая адаптация к изменениям — своего рода повод для гордости.

Я часто говорю об управлении ожиданиями, и это отличный пример.

В дискуссиях часто звучит ложный аргумент: «Zig еще не версии 1.0, так что поломки ожидаемы». Но есть разные подходы к изменениям, и Zig явно в лагере тех, кто «не заботится о сокращении объема работы» для пользователя.

Если смотреть объективно, в Zig сложилась традиция перекладывать всю работу по обновлению на плечи разработчика. Часто звучит мнение, что «поломки делают язык лучше, поэтому они полезны».

Безусловно, изменения нужны, но люди вне сообщества Zig ожидают, что это будет делаться бережнее (через периоды устаревания и т.д.).

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

Это значит, что библиотеки и приложения на Zig продолжат быстро «протухать» (bitrot) без постоянной поддержки.

Для сравнения: Odin (9 лет) по сути уже достиг 1.0 и стабилен несколько лет.

Возможно, это объясняет разницу в реальном «выхлопе». Например, игр на Odin я знаю в 5–10 раз больше, чем на Zig. При этом пользователей у Zig в 5–10 раз больше. Значит, вероятность появления готовой игры у пользователя Odin в 20–100 раз выше.

Этому есть разные объяснения: доступность SDL/Raylib в Odin выше (но почему тогда Zig менее дружелюбен?), возможно, в Odin лучше программисты (но почему они выбирают его?), или на Odin проще писать ресурсоемкие приложения (что тогда делать с заявлениями Zig об оптимальности?).

Если отбросить оправдания («поломки легко чинить», «это еще не 1.0») и хайп («Zig безопаснее C», «я очень продуктивен на Zig») и сравнить его с Odin по реальной продуктивности, стабильности и скорости компиляции (ни C3, ни Odin не требуют сотни гигабайт кэша для быстрой сборки на LLVM), то Zig выглядит не особо выигрышно.

Даже `build.zig`, который часто хвалят, усложняет жизнь новичку («чтобы собрать Hello World, сначала пойми этот нетривиальный скрипт»). Для IDE конфигурация сборки внезапно оказывается спрятана за непрозрачным кодом. Эти компромиссы редко обсуждают, так как и критика, и хайп обычно поверхностны.

Что ж, комментарий затянулся.

Закончу на позитиве: сообщество Zig приятное и гостеприимное. Так что если хотите попробовать Zig — пробуйте, не позволяйте чужому мнению (включая мое) вас останавливать.

Но если решите сравнить Zig с конкурентами, рекомендую смотреть на D, Odin, Jai и C3.

> Not at all, if the team needs 30 more years they should take it.
Yes, I understand that is the opinion in the Zig community. As an outsider, it seems odd to me to pick a language that I constantly need to maintain.

>> However, the outlook for a Zig 1.0 is bleak from what I gather from Zig social forums: the most optimistic estimate I’ve heard is 2029 for 1.0.

> Funny you see it as bleak when most of the community sees it as the most excitinh thing in systems programming happening right now.

You misread that one. I was talking about the odds of seeing a 1.0 version of Zig soon.

> I think you comment is in bad faith, all the big zig projects say that the upgrade path is never a main concern, just read HN comments here or on other zig threads, people ask about this a lot and maintains always answer.

Maybe you didn't read what I wrote carefully enough. This is part of the protectiveness from the Zig community that prompted me to write in the first place.

WITHIN the Zig community it is deemed acceptable for Zig upgrades to break code. Consequently it becomes simple survivor bias that people who use Zig for larger projects don't think that this is a major concern BECAUSE IF THEY FELT IT WAS A CONCERN THEY WOULD NOT USE ZIG.

Whether programmers at large feel that this is a problem is an unknown still, since Zig has not yet reached to point of general adoption (when people use Zig because they have to, rather than because they want to).

However, it is INCORRECT to state that just because a language is not yet 1.0 it needs to break older code aggressively without deprecation paths. As an example, Odin removed the old `os` module and replaced it with the new "os2". This break was announced half a year in advance and lots of thought was put into reducing work for developers: https://odin-lang.org/news/moving-towards-a-new-core-os/

In the case of C3, breaking changes only happen once a year with stdlib going through the general process of deprecating functions long before removing them.

I wanted to highlight how these are quite different approaches. For established languages, this is of course even more rigorous, but neither C3 nor Odin are 1.0, and still see this as valuable and their communities then end up expecting it.

So please understand that when you say "it's never a main[sic] concern", this is simple survivor bias.

> — Ни в коем случае. Если команде нужно еще 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.