[jamiejquinn]

The article's claim of Zig being a "totally new way to write programs" is quite mad but I'd like to make a different claim: Zig's own development is a totally new way of writing programming languages (or is at least very rare).

While I don't wholly agree with all choices made by Andrew and the Zig team, I greatly appreciate the care with which they develop features. The slow pace of deliberating over features, refining them, and removing unnecessary ones seems in sharp contrast to the development of any other langauge I'm aware of. I'm no language historian though, happy to be challenged.

[SleepyMyroslav]

I am not sure if a slow pace is as beneficial as you say. I scrolled through the error handling issue brought up in this comment section ( https://github.com/ziglang/zig/issues/2647#issuecomment-2670... ) and its clear that only thing that happened there was communication on the issue was hindered. I come from C++ side and our "ISO C++ committee" language development process leaves a lot to be desired. Now look at error handling that they did passed in C++23 ( std::expected ). It raises some questions on how slow you can be while still appearing to be moving forward.

Disclaimer: I would like to see Zig and other new languages to become a viable alternatives to C++ in Gamedev. But I understand that it might happen way after me retiring =)

[sesm]

In terms of programming language development, take a look at Clojure. The clarity of reasoning behind every decision is unmatched.

[iLemming]

I second that. Clojure is really a great joy to use. It may take a while to shift into the mindset, especially for someone new to Lisp, but after a while it's an absolute delight.

A great degree of occasional criticism of Clojure typically comes from brief exposure - either from not using structural editing idioms, misunderstanding REPL-driven workflows, or confusion around "the type system". Of course, Clojure being dynamically/strongly typed, doesn't really have a type system in the traditional sense, yet it has mechanisms that provide type-like guarantees, and from pragmatic point-of-view those instruments are incredibly robust.

[brabel]

It seems pretty common to me?! Java is developed that way. So is Rust. And many others. What exactly do you see as different in Zig?

[murkt]

Java and Rust have surpassed 1.0 version a long time ago, so they don’t remove features left and right on each feature release.

Not that it’s a bad thing. Python removes stuff, and it takes time to upgrade to new versions.

[Milpotel]

And Zig has surpassed 1.0 or where is the argument?

[murkt]

Zig has not surpassed 1.0 and explicitly strives to remove features, which Java and Rust don’t do anymore. That’s why it feels different.

[koeng]

I don’t think Java and Rust were so ok with completely removing features. For example, in Zig 0.15 they completely overhauled the io, meaning all libraries now have to rewrite up usage. Just to make sure they did it right

[kibwen]

> I don’t think Java and Rust were so ok with completely removing features.

This just shows that you weren't around for pre-1.0 Rust. Back then Rust was infamous for the language making breaking changes every week. Check out this issue from 2013 tracking support for features which were deprecated but had yet to be removed from the compiler: https://github.com/rust-lang/rust/issues/4707 , and that's just a single snapshot from one moment in Rust's prehistory.

[reichstein]

Semantic major/minor version 0.15 means it's still in development. It's not supposed to be stable. Going from 0.14 to 0.15 allows breaking changes.

Try making a similar change between version 5.0 and 6.0, with hundreds of thousands of existing users, programs, packages and frameworks that all have to be updated. (Yes, also the users who have to learn the new thing.)

[otabdeveloper4]

> Just to make sure they did it right

Let me guess: they didn't, and now there is a third-party "right" way to do it.

(We've been here before, many times.)