i UNIRONICALLY cannot wait to break my projects moving them to 0.17. this is not a dig on zig, this is just a fact of the matter when it comes to language that is still under 1.0. i’m happy to be building and breaking as i continue the journey with the zig community. btw the removal of ** for @splat did throw me, but i guess it doesn’t give up any features. started last night with hum and will have a new version of that releasing very soon. i am definitely targeting x86_64 and genuinely excited about incremental compilation.
9 Likes
for some odd reason, seeing the Zig compilor errors gives a good feeling. ig because the error messages are just too good
2 Likes
Moving to 0.17.0 has been way less painful for me than 0.16.0.
5 Likes
for sure, the time spent on it was well worth it.
1 Like
agree, it definitely has.
1 Like
Im excited to turn fuzzing in CI on for 0.17 
5 Likes
I also like breakages.
It means I get to spend some quality time with old code, updating it to the new version, and at the same time - armed with new knowledge I’ve gained since I last touched it - fixing any bad decisions, getting rid of bugs, revising the design… In my opinion, upgrading to a new version of Zig is always time well-spent.
(But maybe I’m a little biased, I do have a lot of time and patience for this after all)
5 Likes
When I was getting into more serious projects in Zig, I was fully aware of breakages, and thought that I can tolerate it, but I honestly, after experiencing it twice, I am not sure about it anymore.
As time goes on my project(s) getting bigger and harder to upgrade. I had to change my engine’s build.zig (and some other stuff) when I was upgrading from 0.15.2 to 0.16.0 and now I need to do it again for 0.17.0. For this upgrade, if I decide to upgrade my engine, I also need to check every @bitCast usage. I have to upgrade my applications (that are using my engine), and its dependencies as well. Thankfully my engine is only depending on core C APIs and some parts of Zig’s stdlib. Though I cannot say that for my applications.
TLDR; Although it is an upgrade(in a positive way), this is boring and time consuming.
2 Likes
i can say that i also enjoy breaking things and learning from it. though honestly with this most recent change, despite how large it was, did not break nearly as much. very neat.
that’s a valid feeling. i can understand it not being your favorite part of programming in a still evolving language.
Every breakage is one step closer to stability.
I think 0.15.1 was the most challenging upgrade in the history of the project, past and future, because of Writer and Reader fundamentally changing. 0.16.0 breakage probably affected the most number of users due to std.Io, but it’s not that hard to add a new parameter to function calls. 0.17.0 I think is a relatively easy upgrade, except for those who were doing sketchy things in build.zig. As we get closer to 1.0 I expect the breakage to be fewer and less impactful, especially after the efforts to stabilize std lib begin, which hasn’t happened yet.
22 Likes
It’s a fun experience, but I still didn’t have to struggle that much since all my projects are small. I just followed Migration guide section on Changes documentation and everything went well.
I faced more issues migrating projects to 0.16.0 than migrating it to 0.17.0
2 Likes
no complaints from me man, i’m just enjoying the ride
1 Like
110% accurate
The migration to 0.17.0 was fairly painless for my project, got it done in one evening (although the project is still pretty small so that probably helps). Most of the head scratching for me was moving to the external translate-c package, most of that was learning how dependencies work in general with zig fetch.
4 Likes
Same experience as everyone, I was doing a lot of things in my build.zig (about 1k lines) but needed to change quasi nothing ! The caching system immedialty worked for me and improved a lot the build workflow
It is sitting on an open branch for the time being as freestanding (the compiler_rt) doesn’t compile yet
2 Likes
I’ve been upgrading since around 0.10 and I have to say 0.16.0 was one of the most tedious for me. I hope you won’t lose hope though. The code gets better every time, but other than that they’re not all the same and 0.17.0 was one of the easiest - I think ‘zig fmt’ took care of all the @bitCast calls for me.
1 Like
my experience porting one of my projects, hum, to 0.17. spoiler, it broke way less than anticipated, and i was hyped and prepared for it.
for hum, @cImport going away resulted in some reallocation. previously, hum had one shared libc import (basically a workaround for freebsd translate-c issues in 0.16). swapping it wound up being the cleanest part of upgrading. there are no C headers anywhere anymore. honestly, the freebsd problems appear to be gone. i went a step further and stopped linking libmpv as well. it was a dozen declared functions, filled with dlsym. plus, the build no longer requires anything besides zig. one runner cross compiles everything. lovely.
everything else didn’t effect the port quite as much:
**to@splatdupeZtodupeSentinel(u8, s, 0),bufPrintZtobufPrintSentinel(..., 0)b.argstorun_cmd.addPassthruArgs()@typeInfo(T).@"struct".fieldsto.field_names/.field_typesstd.ascii.indexOfIgnoreCasetofindIgnoreCasezig fmtturned@intFromEnuminto@backingInt, same experience as@bitCast
v0.1.8 of hum is out on 0.17. i’ve linked it in the op already, so no need to do it twice.
2 Likes