←back to thread

228 points Retro_Dev | 1 comments | | HN request time: 0.212s | source
Show context
mtlynch ◴[] No.44463570[source]
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

replies(4): >>44465077 #>>44465184 #>>44466320 #>>44471188 #
1. Szpadel ◴[] No.44471188[source]
I never wrote single line of zig code, but I follow it as an interesting language, so I might be missing something fundamental.

I agree that this looks extremely breaking, and feel like providing no compatibility layer fragments community, especially when you might have some unmaintained dependency somewhere that will never be updated.

there were similar situations when in rust some core libraries decided to alter its interfaces.

but I believe rust approach with editions is brilliant and could be adapter to other languages like zig.