Hacker News Reader

Comment by teacup50 | Hacker News Reader

Among other things, systems programming projects generally require stability of language syntax, API, and ABI.

In terms of ABI stability, Rust has none.

In terms of API stability, they seem willing to drop features within a major release cycle or two.

In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x).

Rewriting for the sake of language updates is a huge resource drain when you're talking about code bases with lifetimes that are likely to be longer than their authors'.

For reference, just about every major shipping OS contains significant LoC dating back to the 70s or 80s.

View on HN

> In terms of API stability, they seem willing to drop features within a major release cycle or two.

I don't think any feature/api that was at one point marked as stable post 1.0 (when they started making any guarantees) has ever been removed.

> In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x).

While it's true that 2.x has the rights to break everything, this is incredibly dishonest to state in a vacuum, because it's a well established point that 2.x should never exist. The devs want all code to work forever, and only a catastrophe would push them to pull the lever. They have of course reserved the right to require fixes in special cases -- e.g. fixing a bug in the type checker might break some code, and that's acceptable. Although even then they'll try to phase in the fix over a few releases. Every release is tested against the entire crates.io ecosystem to try to catch these regressions.

You are absolutely correct on ABI stability, though.

Given the litany of deprecation markers applied to existing APIs, one must presume the intention of removing them, no?

Not necessarily. I suspect even in the case of 2.0, most if not all of those apis will survive. Deprecation markers exist to encourage people to use newer, better APIs.

I suspect that even if 2.0 happened, the only apis that would be removed would be ones that we're reasonably sure nobody uses (via crater), and even then there would be debate.

And like Gankro said, 2.0 is a thing that's not supposed to happen in the first place.

> Given the litany of deprecation markers applied to existing APIs, one must presume the intention of removing them, no?

No! That would be a basic violation of the compatibility promise that we've upheld since 1.0.

Are you going to criticize C for marking gets() as deprecated?

C11 does not have gets() anymore!

Sorry, C will never live it down.

To re-iterate what gankro said, we care a _lot_ about making sure that it's trivial to update your Rust. Your ABI compatibility comment is correct, but the rest of them aren't. We only break backwards compatibility in very few cases: if there's a soundness hole, or if we have to fix something in certain underspecified areas of the language. For those latter ones, if it's not a trivial fix, then it's a no-go, and even if it is, we do warnings until we don't see them in the ecosystem any longer.

But really, it's not about rules-lawyering over technicalities about what our policies are: the underlying attitude we share towards new Rust versions is that it should be trivial to upgrade. And we collect data to make sure that we're on target there: part of it is the train-based release strategy, part of it is stuff like testing everything on crates.io, part of it is things like the community survey, where most people said their code has never broken, and if it did, it was extremely easy to fix.

"Trivial to upgrade" is not the same as stable. It means code bitrots in-place.

True stability is impossible for almost any language out there, especially one with a nontrivial type system.

An example of a thing considered "trivial to upgrade" over is when the stdlib adds a new method to a type. Libraries may already have implemented a method of the same name on that type via a trait. In this case, folks upgrading would have to explicitly specify which method they're talking about.

It's these kinds of things that are not counted as breaking changes, because the alternative is freezing the stdlib forever. Other languages have the similar problems.

New releases are tested on the entire ecosystem to ensure that this rarely happens, if ever.

> In terms of API stability, they seem willing to drop features within a major release cycle or two.

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."

> This is completely false. Do you have an example?

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.

Are you referring to unstable APIs being deprecated and removed?

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.

> Review the "Breaking Changes" of release notes

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.

Reply on news.ycombinator.com