This is completely false. Do you have an example?
Besides, this is completely off topic in a Zig thread. From the FAQ: "Zig is not afraid to roll the major version number of the language if it improves simplicity, fixes poor design decisions, or adds a new feature which compromises backward compatibility."
Review the "Breaking Changes" of release notes, and the number of discussions regarding removing API after a short (in the view of someone who works on said "systems code") period of deprecation.
> Besides, this is completely off topic in a Zig thread. From the FAQ: "Zig is not afraid to roll the major version number of the language if it improves simplicity, fixes poor design decisions, or adds a new feature which compromises backward compatibility."
And thus, it won't be used as a systems language.
Technically we can remove those at any time (happens in librustc all the time), the deprecation period is to help and motivate migration of nightly users, nobody else can touch those APIs.
This is another instance where our being up front about any theoretical breakage leads to misunderstandings. Every new release of GCC and Clang has breaking changes in the Rust sense too--they just don't call them "breaking changes" (and we stopped doing that too, because of comments like yours). For example, I had some code break when upgrading GCC the other day due to newer versions becoming stricter about copy constructor semantics in C++11. In Rust we (used to) call this type of thing a "breaking change" out of an abundance of caution--even though it was nothing more than the compiler getting stricter about code that never should have compiled in the first place. Unfortunately being up front about it led to confusions and comments like yours.