Thoughts on Rust 2019

Original author: Raph Levien
  • Transfer
Colleagues, good evening to all!

We are pleased to offer you a translation of a truly programmatic article from Raf Levin , whose titanic work on the development of the Rust language evokes respect and piety:

Without false modesty and without hats, the subject and enthusiastically respected author responded to the call of the Rust community, published by reference in the beginning of this article. We hope it turned out interesting and life-affirming.

Recently, the Rust Core Team offered to write articles with opinions on how Rust should evolve in 2019. Here is my opinion.

The life cycle of ripening

In this article I will discuss the life cycle of ripening in an extremely simplified form. Let it consist of only three stages: research, development, polishing. Different elements of Rust differ in different degrees of maturity. It is important to take this into account when trying to accurately characterize the current stage of language development, and ideally bring it to the next stage. For example, it seems to me that the language is mainly in the “grinding” stage. If you persist in the fact that the “research” stage has not yet been completed, then the language can be enriched with dependent types, virtual structuresetc., which would be interesting, but counterproductive. The reverse is also true: we cannot precisely formulate what we lack in the graphical user interface, therefore premature attempts to bring these searches to a standard solution are likely to result in non-optimal results.

Many mature products are interspersed with releases, some of which are devoted to running in new features, while others - to their stabilization. Such, for example, is Intel's tick-tock system. Versions of Android Kit Kat and Marshmallow were stable, and at the same time Lollipop was actively shoveling). In 2018, Rust was enriched with many new features, so I believe that the time has come for the stabilization phase. In this I agree with Jonathan Turner , as well as with many others.

Rust language

I think that, by and large, the Rust language is ready. It seems that the community has reached agreement on the need to "land" those features that are still "on the fly" (under development): talking about async / await, const generics, and the interpreter (which will probably provide us with generalized associated types ). However, I think that beyond this we should not be overly zealous with filling the pipeline with new features.

Changes cost money. As of 2018, Rust has written two excellent books, but both are already slightly out of date. Agreements for qualified paths are different in them, now we use dyn Trait, etc. The more dynamic the changes, the greater the inconvenience for users.

There are many factors that limit the success of Rust; I do not think that most of these shortcomings are inherent in the language itself.


Rust gear could be much better. I experimented with RLS, but I always returned to the usual text editor and command line cycle (to be honest, I haven’t done such experiments lately). I think in the long run, it is required to significantly refine the Rust toolkit in order to at least ease the learning curve. I have some ideas (I hope there will be time to explain them in more detail) about a more greenhouse language, the realizability of which I am not sure about, where there would be no clear distinction between meaning and reference to it, meaning could be used after the move, etc. . In principle, such a language would allow the string to be treated as a number. The server accepts programs written in this language, quickly corrects them and converts them into a full-featured Rust.

Naturally, RLS only half corresponds to this, users interact with it through the editor. Working with xi-editor is convenient, although it usually takes some guidance and support. This work was undertaken by a community led by Colin Roflz , and I was just happy to see how this editor is improving (he has already become my main). It provides support for the language server, as well as new features, such as the general annotation mechanism, will be significantly improved in 2019.

Library Ecosystem

The hottest job is now in full swing in creating libraries for Rust. Below I will list the things that I plan to do myself.

One of the topics I would like to raise is “coherence”, which, in my opinion, is one of the most valuable features of Rust, along with the technical component of its type system . Many of the components of the “game engine” within C ++ are a carefully prepared collection of libraries that interact well with each other. But in Rust, many such things happen organically. Containers are really usually sharpened for use in bundles, and if you properly use such things as into, then all the more established. A particularly convincing example of the second kind is mint , which ensures the interoperability of many mathematical containers, even though they do not match the conventions used to define vector types, etc.


I think SIMD libraries are still at the research stage. There are a number of wrapper libraries, each of which offers a slightly different perspective and a different row of compromises: simdeez , packed_simd , faster, and, of course, my own fearless_simd . These trade-offs are far from unconditional, because some users will need to squeeze out all the performance from the language to the last drop, and if you suffer from such extremes, you will have to resort to the best instructions for specific processors. Others will appreciate portability and security.

One of the most important quotes for SIMD is that much more work has to be done in the compiler, largely for the sake of interoperability with AVX-512 and non-x86 SIMD architectures. It is also possible that the wrapper libraries require some changes at the language level in order to work as comfortably as possible; so, at the moment, embedding and cfg(target_feature = ...)interacting badly. In my opinion, this is another issue that requires research. It is interesting to understand how far we can go without additional support at the language level, and what opportunities will help to fundamentally improve the usability of working with it?


There are convenient low-level audio containers, among which cpal should be noted. However, with it there may be difficulties at the level of performance (the container does not always use the real-time stream), some possibilities. It is necessary to find the best way: either to refine cpal, or to develop a new container, which would allow to correct specific problems. To do this, in particular, you need to carefully look at the C ++ libraries, for example, RtAudio , which solves these problems well.

For higher level audio synthesis, I have big plans for synthesize-rs . This option is not suitable for everyone, but I think this is a good basis for a variety of synthesis techniques and audio effects. It seems that today this area of ​​work is somewhere between the stages of research and development.

To follow up on this work, check outstream #synthesizer in our Zulip chat. In November, I gave a lecture on this, on the basis of which I soon plan to write a post.


Currently, graphical user interfaces are one of the weakest points of Rust. I think in 2019 we will see in the Rust community a lot of articles on this topic.
Personally, it seems to me that Rastov GUIs should now be attributed to the “research” phase. Many alternative approaches are being worked out, and so far there is no consensus about which one is the best. How active should 2D graphics and other user interface primitives be used in the system architecture, or should we implement this entire stack ourselves? Is deployment to the web necessary (using wasm)? Should the entire programming process be perceived as “Rust-native”, or should it be better adapted to conventions established in some mature GUI? Will the Rust community have enough resources to create a new GUI toolkit, and if so, is it worth it?

I started the project Druidto make a GUI for my synthesizer and game, but this project is an exploratory one. It presents my point of view, my answers to all the questions formulated above, and, in my opinion, this project is developing well. But, again, this is a research project, and it would be very foolish at this stage to implement it in other projects.

In addition, a number of other GUI development projects are underway. In my opinion, the most promising of these is Azul , since I like WebRender as the basis for building a GUI. Another very promising project is OrbTK , made on the basis of Redox, but cross-platform and really advanced. You can learn a lot from examples Conrod , ggezas well as on toolbox wrappers from other languages.

Not surprisingly, the most vigorous GUI development in Rust is closely related to games, and it seems to me that this is good. Innovation is better acclimatized in the gaming segment, and the need for mature tools is not so urgent here. But, as soon as an excellent approach to the implementation of the GUI in Rust appears, I think it will find the widest application. Also note that my Druid was born on the basis of a GUI-level from the xi client editor for Windows .


library pulldown-cmarkIt is used quite well, in particular, for rustdoc, but in some respects it has become more tired. Its evolution does not keep pace with the development of the CommonMark specification. One of the reasons why it is a little stuck is related to the parsing algorithm; I already have an idea how to write a new algorithm for this purpose, much better than before; but I have not worked out the details yet. Recently, I returned to this work again and am preparing to release an algorithm. When the branch is new_algo added to the master, I think the community should take up its further development, enrich it with new features. I’m thinking about full GFM compatibility, math and maybe something else like that.

Thanks to everyone in the Rust community for finalizing the language that I enjoy living with.

Only registered users can participate in the survey. Sign in , please.

Screenshot from Gitkhab - to be or not to be?

Also popular now: