3 ms·

Hi Andrew. I once saw a video (at least I think it was a video) where you suggested the possibility of Zig reaching language stability in 2025. Is that still ac

Hi Andrew. I once saw a video (at least I think it was a video) where you suggested the possibility of Zig reaching language stability in 2025. Is that still accurate?

reactordev 3y ago
The Bun team I guess doesn't care and went ahead with 1.0 launch a few months ago. If they are willing to bet it all on zig, I'm sure it will be around for a while. It's quite mature as it stands now. Personally, I think the road to zig 1.0 should be made methodically and without any timeline.
- charlotte-fyi 3y ago
  I don't know that this is an endorsement of zig rather than an indictment of bun.
  - reactordev 3y ago
    Total endorsement - thanks for forcing clarification.
- fl0ki 3y ago
  I don't recommend choosing technologies this way. Elm is one of many recent, prominent examples of how years of promising language work can still leave production users stranded, both with backwards-incompatible changes that are deal-breakers for many projects, and then stalling further updates anyway even for the users still able to use the latest version. I'm not saying Zig will go the same way, I hope it succeeds. But success in industry funding is not a guarantee, successful transition to large team contributions is not a guarantee, and even if all of that does pan out, by then the language may be markedly different. Look at Rust in 2012 vs its 1.0 in 2015 and ask yourself if you'd want you and your team to have to make so many changes to production code. Ask yourself how many unknown costs you are willing to risk in exchange for whatever you believe is the actual upside of using Zig for a particular project. Sure, somebody has to break that cycle by making those bets, but be sure before deciding to be among them. Somebody else making that bet only changes the odds so much.
  - reactordev 3y ago
    Except I’m referring to an ecosystem built on top of zig. Not Zig proclaiming to solve the web’s problems. There’s two teams here that say “we think zig is good”. One, the language team (your Elm reference), the other, the bun team (and all that js ecosystem). I’m pretty confident in saying that it’s not just some plaything or niche language. Then again, I can’t predict the future and it could very well be that bun and zig both blow up. Same could be said for Rust.
    - fl0ki 3y ago
      I know what you mean but it's not that simple. The ecosystem clearly depends on the language in a very real way. If Zig changed enough to be a deal breaker for Bun, or even stopped being maintained at all, then Bun is stranded until they can move to a completely different language. (I'm not even willing to entertain the notion that they would fork Zig and maintain it long term. Even if they somehow did which would be nuts on its own, they'd still be cut off from the rest of the ecosystem and lose out on that front.) My best case for Zig is that it offers a worthwhile option to clean up existing C & C++ projects without incurring, or at least deferring, the more substantial costs of rewriting outright in Rust, bindings or no. "Maintain it in Zig" is a sensible value proposition, or at least it will be once that Zig code has a compatibility promise so it's not trading one maintenance cost for another. Look at how costly it was for the ecosystem to migrate from Python 2 to Python 3, even despite how many participants in that ecosystem were themselves large, well-funded corporations. Situations like that are why Go and Rust have made permanent 1.0 compatibility promises even at the cost of some tech debt which they know will only accrue further. Zig will too, but it hasn't yet, and anybody adopting it now risks unknown migration costs. > Then again, I can’t predict the future and it could very well be that bun and zig both blow up. Same could be said for Rust. Sure, lots of things are possible, but ask yourself which is more likely. That's all I'm saying here. Rust has already been where Zig is now and is in a meaningfully different place today: a stability promise and substantial industry adoption and contribution. It no longer depends on any one person and a lot of investment is going in to its continued success. Anything can still fail, but there aren't that many examples of languages outright failing after reaching this point in industry adoption. There are many examples of languages outright failing by pushing backwards-incompatible changes on the industry right in the middle of what should have been a healthy growth curve. There are also many examples of simply not offering enough marginal value to justify their marginal costs. The title here is "C++, D, and Rust" and, I'm sorry to say, but one of these is not like the other ones. Zig will have a lot of work to do in order to end up more like Rust than D, especially when memory and thread safety are a big part of why the industry is adopting Rust in the first place. Notice how Chromium does not have a Zig branch just like it never had a D branch. It was all C++ until Rust offered clear improvements to safety in exchange for its adoption costs.
