📜 ⬆️ ⬇️

Towards Rust 1.0

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 not far off at all (a preliminary forecast is the end of this / beginning of next year), and the authors of the language are going to publish several introductory articles on what this particular 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 they allow to solve. I will try to translate them as they come out and I hope that the language will interest someone. Please send comments to the translation in lichku.



')
Rust 1.0 is on the way! We have decided on the list of features and are busy with their implementation. Our plan is to release a beta version 1.0 at the end of the year. If everything is in order, then release 1.0 will take place shortly after the beta. Future versions in the 1.x branch will be backward compatible, that is, the existing code will be compiled by them unchanged (of course, except for bugs in the compiler).

Naturally, release 1.0 does not mean only stabilization (“your code will continue to compile”); for us, it means that language has become what we want it to be. If more precisely, it is minimal . At the moment, the language is built around simple basic concepts that we call ownership (ownership) and borrowing (more on them later). By applying these concepts, we were able to bring everything else to the libraries. This is very cool, because you can write similar libraries yourself. Because of this, we are confident that Rust will not only achieve its original goals, but will go further, applying it in tasks that we didn’t even imagine.



Path to Rust 1.0


Rust has come a long way in its development. If you have not watched him for some time, then you will most likely be surprised at how much we have simplified it over the past year. One of the most outstanding examples is the pointers. For a long time, several types of pointers have been built into Rust, denoted by special characters. They are no longer there, and only reference types, &T and &mut T remain in the language. In addition, we were able to combine and simplify many other elements of the language, for example, closures that were previously presented in many forms. Much continues to change and still.

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 efficient and secure way to transfer data between tasks (streams), but over time we realized that due to this very mechanism we can take out the most different elements of the language to libraries. The resulting architecture is not only easier to learn; it is much “closer to the gland” than we could expect. All constructions of the Rust language are directly mapped to machine operations, and Rust does not require a special runtime environment or external dependencies. In the very minimal version of it on Rust, you can even write the kernel of the operating system .

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 features offered by C and C ++. In other words, if you want to dive into working directly with iron, but at the same time you have no desire to waste a huge amount of time debugging segfolts and data races, Rust will be useful to you.

Do not worry if you are still unfamiliar with Rust. Over the next few months, we plan to launch a series of blog posts about the language structure. The first few articles will cover various aspects of data ownership and how it can be used for secure memory management, multi-threaded programming, and more. After that, we move on to the other elements of the language and its ecosystem.

What else is left to do


We are already far advanced, but there is still much to be done before the first release. Here is a list of the major changes we are currently working on:

  1. Types with dynamic size ( Dynamically sized types ). This extension of the type system will make it possible to work in a uniform manner with types whose size is unknown at compile time, such as arrays. With DST, users of the language will be able to create their own smart pointers that will be able to contain arrays of objects. Nicholas Cameron recently did most of the work needed.
  2. Unboxed closures ( Unboxed closures ). A new design of closures combines closures and object types. Most of this specification has already been implemented.
  3. Associated types . We translate our mechanism of traits to the use of associated types , which will greatly reduce the number of type variables previously needed to create truly generic libraries. Patrick Walton has already made a preliminary implementation of the associated types.
  4. Where clauses . We want to add a new flexible form for specifying restrictions on type variables - where-conditions . Patrick Walton has already added basic syntax support, and I’ve done the rest of the functionality in a separate thread that will soon be integrated into the project.
  5. Multidispatch traits . We are going to expand the capabilities of the 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 thread.
  6. Destructors . We want to improve the semantics of destructors so that they do not require a prior zeroing of memory. As a result, the compilation time will decrease, and the speed of the already compiled code will increase. Felix Klock analyzed what is needed for this, and is now busy with implementation.
  7. Lightweight threads ( Green threading ). We will remove support for lightweight streams from the standard library and transfer it to a separate package. Due to this, the Rust threading model will become closer to the operating system model, which, in turn, will lead to more efficient programs. Aaron Turon wrote an RFC and is about to start working on this.


As for libraries, now we are going through libstd , marking its separate 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 fit accepted agreements.

Cargo and Library Ecosystem


Earlier, I wrote that Rust 1.0 is not so much the final goal as the start line. This is actually the case. The purpose of version 1.0 is to become a flexible basis for creating efficient libraries. But libraries are only as good as finding and installing them.

Meet Cargo, the package manager Rust . 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, so it will be very easy to create and distribute libraries (which we call “crates” boxes). And of course, Cargo and the repository server are both written in Rust.

Release process


Intermediate versions of Rust for a long time went 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 system of “channels”, which is used by many projects, such as Firefox , Chrome and Ember.js .

The main idea is the presence of three channels: Nightly, Beta and Stable. The nightly channel includes unstable features and libraries that can be changed without 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 existing Beta branch will become a Stable release. We expect users of the language to test their code under the Beta branch, and to assemble ready-made programs using Stable. Your beta testing will help us know in advance that we have broken something that you are using.

Specifically, release 1.0, we plan to release as a beta and then use the above process to move to the official release 1.0. However, if we find any serious problem in beta, we can postpone the release and spend another one or two beta periods. In the end, it is better to wait a little 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 a lot of ideas, and some of them are already planned for implementation. But most of all, I'm not waiting for 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 it is now. I can not wait for what comes of it.

Source: https://habr.com/ru/post/237199/


All Articles