November 16, 2014 at 00:54Stability as a result
- Transfer
This article is a translation of the second part of a series of blog posts dedicated to the upcoming release of the first stable version of Rust. The translation of the first part can be read here .
Please send comments on the translation in PM.
The upcoming release of Rust 1.0 carries a lot of important things, but the most important one is our efforts to ensure stability, similar to our constant focus on security.
Starting with version 1.0, we will move on to a six-week release cycle and a set of “channels”. The stable release channel will provide painless updates, and the nightly build channel will provide pioneers with access to the functionality that is currently being worked on.
From its earliest days in Rust, only two things have been unchanged - security and change, and sometimes only the second. In the process of developing Rust, we often ran into dead ends, so the freedom to change the language was absolutely necessary.
But since then, Rust has "matured", and its key aspects have not changed for quite some time. Its architecture finally seems right to us. In addition, you can now observe a genuine interest in the language, restrained only in anticipation of the release of the stable version 1.0.
It is very important to clarify what we mean by stability. This does not mean that Rust will stop developing. We will regularly release new versions of the language and we hope that its users will update the environment for their projects as often. But for this, the update process itself should be painless.
If very simple, then our responsibility is to ensure that you are never afraid to update Rust. If your code is compiled with stable release 1.0, it should also be compiled with stable release 1.x with a minimum of hassle.
We will use the version of the “train” model, which first appeared in the development of web browsers and is now widely used to ensure stability and prevent stagnation:
In other words, we will have three release channels - nightly builds, beta builds and stable releases, with regular promotion from one channel to the next.
New functionality and a new API will be marked as unstable using feature gate and stability attributes, respectively. Unstable features and standard library APIs will be available only in the nightly build channel and only if you explicitly agree to use them.
Beta and stable releases, on the other hand, will only include features and APIs that are marked as stable . This means that special attention will be paid not to break the code that uses them.
A lot of details are involved in the described process, and we are going to publish the RFC, in which we will talk more about them. The remainder of this post focuses on the most important features and potential concerns about our plan.
We analyzed the existing infrastructure of the Rust ecosystem in order to identify the most used libraries (crates) and feature gates that they use, and build on this our stabilization plan. The good news: the vast majority of the functionality that is being actively used now will be marked as stable in release 1.0:
After much discussion, we decided to leave multiple imports and macros stable in release 1.0. We believe that problems with glob imports can be solved without breaking backward compatibility. For macros, we are likely to provide an additional way to define them (with improved hygiene ) later, until gradually improving existing “macro definitions”. In release 1.0, all existing support for macros, including their import / export, will be stabilized.
On the other hand, we cannotdeclare syntax extensions, which are compiler plugins with full access to its internals, stable. This will mean that the entire internal device of the compiler will be forever fixed. Therefore, we need to develop a more thoughtful interface between the extensions and the compiler, and therefore the syntax extensions will remain with the feature flag in 1.0.
In many important cases, syntax extensions can be replaced with traditional code generation, and its support will soon be included in Cargo. We are going to help library authors get away from syntax extensions to release 1.0. But since a large number of extensions do not fit into this model, their stabilization is a high priority after the release of 1.0.
We are gradually stabilizing the standard library, and we have plans for almost all of its modules. It is expected that the vast majority of the functionality of the standard library will be marked as stable to 1.0. In addition, we transfer the most experimental parts of the API to separate libraries (crates).
Library developers, as today, will be able to continue to use the stability attributes for their code. These attributes will not be associated with the default Rust release channels. In other words, if you compile using stable Rust, you can only use the stable API from the standard library, but you are free to try the experimental elements of other libraries. Rust release channels are intended for a painless update of Rust itself (the compiler and the standard library).
Library authors are supposed to follow the specification of semantic versions . Soon we will publish an RFC that defines the relationship between stability attributes and semantic versions.
When using unstable language elements and libraries in stable releases, three problems arise.
Firstly, how many times you can observe in the field of web development, just declaring something unstable does not help. As soon as any features begin to be used at least a little widely, they are very difficult to change; and as soon as features become available in principle, it is very difficult to prevent their use. Mechanisms such as vendor prefixes on the web, originally designed to experiment with features, have become the de facto standard.
Secondly, unstable elements, by definition, are incomplete, work is ongoing on them all the time. However, beta and stable releases “freeze” them at designated times, while library developers would like to work with their latest version.
And finally, we simply cannot ensure Rust's stability if we do not insist on the implementation of certain rules. We promise that if you use a stable release of Rust, you can be completely fearlessly updated for the next release. If third-party libraries would depend on instabilities in Rust, then we could keep this promise only if the authors of these libraries would guarantee the same by supporting their libraries for all three channels simultaneously.
Making the whole ecosystem solve these problems is completely unrealistic and, in principle, is not necessary. Instead, we establish the rule that if something is stable, then it is actually stable, and a stable channel offers only stable features.
No, the ecosystem will not be divided: this approach only highlights its subset. Developers working with the nightly channel will be able to freely use libraries designed for a stable version of the language. The most important features and APIs will somehow stabilize, so there will be less and less reasons to stay in an unstable world over time.
We planned release 1.0 in such a way that most of the existing ecosystem falls into the “stable” category, so beginners who are just starting to learn Rust will be able to immediately use the vast majority of existing libraries in stable release 1.0.
We reserve the right to fix bugs in the compiler, close security holes and change type inference algorithms so that additional type annotations may be required. We believe that this kind of change should not cause a serious headache when upgrading Rust.
The stability features in the API will be outlined in the future RFC, but in general they are also conceived in such a way as to make it easier for you to upgrade.
Definitely yes! As fresh changes get to the main branch all the time, the “train” model will not slow down the pace of development and will not introduce artificial delays. With the assistance of our amazing community, Rust has always developed very fast, and we are confident that the pace will only accelerate in the future.
Please send comments on the translation in PM.
The upcoming release of Rust 1.0 carries a lot of important things, but the most important one is our efforts to ensure stability, similar to our constant focus on security.
Starting with version 1.0, we will move on to a six-week release cycle and a set of “channels”. The stable release channel will provide painless updates, and the nightly build channel will provide pioneers with access to the functionality that is currently being worked on.
The pursuit of stability
From its earliest days in Rust, only two things have been unchanged - security and change, and sometimes only the second. In the process of developing Rust, we often ran into dead ends, so the freedom to change the language was absolutely necessary.
But since then, Rust has "matured", and its key aspects have not changed for quite some time. Its architecture finally seems right to us. In addition, you can now observe a genuine interest in the language, restrained only in anticipation of the release of the stable version 1.0.
It is very important to clarify what we mean by stability. This does not mean that Rust will stop developing. We will regularly release new versions of the language and we hope that its users will update the environment for their projects as often. But for this, the update process itself should be painless.
If very simple, then our responsibility is to ensure that you are never afraid to update Rust. If your code is compiled with stable release 1.0, it should also be compiled with stable release 1.x with a minimum of hassle.
Our plan
We will use the version of the “train” model, which first appeared in the development of web browsers and is now widely used to ensure stability and prevent stagnation:
- New functionality is added directly to the main branch.
- Every day, the last successful build based on the main branch becomes a new nightly release.
- Every six weeks, a beta branch is created from the current state of the main branch, and the previous beta version is declared stable.
In other words, we will have three release channels - nightly builds, beta builds and stable releases, with regular promotion from one channel to the next.
New functionality and a new API will be marked as unstable using feature gate and stability attributes, respectively. Unstable features and standard library APIs will be available only in the nightly build channel and only if you explicitly agree to use them.
Beta and stable releases, on the other hand, will only include features and APIs that are marked as stable . This means that special attention will be paid not to break the code that uses them.
FAQ
A lot of details are involved in the described process, and we are going to publish the RFC, in which we will talk more about them. The remainder of this post focuses on the most important features and potential concerns about our plan.
What features will be stabilized in 1.0?
We analyzed the existing infrastructure of the Rust ecosystem in order to identify the most used libraries (crates) and feature gates that they use, and build on this our stabilization plan. The good news: the vast majority of the functionality that is being actively used now will be marked as stable in release 1.0:
- Some features that are almost finished: structure-options (enumerations), t and new parameters by default, indexing of tuples and syntax for creating slices.
- Two key elements of the language that still need to be worked on are unboxed closures and associated types.
- And finally, important features, problems in which we no longer have time to solve before 1.0, are multiple (glob) imports, macros, and syntax extensions. Here we have to make difficult decisions.
After much discussion, we decided to leave multiple imports and macros stable in release 1.0. We believe that problems with glob imports can be solved without breaking backward compatibility. For macros, we are likely to provide an additional way to define them (with improved hygiene ) later, until gradually improving existing “macro definitions”. In release 1.0, all existing support for macros, including their import / export, will be stabilized.
On the other hand, we cannotdeclare syntax extensions, which are compiler plugins with full access to its internals, stable. This will mean that the entire internal device of the compiler will be forever fixed. Therefore, we need to develop a more thoughtful interface between the extensions and the compiler, and therefore the syntax extensions will remain with the feature flag in 1.0.
In many important cases, syntax extensions can be replaced with traditional code generation, and its support will soon be included in Cargo. We are going to help library authors get away from syntax extensions to release 1.0. But since a large number of extensions do not fit into this model, their stabilization is a high priority after the release of 1.0.
What parts of the standard library will be stable in 1.0?
We are gradually stabilizing the standard library, and we have plans for almost all of its modules. It is expected that the vast majority of the functionality of the standard library will be marked as stable to 1.0. In addition, we transfer the most experimental parts of the API to separate libraries (crates).
What about stability attributes outside the standard library?
Library developers, as today, will be able to continue to use the stability attributes for their code. These attributes will not be associated with the default Rust release channels. In other words, if you compile using stable Rust, you can only use the stable API from the standard library, but you are free to try the experimental elements of other libraries. Rust release channels are intended for a painless update of Rust itself (the compiler and the standard library).
Library authors are supposed to follow the specification of semantic versions . Soon we will publish an RFC that defines the relationship between stability attributes and semantic versions.
Why not allow the use of unstable features with a stable release?
When using unstable language elements and libraries in stable releases, three problems arise.
Firstly, how many times you can observe in the field of web development, just declaring something unstable does not help. As soon as any features begin to be used at least a little widely, they are very difficult to change; and as soon as features become available in principle, it is very difficult to prevent their use. Mechanisms such as vendor prefixes on the web, originally designed to experiment with features, have become the de facto standard.
Secondly, unstable elements, by definition, are incomplete, work is ongoing on them all the time. However, beta and stable releases “freeze” them at designated times, while library developers would like to work with their latest version.
And finally, we simply cannot ensure Rust's stability if we do not insist on the implementation of certain rules. We promise that if you use a stable release of Rust, you can be completely fearlessly updated for the next release. If third-party libraries would depend on instabilities in Rust, then we could keep this promise only if the authors of these libraries would guarantee the same by supporting their libraries for all three channels simultaneously.
Making the whole ecosystem solve these problems is completely unrealistic and, in principle, is not necessary. Instead, we establish the rule that if something is stable, then it is actually stable, and a stable channel offers only stable features.
Will the ecosystem split? Won't everyone use nightly builds even after release?
No, the ecosystem will not be divided: this approach only highlights its subset. Developers working with the nightly channel will be able to freely use libraries designed for a stable version of the language. The most important features and APIs will somehow stabilize, so there will be less and less reasons to stay in an unstable world over time.
We planned release 1.0 in such a way that most of the existing ecosystem falls into the “stable” category, so beginners who are just starting to learn Rust will be able to immediately use the vast majority of existing libraries in stable release 1.0.
Under what conditions is stability provided?
We reserve the right to fix bugs in the compiler, close security holes and change type inference algorithms so that additional type annotations may be required. We believe that this kind of change should not cause a serious headache when upgrading Rust.
The stability features in the API will be outlined in the future RFC, but in general they are also conceived in such a way as to make it easier for you to upgrade.
Will Rust and its ecosystem continue to develop as actively as they are now?
Definitely yes! As fresh changes get to the main branch all the time, the “train” model will not slow down the pace of development and will not introduce artificial delays. With the assistance of our amazing community, Rust has always developed very fast, and we are confident that the pace will only accelerate in the future.