- pjmlp 3y ago
  They also made a 1.0 release without Windows support, so that already says a lot about what they care about.

Hi Andrew. I once saw a video (at least I think it was a video) where you suggested the possibility of Zig reaching language stability in 2025. Is that still accurate?

reactordev 3y ago

The Bun team I guess doesn't care and went ahead with 1.0 launch a few months ago. If they are willing to bet it all on zig, I'm sure it will be around for a while. It's quite mature as it stands now. Personally, I think the road to zig 1.0 should be made methodically and without any timeline.

charlotte-fyi 3y ago
I don't know that this is an endorsement of zig rather than an indictment of bun.
- reactordev 3y ago
  Total endorsement - thanks for forcing clarification.
fl0ki 3y ago
I don't recommend choosing technologies this way. Elm is one of many recent, prominent examples of how years of promising language work can still leave production users stranded, both with backwards-incompatible changes that are deal-breakers for many projects, and then stalling further updates anyway even for the users still able to use the latest version. I'm not saying Zig will go the same way, I hope it succeeds. But success in industry funding is not a guarantee, successful transition to large team contributions is not a guarantee, and even if all of that does pan out, by then the language may be markedly different. Look at Rust in 2012 vs its 1.0 in 2015 and ask yourself if you'd want you and your team to have to make so many changes to production code. Ask yourself how many unknown costs you are willing to risk in exchange for whatever you believe is the actual upside of using Zig for a particular project. Sure, somebody has to break that cycle by making those bets, but be sure before deciding to be among them. Somebody else making that bet only changes the odds so much.
- reactordev 3y ago
  Except I’m referring to an ecosystem built on top of zig. Not Zig proclaiming to solve the web’s problems. There’s two teams here that say “we think zig is good”. One, the language team (your Elm reference), the other, the bun team (and all that js ecosystem). I’m pretty confident in saying that it’s not just some plaything or niche language. Then again, I can’t predict the future and it could very well be that bun and zig both blow up. Same could be said for Rust.
  - fl0ki 3y ago
    I know what you mean but it's not that simple. The ecosystem clearly depends on the language in a very real way. If Zig changed enough to be a deal breaker for Bun, or even stopped being maintained at all, then Bun is stranded until they can move to a completely different language. (I'm not even willing to entertain the notion that they would fork Zig and maintain it long term. Even if they somehow did which would be nuts on its own, they'd still be cut off from the rest of the ecosystem and lose out on that front.) My best case for Zig is that it offers a worthwhile option to clean up existing C & C++ projects without incurring, or at least deferring, the more substantial costs of rewriting outright in Rust, bindings or no. "Maintain it in Zig" is a sensible value proposition, or at least it will be once that Zig code has a compatibility promise so it's not trading one maintenance cost for another. Look at how costly it was for the ecosystem to migrate from Python 2 to Python 3, even despite how many participants in that ecosystem were themselves large, well-funded corporations. Situations like that are why Go and Rust have made permanent 1.0 compatibility promises even at the cost of some tech debt which they know will only accrue further. Zig will too, but it hasn't yet, and anybody adopting it now risks unknown migration costs. > Then again, I can’t predict the future and it could very well be that bun and zig both blow up. Same could be said for Rust. Sure, lots of things are possible, but ask yourself which is more likely. That's all I'm saying here. Rust has already been where Zig is now and is in a meaningfully different place today: a stability promise and substantial industry adoption and contribution. It no longer depends on any one person and a lot of investment is going in to its continued success. Anything can still fail, but there aren't that many examples of languages outright failing after reaching this point in industry adoption. There are many examples of languages outright failing by pushing backwards-incompatible changes on the industry right in the middle of what should have been a healthy growth curve. There are also many examples of simply not offering enough marginal value to justify their marginal costs. The title here is "C++, D, and Rust" and, I'm sorry to say, but one of these is not like the other ones. Zig will have a lot of work to do in order to end up more like Rust than D, especially when memory and thread safety are a big part of why the industry is adopting Rust in the first place. Notice how Chromium does not have a Zig branch just like it never had a D branch. It was all C++ until Rust offered clear improvements to safety in exchange for its adoption costs.
pjmlp 3y ago
They also made a 1.0 release without Windows support, so that already says a lot about what they care about.