# Rust's complexity + Rust's stability policy =?

**URL:** <https://internals.rust-lang.org/t/rusts-complexity-rusts-stability-policy/16946>\
**Category:** Uncategorized\
**Created:** [July 5, 2022, 8:08am UTC](https://internals.rust-lang.org/t/rusts-complexity-rusts-stability-policy/16946 "2022-07-05T08:08:24Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![jbe](https://avatars.discourse-cdn.com/v4/letter/j/f6c823/32.png) [@jbe](https://internals.rust-lang.org/u/jbe)\
**Post date:** [July 5, 2022, 2:53pm UTC](https://internals.rust-lang.org/t/rusts-complexity-rusts-stability-policy/16946/11 "2022-07-05T14:53:28Z")

</div>

There must always be a tradeoff between publishing a breaking change of an API and keeping using an old API for the sake of interoperability.

However, I see a structural problem here because of the combination of:

- the goal of Rust's stability (which is important and legit),
- (allegedly? yet?) missing concepts for migration,
- the long lifecycle of a programming language, and
- the complexity of Rust.

I believe that this structural problem should at least be recognized as such. Not to say that I have a solution; but it is not "irrelevant".

---

_[View the full topic](https://internals.rust-lang.org/t/rusts-complexity-rusts-stability-policy/16946)._