Zig breaking change – Initial Writergate

As a hobby Zig developer, it's a bummer to see a breaking change in something so fundamental, but I get that's what I accept when building on a pre-1.0 language.

I hope that the Zig team invests more into helping with migration than they have in the past. My experience for past breaking changes is that downstream developers got left in the cold without clear guidance about how to fix breaking changes.

In Zig 0.12.0 (released just a year ago), there were a lot of breaking changes to the build system that the release notes didn't explain at all. To see what I mean, look at the changes I had to make[0] in a Zig 0.11.0 project and then search the release notes[1] for guidance on those changes. Most of the breaking changes aren't even mentioned, much less explained how to migrate from 0.11.0 to 0.12.0.

>Some of you may die, but that is a sacrifice I am willing to make.

>-Lord Farquaad

[0] https://github.com/mtlynch/zenith/pull/90/files#diff-f87bb35...

[1] https://ziglang.org/download/0.12.0/release-notes.html

This is why I'm surprised when production projects, like bun, choose to use zig. I don't think the language itself is a bad choice (although I do disagree qith some of the design decisions), but having to make substantial changes when there are breaking changes like this because the language is pre-1.0 every so often in a large code base isn't something I would want to deal with.

Zig just caught up with the practice that runs rampant in JavaScript land ;)

this comparison doesn't really make sense since JS as a language keeps a lot of old baggage to maintain backwards compatibility.

In reality it makes little difference whether source code needs to be fixed because of a breaking language or dependency update. Even in C/C++ I need to go over my code whenever I update to a new compiler version because of new warnings.