Hacker News Reader

Comment by Aurornis | Hacker News Reader

> Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes.

This is a solved problem in other projects. Either use the version numbers as intended and bump the major version number on breaking changes, or use Rust-style editions to opt in to the newer versions of the changes.

Calling a project production-ready but keeping the version number below 1.0 and saying breaking changes are expected is a tired game. We've seen it backfire across a number of language projects like Elm, where the exact same claim was used to both encourage people to use it and then blame them when it backfired.

If it's production ready, go to 1.0 and then follow semver for breaking changes. I don't care if we get to Zig v73.2.0 as a result. At least we can see from a glance which versions need to be checked for breaking changes.

View on HN

languages ideally should not have breaking changes ever.

on the other hand, a language with frequent breaking changes should not be considered production ready.

people are of course free to live on the edge, and if someone decided that zig is good enough and they are not bothered by breaking changes then they are free to use it for their production system, but that doesn't mean it's ready for everyone. so i prefer the zig approach.

> languages ideally should not have breaking changes ever.

I disagree MIGHTILY. This is how you wind up with C++ and Java.

Languages need to be able to remove features to stay coherent. Occasionally, you get things wrong, it takes time to figure that out, and that's just the way life is.

different preferences i guess. i much prefer language stability. the idea that i should have to test my code with every python version out there for example is disturbing, but there are tools to do exactly that. they should not be needed.

The solution to this is editions/epochs, like Rust. You can set your project to the 2025 edition and be sure that, even if future versions introduce breaking changes, they will not affect your project; it will continue to compile as before.

pike has that. or had it. for two decades. inline in the code, in each file you could specify the version. they decided to drop it because of the maintenance overhead.

You can continue to compile as before by using a previous version of the Zig compiler. You even get a 100% byte-for-byte match with reproducible builds.

Why are we so obsessed with updating dependencies, and at the same time, not willing to put in the work to update our own code?

The result of Zig’s approach is that the ecosystem of packages is very active, quickly updating to use the latest language features, and with a good foundation of tests that catch regressions.

Why are we so obsessed with updating dependencies, and at the same time, not willing to put in the work to update our own code?

because i want to benefit from the improvements/bug fixes in the dependencies, whereas updating my own code does not bring any improvements (unless it is taking advantage of a new feature in the dependencies) and for a large project can be very expensive.

more practically for my work, i need to be able to compile my application with a compiler that is actively supported, but i have no budget to rewrite old code just because the compiler developers decided to break old functionality.

i'd like to add, there are many things that can be criticized on C++ or java. but language stability is not one of them. in fact i believe language stability is one of the things that keeps both languages an ongoing success.

Reply on news.ycombinator.com