September 17, 2014 at 23:48Towards Rust 1.0
- Transfer
This article is a translation of the first post on the official blog of the Rust programming language developed by Mozilla. The first stable version of Rust is just around the corner (a preliminary forecast is the end of this / the beginning of next year), and the authors of the language are going to publish several introductory articles about what such special Rust offers.
In these articles, developers will talk in more detail about the key features of the language - the concepts of owning and borrowing data, why they are needed at all, and what tasks can be solved. I will try to translate them as I get out and hope that someone will be interested in the language. Please send comments on the translation in PM.
Rust 1.0 is on the way! We decided on the list of features and are busy with their implementation. Our plan is to release beta 1.0 at the end of the year. If everything is in order, then release 1.0 will take place shortly after beta. Future versions in the 1.x branch will be backward compatible, that is, the existing code will be compiled by them without changes (of course, with the exception of bugs in the compiler).
Naturally, release 1.0 does not only mean stabilization ("your code will continue to compile"); for us, it means that the language has become the way we want to see it. More precisely, that it is minimal . At the moment, the language is built around the simple basic concepts that we call possession (ownership) and borrowing(borrowing) (more about them later). Using these concepts, we were able to put everything else out into the libraries. This is very cool, because you yourself can write similar libraries. Because of this, we are sure that Rust will not only achieve its original goals, but also go further, applying in tasks that we did not even imagine.
Rust has come a long way in its development. If you have not followed him for some time, then you will probably be surprised how much over the past year we have simplified him. One of the most prominent great examples is pointers. For a long time, several types of pointers, denoted by special characters, were built into Rust. They are no more, and in the language there are only reference types,
The key to all this was the purposeful use of fundamental ideas: ownership (data; ownership) and borrowing(borrowing). First, we introduced the concept of data ownership as an effective and safe way to transfer data between tasks (streams), but over time we realized that due to this very mechanism we can transfer a variety of language elements to libraries. The resulting architecture is not only easier to learn; it is much "closer to iron" than we could have expected in principle. All Rust constructions are mapped directly to machine operations, and Rust does not require a special runtime or external dependencies. In its most minimal version, you can even write the kernel of the operating system in Rust .
Despite all these changes, Rust has remained true to its goal - to provide the security and convenience of modern programming languages without losing the efficiency and low-level capabilities that C and C ++ offer. In other words, if you want to immerse yourself in work directly with hardware, but you don’t want to spend a lot of time debugging segfaults and data races, Rust will come in handy.
Do not worry if you are not familiar with Rust. Over the next few months, we plan to release a series of blog posts about language design. The first few articles will focus on various aspects of data ownership and how it can be used for secure memory management, multi-threaded programming, and more. After that, we will move on to the remaining elements of the language and its ecosystem.
We have already advanced far, but much remains to be done before the first release. Here is a list of the big changes we're currently working on:
As for libraries, now we go through
Earlier, I wrote that Rust 1.0 is not so much the ultimate goal as the starting line. This is actually so. The goal of version 1.0 is to become a flexible foundation for creating efficient libraries. But libraries are only as good as easy to find and install.
Meet Cargo, Rust's package manager . Cargo has been developing very fast lately and is already quite functional. By the release of Rust 1.0, we also plan to launch a central package repository, making it very easy to create and distribute libraries (which we call “crates”). And of course, Cargo and the server with the repository are both written in Rust.
Intermediate versions of Rust for a long time came out exactly on schedule, and we do not plan to abandon it. However, as soon as we have stable releases, we will build additional infrastructure around them. We want to use the “channels” system, which is used by many projects, such as Firefox , Chrome and Ember.js .
The main idea is to have three channels: Nightly, Beta and Stable. The Nightly channel includes unstable features and libraries that may change without maintaining backward compatibility. Every six weeks we will create a new branch, Beta. It will no longer make changes that break compatibility, so if you use Beta or Stable, you can be sure that your code will continue to compile without changes. At the same time, the already existing Beta branch will become a stable release. We expect that users of the language will test their code under the Beta branch, and ready-made programs will be assembled using Stable. Your testing with the Beta version will help us know in advance that we have broken something that you are using.
Specifically, we plan to release release 1.0 in beta and then use the above process to move to the official release 1.0. However, if we find any serious beta problem, we can delay the release and spend another one or two beta periods. In the end, it’s better to wait a bit than to spend all your energy on something completely inoperative.
In many ways, the release of Rust 1.0 is not the end, but only the beginning. Naturally, we plan to develop the language in the future: we have many ideas, and some of them are already planned for implementation. But most of all, I do not expect the results of the Rust team; I believe that a sustainable foundation will allow the Rust community and its ecosystem to grow and grow even faster than they do now. I can’t wait for what happens.
In these articles, developers will talk in more detail about the key features of the language - the concepts of owning and borrowing data, why they are needed at all, and what tasks can be solved. I will try to translate them as I get out and hope that someone will be interested in the language. Please send comments on the translation in PM.
Rust 1.0 is on the way! We decided on the list of features and are busy with their implementation. Our plan is to release beta 1.0 at the end of the year. If everything is in order, then release 1.0 will take place shortly after beta. Future versions in the 1.x branch will be backward compatible, that is, the existing code will be compiled by them without changes (of course, with the exception of bugs in the compiler).
Naturally, release 1.0 does not only mean stabilization ("your code will continue to compile"); for us, it means that the language has become the way we want to see it. More precisely, that it is minimal . At the moment, the language is built around the simple basic concepts that we call possession (ownership) and borrowing(borrowing) (more about them later). Using these concepts, we were able to put everything else out into the libraries. This is very cool, because you yourself can write similar libraries. Because of this, we are sure that Rust will not only achieve its original goals, but also go further, applying in tasks that we did not even imagine.
Path to Rust 1.0
Rust has come a long way in its development. If you have not followed him for some time, then you will probably be surprised how much over the past year we have simplified him. One of the most prominent great examples is pointers. For a long time, several types of pointers, denoted by special characters, were built into Rust. They are no more, and in the language there are only reference types,
&Tand &mut T. In addition, we were able to combine and simplify many other elements of the language, for example, closures, which were previously presented in many forms. Much continues to change to this day. The key to all this was the purposeful use of fundamental ideas: ownership (data; ownership) and borrowing(borrowing). First, we introduced the concept of data ownership as an effective and safe way to transfer data between tasks (streams), but over time we realized that due to this very mechanism we can transfer a variety of language elements to libraries. The resulting architecture is not only easier to learn; it is much "closer to iron" than we could have expected in principle. All Rust constructions are mapped directly to machine operations, and Rust does not require a special runtime or external dependencies. In its most minimal version, you can even write the kernel of the operating system in Rust .
Despite all these changes, Rust has remained true to its goal - to provide the security and convenience of modern programming languages without losing the efficiency and low-level capabilities that C and C ++ offer. In other words, if you want to immerse yourself in work directly with hardware, but you don’t want to spend a lot of time debugging segfaults and data races, Rust will come in handy.
Do not worry if you are not familiar with Rust. Over the next few months, we plan to release a series of blog posts about language design. The first few articles will focus on various aspects of data ownership and how it can be used for secure memory management, multi-threaded programming, and more. After that, we will move on to the remaining elements of the language and its ecosystem.
What else is left to do
We have already advanced far, but much remains to be done before the first release. Here is a list of the big changes we're currently working on:
- Types with dynamic size ( Dynamically sized types ). This extension of the type system will make it possible to work uniformly with types whose size is not known at compile time - such as arrays. Using DST, language users will be able to create their own "smart" pointers that will be able to contain arrays of objects. Nicholas Cameron has recently done most of the necessary work.
- Unboxed-circuit ( unboxed closures ). The new closure design combines closures and object types. Most of this specification has already been implemented.
- Associated types ( Associated types ). We are switching our trait mechanism to using associated types , which will greatly reduce the number of type variables previously needed to create truly generalized libraries. Patrick Walton has already made a preliminary implementation of the associated types.
- Where conditions ( Where clauses ). We want to add a new flexible form for setting constraints on type variables - where-conditions . Patrick Walton already added basic syntax support, and I made the remaining functionality in a separate branch, which will soon be integrated into the project.
- Multiple dispatch traits ( Multidispatch traits ). We are going to expand the possibilities of traits so that the compiler can choose a specific implementation of the trait based on several types at once. The prototype is already in my branch.
- Destructors ( Destructors ). We want to improve the semantics of destructors so that they do not require preliminary zeroing of memory. As a result, the compilation time will decrease, and the execution speed of already compiled code will increase. Felix Klock analyzed what is needed for this, and is now busy with the implementation.
- Lightweight threads ( Green threading ). We will remove support for lightweight threads from the standard library and transfer it to a separate package. Thanks to this, the thread model Rust will become closer to the model of the operating system, which, in turn, will lead to more efficient programs. Aaron Turon has written the RFC and is about to begin work on this.
As for libraries, now we go through
libstd, marking its individual parts as stable and unstable. You can follow our progress here . Keep in mind that many “unstable” definitions will actually change minimally, for example, they may slightly change the name to better match accepted conventions.Cargo and the ecosystem of libraries
Earlier, I wrote that Rust 1.0 is not so much the ultimate goal as the starting line. This is actually so. The goal of version 1.0 is to become a flexible foundation for creating efficient libraries. But libraries are only as good as easy to find and install.
Meet Cargo, Rust's package manager . Cargo has been developing very fast lately and is already quite functional. By the release of Rust 1.0, we also plan to launch a central package repository, making it very easy to create and distribute libraries (which we call “crates”). And of course, Cargo and the server with the repository are both written in Rust.
Release process
Intermediate versions of Rust for a long time came out exactly on schedule, and we do not plan to abandon it. However, as soon as we have stable releases, we will build additional infrastructure around them. We want to use the “channels” system, which is used by many projects, such as Firefox , Chrome and Ember.js .
The main idea is to have three channels: Nightly, Beta and Stable. The Nightly channel includes unstable features and libraries that may change without maintaining backward compatibility. Every six weeks we will create a new branch, Beta. It will no longer make changes that break compatibility, so if you use Beta or Stable, you can be sure that your code will continue to compile without changes. At the same time, the already existing Beta branch will become a stable release. We expect that users of the language will test their code under the Beta branch, and ready-made programs will be assembled using Stable. Your testing with the Beta version will help us know in advance that we have broken something that you are using.
Specifically, we plan to release release 1.0 in beta and then use the above process to move to the official release 1.0. However, if we find any serious beta problem, we can delay the release and spend another one or two beta periods. In the end, it’s better to wait a bit than to spend all your energy on something completely inoperative.
Perspective
In many ways, the release of Rust 1.0 is not the end, but only the beginning. Naturally, we plan to develop the language in the future: we have many ideas, and some of them are already planned for implementation. But most of all, I do not expect the results of the Rust team; I believe that a sustainable foundation will allow the Rust community and its ecosystem to grow and grow even faster than they do now. I can’t wait for what happens.