3 ms·

IME Zig's breaking changes are quite manageable for a lot of application types since most of the breakage these days happens in the stdlib and not in the langua

IME Zig's breaking changes are quite manageable for a lot of application types since most of the breakage these days happens in the stdlib and not in the language. And if you just want do read and write files, the highlevel file-io interfaces are nearly identical, they just moved to a different namespace and now require a std.Io pointer to be passed in. And tbh, I take a 'living' language any day over a language that's ossified because of strict backward compatibility requirements. When updating a 3rd-party dependency to a new major version it's also expected that the code needs to be fixed (except in Zig those breaking changes are in the minor versions, but for 0.x that's also expected). I actually hope that even after 1.x, Zig will have a strategy to keep the stdlib lean by aggressively removing deprecated interfaces (maybe via separate stdlib interface versions, e.g. `const std = @import("std/v1");`, those versions could be slim compatibility wrappers around a single core stdlib implementation.

pron 9mo ago
> I take a 'living' language any day over of a language that's ossified because of strict backward compatibility requirements Maybe you would, but >95% of serious projects wouldn't. The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace, where low-level languages are commonly used, codebases typically last for over 30 years), and while such changes are manageable early on, they become less so over time. You say "strict" as if it were out of some kind of stubborn princple, where in fact backward compatibility is one of the things people who write "serious" software want most. Backward compatibility is so popular that at some point it's hard to find any feature that is in high-enough demand to justify breaking it. Even in established languages there's always a group of people who want somethng badly enough they don't mind breaking compatibility for it, but they're almost always a rather small minority. Furthermore, a good record of preserving compatibility in the past makes a language more attractive even for greenfield projects written by people who care about backward compatibility, who, in "serious" software, make up the majority. When you pick a language for such a project, the expectation of how the language will evolve over the next 20 years is a major concern on day one (a startup might not care, but most such software is not written by startups).
- flohofwoe 9mo ago
  > The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace). Either those applications are actively maintained, or they aren't. Part of the active maintenance is to decide whether to upgrade to a new compiler toolchain version (e.g. when in doubt, "never change a running system"), old compiler toolchains won't suddenly stop working. FWIW, trying to build a 20 or 30 year old C or C++ application in a modern compiler also isn't exactly trivial, depending on the complexity of the code base (especially when there's UB lurking in the code, or the code depends on specific compiler bugs to be present - e.g. changing anything in a project setup always comes with risks attached).
  - pron 9mo ago
    > Part of the active maintenance is to decide whether to upgrade to a new compiler toolchain version Of course, but you want to make that as easy as you can. Compatibility is never binary (which is why I hate semantic versioning), but you should strive for the greatest compatibility for the greatest portion of users. > FWIW, trying to build a 20 or 30 year old C or C++ application in a modern compiler also isn't exactly trivial I know that well (especially for C++; in C the situation is somewhat different), and the backward compatibility of C++ compilers leaves much to be desired.
  - strawhatguy 9mo ago
    You could fix versions, and probably should. However willful disregard of prior interfaces encourages developers code to follow suit. It’s not like Clojure or Common Lisp, where a decades old software still runs, mostly unmodified, the same today, any changes mainly being code written for a different environment or even compiler implementation. This is largely because they take breaking user code way more seriously. Alot of code written in these languages seem to have similar timelessness too. Software can be “done”.
- andrepd 9mo ago
  I would also add that Rust manages this very well. Editions let you do breaking changes without actually breaking any code, since any package (crate) needs to specify the edition it uses. So when in 30 years you're writing code in Rust 2055, you can still import a crate that hasn't been updated since 2015 :)
epolanski 9mo ago
Sure, but considering that Zig is a modern C alternative, one should not and cannot afford to forget that C has been successful also because it stayed small and consistent for so long. The entire C, C ABI and standard lib specs, combined, are probably less words than the Promise spec from ECMAScript 262. A small language that stays consistent and predictable lets developers evolve it in best practices, patterns, design choices, tooling. C has achieved all that. No evolving language has anywhere near that freedom. I don't want an ever evolving Zig too for what is worth. And I like Zig. I don't think any developer can resolve all of the design tensions a programming language has, you can't make it ergonomic on its own. But a small, modern, stable C would still be welcome, besides Odin.
- bbkane 9mo ago
  Besides Odin? Does Odin give you most of this?
- dnautics 9mo ago
  I'm pretty sure the point of aggressively evolving now is to have to basically not evolve it at some point in the future?
