logoalt Hacker News

lernoyesterday at 3:09 PM0 repliesview on HN

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