Stabilization of Rust language and stdlib features

1

Today on our call I mentioned an example of how Rust develops and stabilizes features. Here’s the stabilization list from today’s release notes:

So, Rust the language has a semantic version. Currently that’s 1.45.0. This is not only the version for the language, but for stdlib and tools as well (rustc–the compiler, and Cargo–the package manager and build system). So when you get Rust 1.45.0, the language, the compiler, the stdlib, and package manager are all 1.45.0.

Rust has been stable (1.x.x) since May 2015, but its stdlib still has unstable parts which get stabilized in minor releases, as documented in the link above.

Some food for thought and discussion on how we could manage stdlib development and releases.

2 Likes
2

Further, if you follow the link to the documentation for any of the functions, you can see the version number on the right side in the heading of each function:

https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#method.as_ptr

While not exactly the version number of the function, it could be effectively be the version number of its API, because this number says in which Rust version was the function stabilized.

1 Like
3

Another interesting thing I just learned is that Rust has a Core library and a Standard library.

I find this somewhat analogous to Fortran’s intrinsic procedures and the Fortran stdlib.

1 Like
4

Thanks for sharing this, and I like this approach, I think this can work for us also. Essentially they have unstable and stable, and everything in the master branch, and it seems to be done on a per function / method basis (some methods of the same class are stable, while other are unstable).

Applied to our case, we would get rid of the word experimental in the module name, but each function would be labeled experimental (or unstable) and once we move from experimental to stable, we update the documentation and announce which functions became stable and with what version of stdlib.

1 Like
5

Thank you for this info.
I like Rust 's approach: the user knows what is experimental or not, and can easily use experimental and stable procedures in the code. Moreover, if the API doesn’t change when moving from experimental to stable, the user doesn’t need to change her/his code.
Do you know if some Rust users complained about this approach?

A section (e.g., “Status: experimental/ stable since x.x.x”) could be easily added in the source code and in the specs of stdlib.

1 Like
6

An interesting blog post on the organization of the Rust project:

Ideally, the project goals of an open source project like Rust are simply the combination of personal goals of everyone working on it. And this is tricky. Because when a new person shows up, we don’t assign them a task that fits with our goals. Instead, this person comes with their own goals and ideas, adding to an already quite diverse set of potentially conflicting goals.

Without people who have it as their personal goal to make something happen, things just don’t happen.

1 Like