- pjmlp 9mo ago
  > The entire C, C ABI and standard lib specs, combined, are probably less words than the Promise spec from ECMAScript 262. Not if you look into C23, include all the compiler extensions devs keep thinking are part of ISO C, and the "C ABI" is one per each existing OS written in C.
  - uecker 9mo ago
    C23 did not increase a lot. The core language spec is also very small. Extensions are also often relatively simple, but most importantly, one does not have to use them. ABI is usually not per OS but per architecture.

pron 9mo ago

> I take a 'living' language any day over of a language that's ossified because of strict backward compatibility requirements Maybe you would, but >95% of serious projects wouldn't. The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace, where low-level languages are commonly used, codebases typically last for over 30 years), and while such changes are manageable early on, they become less so over time. You say "strict" as if it were out of some kind of stubborn princple, where in fact backward compatibility is one of the things people who write "serious" software want most. Backward compatibility is so popular that at some point it's hard to find any feature that is in high-enough demand to justify breaking it. Even in established languages there's always a group of people who want somethng badly enough they don't mind breaking compatibility for it, but they're almost always a rather small minority. Furthermore, a good record of preserving compatibility in the past makes a language more attractive even for greenfield projects written by people who care about backward compatibility, who, in "serious" software, make up the majority. When you pick a language for such a project, the expectation of how the language will evolve over the next 20 years is a major concern on day one (a startup might not care, but most such software is not written by startups).

flohofwoe 9mo ago
> The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace). Either those applications are actively maintained, or they aren't. Part of the active maintenance is to decide whether to upgrade to a new compiler toolchain version (e.g. when in doubt, "never change a running system"), old compiler toolchains won't suddenly stop working. FWIW, trying to build a 20 or 30 year old C or C++ application in a modern compiler also isn't exactly trivial, depending on the complexity of the code base (especially when there's UB lurking in the code, or the code depends on specific compiler bugs to be present - e.g. changing anything in a project setup always comes with risks attached).
- pron 9mo ago
  > Part of the active maintenance is to decide whether to upgrade to a new compiler toolchain version Of course, but you want to make that as easy as you can. Compatibility is never binary (which is why I hate semantic versioning), but you should strive for the greatest compatibility for the greatest portion of users. > FWIW, trying to build a 20 or 30 year old C or C++ application in a modern compiler also isn't exactly trivial I know that well (especially for C++; in C the situation is somewhat different), and the backward compatibility of C++ compilers leaves much to be desired.
- strawhatguy 9mo ago
  You could fix versions, and probably should. However willful disregard of prior interfaces encourages developers code to follow suit. It’s not like Clojure or Common Lisp, where a decades old software still runs, mostly unmodified, the same today, any changes mainly being code written for a different environment or even compiler implementation. This is largely because they take breaking user code way more seriously. Alot of code written in these languages seem to have similar timelessness too. Software can be “done”.
andrepd 9mo ago
I would also add that Rust manages this very well. Editions let you do breaking changes without actually breaking any code, since any package (crate) needs to specify the edition it uses. So when in 30 years you're writing code in Rust 2055, you can still import a crate that hasn't been updated since 2015 :)

epolanski 9mo ago

Sure, but considering that Zig is a modern C alternative, one should not and cannot afford to forget that C has been successful also because it stayed small and consistent for so long. The entire C, C ABI and standard lib specs, combined, are probably less words than the Promise spec from ECMAScript 262. A small language that stays consistent and predictable lets developers evolve it in best practices, patterns, design choices, tooling. C has achieved all that. No evolving language has anywhere near that freedom. I don't want an ever evolving Zig too for what is worth. And I like Zig. I don't think any developer can resolve all of the design tensions a programming language has, you can't make it ergonomic on its own. But a small, modern, stable C would still be welcome, besides Odin.

bbkane 9mo ago
Besides Odin? Does Odin give you most of this?
dnautics 9mo ago
I'm pretty sure the point of aggressively evolving now is to have to basically not evolve it at some point in the future?
pjmlp 9mo ago
> The entire C, C ABI and standard lib specs, combined, are probably less words than the Promise spec from ECMAScript 262. Not if you look into C23, include all the compiler extensions devs keep thinking are part of ISO C, and the "C ABI" is one per each existing OS written in C.
- uecker 9mo ago
  C23 did not increase a lot. The core language spec is also very small. Extensions are also often relatively simple, but most importantly, one does not have to use them. ABI is usually not per OS but per architecture.