> 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.