Stability as a result
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 the Rust language. The translation of the first part can be read here .
Please send comments to the translation in lichku.
')
The upcoming release of Rust 1.0 carries a lot of important things, but the main thing in it is our efforts to ensure stability, similar to our ongoing security orientation.
Starting from version 1.0, we will move to a six-week release cycle and a set of “channels”. The channel of stable releases will provide painless updates, and the channel of nightly assemblies will provide pioneers with access to the functionality that is currently being worked on.
From his very first days in Rust, only two things remained 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 perfect and necessary.
But since then Rust has matured, and its key aspects have not changed for quite a long time. His architecture finally seems to us correct. In addition, you can now see a genuine interest in the language, restrained only in anticipation of the release of a 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 hope that its users will update the environment for their projects as often. But for this the update process itself should be painless.
If it is very simple, then our responsibility is that you are never afraid to update Rust. If your code is compiled with stable release 1.0, it should be compiled and 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 widely used now to ensure stability and prevent stagnation:
In other words, we will have three release channels - nightly builds, beta builds and stable releases, with regular promotions from one channel to the next.
The new functionality and the new API will be marked as unstable with the help of feature gates and stability attributes, respectively. Unstable features and API of standard libraries 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 include only those features and APIs that are marked as stable . This means that special attention will be paid not to break the code that uses them.
There are many details involved in this process, and we are going to publish an RFC in which we’ll tell you more about them. The rest of this post is about the most important features and potential concerns about our plan.
We analyzed the existing infrastructure of the Rust ecosystem in order to determine the most used libraries (crates) and features that they use, and build on this basis our stabilization plan. Good news: the overwhelming majority of the functionality that is being actively used will be marked as stable in release 1.0:
After much discussion, we decided to keep 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, however, we will most likely provide an additional way to define them (with improved hygiene ) later, until then gradually improving the existing “macros”. In release 1.0, all existing support for macros, including import / export, will be stabilized.
On the other hand, we cannot declare syntactic extensions that are plugins of the compiler with full access to its internals, stable. This will mean that the entire internal structure of the compiler will be fixed forever. Therefore, we need to develop a more thoughtful interface between extensions and the compiler, and therefore the syntax extensions will remain in feature 1.0.
In many important cases, syntactic extensions can be replaced by traditional code generation, and Cargo will soon be included to support it. We're going to help library authors get away from syntax extensions before release 1.0. But since a large number of extensions do not fit into this model, their stabilization is a high priority after release 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 output 1.0. In addition, we transfer the most experimental parts of the API to separate libraries (crates).
Library developers, like today, can continue to use stability attributes for their code. These attributes will not be associated with the default Rust release channels. In other words, if you compile with 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 designed for a painless update of Rust itself (compiler and standard library).
It is assumed that authors of libraries should follow the specification of semantic versions . Soon we will publish an RFC, defining the relationship between stability attributes and semantic versions.
When using unstable language elements and libraries in stable releases, three problems arise.
First, how many times it has been observed in the field of web development, simply declaring something unstable does not help. As soon as any features begin to be used at least 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 like vendor prefixes on the web, originally intended for experimenting with features, have become the de facto standard.
Secondly, unstable elements, by definition, are unfinished, they are being worked on all the time. However, beta and stable releases “freeze” them at designated points in time, at a time when library developers would like to work with their latest version.
Finally, we simply cannot ensure the stability of Rust if we do not insist on the fulfillment 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 guaranteed the same thing, maintaining their libraries for all three channels simultaneously.
Making the whole ecosystem solve these problems is completely unrealistic and, in principle, not necessary. Instead, we set 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 free to use libraries designed for a stable version of the language. The most important features and API 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 will fall 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 correct bugs in the compiler, close security holes and change the type inference algorithms so that additional type annotations may be required. We believe that such changes should not cause a serious headache when updating Rust.
The features of stability in the API will be outlined in the future RFC, but in general they are also thought of in such a way as to facilitate updates to you.
Definitely yes! Since the latest changes are constantly entering the main branch, the “train” model will not slow down the development rate and will not introduce artificial delays. With the help of our amazing community, Rust has always developed very quickly, and we are confident that in the future the pace will only accelerate.
Please send comments to the translation in lichku.
')
The upcoming release of Rust 1.0 carries a lot of important things, but the main thing in it is our efforts to ensure stability, similar to our ongoing security orientation.
Starting from version 1.0, we will move to a six-week release cycle and a set of “channels”. The channel of stable releases will provide painless updates, and the channel of nightly assemblies will provide pioneers with access to the functionality that is currently being worked on.
Desire for stability
From his very first days in Rust, only two things remained 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 perfect and necessary.
But since then Rust has matured, and its key aspects have not changed for quite a long time. His architecture finally seems to us correct. In addition, you can now see a genuine interest in the language, restrained only in anticipation of the release of a 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 hope that its users will update the environment for their projects as often. But for this the update process itself should be painless.
If it is very simple, then our responsibility is that you are never afraid to update Rust. If your code is compiled with stable release 1.0, it should be compiled and 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 widely used now 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 version 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 promotions from one channel to the next.
The new functionality and the new API will be marked as unstable with the help of feature gates and stability attributes, respectively. Unstable features and API of standard libraries 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 include only those features and APIs that are marked as stable . This means that special attention will be paid not to break the code that uses them.
Frequently asked Questions
There are many details involved in this process, and we are going to publish an RFC in which we’ll tell you more about them. The rest of this post is about 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 determine the most used libraries (crates) and features that they use, and build on this basis our stabilization plan. Good news: the overwhelming majority of the functionality that is being actively used will be marked as stable in release 1.0:
- Some features that are already almost finished: variant structures (enumerations), new and default parameters, indexing of tuples and syntax for creating slices.
- Two key elements of the language that still need a lot of work - unboxed closures and associated types.
- And finally, important features, the problems in which we no longer have time to solve up to 1.0 are multiple (glob) imports, macros, and syntax extensions. Here we have to make hard decisions.
After much discussion, we decided to keep 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, however, we will most likely provide an additional way to define them (with improved hygiene ) later, until then gradually improving the existing “macros”. In release 1.0, all existing support for macros, including import / export, will be stabilized.
On the other hand, we cannot declare syntactic extensions that are plugins of the compiler with full access to its internals, stable. This will mean that the entire internal structure of the compiler will be fixed forever. Therefore, we need to develop a more thoughtful interface between extensions and the compiler, and therefore the syntax extensions will remain in feature 1.0.
In many important cases, syntactic extensions can be replaced by traditional code generation, and Cargo will soon be included to support it. We're going to help library authors get away from syntax extensions before release 1.0. But since a large number of extensions do not fit into this model, their stabilization is a high priority after release 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 output 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, like today, can continue to use stability attributes for their code. These attributes will not be associated with the default Rust release channels. In other words, if you compile with 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 designed for a painless update of Rust itself (compiler and standard library).
It is assumed that authors of libraries should follow the specification of semantic versions . Soon we will publish an RFC, defining 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.
First, how many times it has been observed in the field of web development, simply declaring something unstable does not help. As soon as any features begin to be used at least 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 like vendor prefixes on the web, originally intended for experimenting with features, have become the de facto standard.
Secondly, unstable elements, by definition, are unfinished, they are being worked on all the time. However, beta and stable releases “freeze” them at designated points in time, at a time when library developers would like to work with their latest version.
Finally, we simply cannot ensure the stability of Rust if we do not insist on the fulfillment 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 guaranteed the same thing, maintaining their libraries for all three channels simultaneously.
Making the whole ecosystem solve these problems is completely unrealistic and, in principle, not necessary. Instead, we set the rule that if something is stable, then it is actually stable, and a stable channel offers only stable features.
Will there be a split ecosystem? Will everyone use the nightly build even after the release?
No, the ecosystem will not be divided: this approach only highlights its subset. Developers working with the nightly channel will be free to use libraries designed for a stable version of the language. The most important features and API 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 will fall 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 correct bugs in the compiler, close security holes and change the type inference algorithms so that additional type annotations may be required. We believe that such changes should not cause a serious headache when updating Rust.
The features of stability in the API will be outlined in the future RFC, but in general they are also thought of in such a way as to facilitate updates to you.
Will Rust and its ecosystem continue to grow as actively as now?
Definitely yes! Since the latest changes are constantly entering the main branch, the “train” model will not slow down the development rate and will not introduce artificial delays. With the help of our amazing community, Rust has always developed very quickly, and we are confident that in the future the pace will only accelerate.
Source: https://habr.com/ru/post/243315/
All Articles