It’s good to see that this is finally addressed. It’s been a well known broken part of the language semantics for years.
There are similar hidden quirks in the language that will need to be addressed at some point, such as integer promotion semantics.

To address the question about stability: the Zig community are already used to Zig breaking between 0.x versions. Unlike competitors such as Odin or my own C3, there is no expectation that Zig is trying to minimize upgrading problems.

This is a cultural thing, it would be no real problem to be clear about deprecations, but in the Zig community it’s simply not valued. In fact it’s a source of pride to be able to adapt as fast as possible to the new changes.

I like to talk about expectation management, and this is a great example of it.

In discussions, it is often falsely argued that ”Zig is not 1.0 so breaks are expected” in order to motivate the frequent breaks. However, there are degrees to how you handle breaks, and Zig is clearly in the ”we don’t care to reduce the work”-camp.

If someone is trying to get a more objective look at the Zig upgrade path, then it’s worth keeping in mind that the tradition in Zig is to offload all the work on the user.

The argument, which is frequently voiced, is that ”breaking things will make the language get better and so it’s good that there are language breaks”

It is certainly true that breaking changes are needed, but most people outside of the Zig community would expect it to be done with more care (deprecation paths etc)

Secondly, it should perhaps be a concern for Zig, now at 10 years old, to still produce solidly breaking code every half year.

10 years is the common point where languages go 1.0. 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.

This means that in the future, projects using Zig can still expect any libraries and applications to bitrot quickly if they are not constantly maintained.

Putting this in contrast with Odin (9 years old) which is essentially 1.0 already and has been stable for several years.

Maybe this also explains the difference in actual output. For example the number of games I know of written in Odin is somewhere between 5 to 10 times as many as Zig games. Now weighing in that Zig has maybe 5 or 10 times as many users, it means Odin users are somewhere between 20-100 times as likely to have written a playable game.

There are several explanations as to why this is: we could discuss whether the availability of SDL, Raylib etc is easier on Odin (then why is Zig less friendly?), maybe more Odin has better programmers (then why do better programmers choose Odin over Zig), maybe it’s just easier to write resource intensive applications with Odin than Zig (then what do we make of Zig’s claim of optimality?)

If we look past the excuses made for Zig (”it’s easy to fix breaks” ”it’s not 1.0”) and the hype (”Zig is much safer than C” ”Zig makes me so productive”) and compare with Odin in actual productivity, stability and compilation speed (neither C3 nor Odin requires 100s of GB of cache to compile in less than a second using LLVM) then Zig is not looking particularly good.

Even things like build.zig, often touted as a great thing, is making it really hard for a Zig beginner (”to build your first Hello World, first understand this build script in non-trivial Zig”). Then for IDEs, suddenly something like just reading the configuration of what is going to be used for building is hidden behind an opaque Zig script. These trade-offs are rarely talked about, as both criticism and hype is usually based on surface rather than depth.

Well, that’s long enough of a comment.

To round it off I’d like to end on a positive note: I find the Zig community nice and welcoming. So if you’re trying Zig out (and better do that, don’t let others’ opinions - including mine - prevent you from trying things out) do so.

If you want to evaluate Zig against competitors, I’d recommend comparing it to D, Odin, Jai and C3.

Приятно видеть, что эту проблему наконец-то решают. Это место в семантике языка годами было общеизвестным «костылем». В языке есть и другие скрытые странности, требующие внимания, например, семантика продвижения целых чисел (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.