Thoughts on Rust 2019
Colleagues, good evening everyone!
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 reverence:
')
Without false modesty and without hatefulness, the author substantively and enthusiastically responded to the call of the Rust community, published by reference at the beginning of this article. Hopefully, 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.
Maturation life cycle
In this article I will look at the life cycle of ripening in a very 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 basically 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 structures , etc., 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, and others - 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. The conventions for the qualified paths are different in them, now we use
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.
Rigging
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 correctly use such things as
SIMD
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 series 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 aspects of SIMD is that much more work has to be done in the compiler, largely for the sake of interoperability with the AVX-512 and non-x86 SIMD architectures. It is also possible that wrapper libraries require some changes at the language level in order to work as comfortably as possible; so, at the moment, embedding and
Audio
There are convenient low-level audio containers, among which cpal should be especially 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. For 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 this work, check out the #synthesizer stream in our Zulip chat. In November, I gave a lecture on this, on the basis of which I soon plan to write a post.
GUI
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 it necessary to deploy to the web (using wasm)? Should the whole programming process be perceived as “Rust-native”, or should it be better adapted to conventions established in some mature GUI? Does the Rust community have enough resources to create a new GUI toolkit, and if so, is it worth it?
I started the Druid project to 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. Much can be learned from the examples of Conrod , ggez , as well as the wrappers of tools from other languages.
Not surprisingly, the most vigorous GUI development work 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 originated on the basis of the GUI-level from the xi client editor for Windows .
Markup
The pulldown-cmark library is used quite well, in particular, for rustdoc, but in some respects it is a bit 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
Thanks to everyone in the Rust community for finalizing the language that I enjoy living with.
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 reverence:
')
Without false modesty and without hatefulness, the author substantively and enthusiastically responded to the call of the Rust community, published by reference at the beginning of this article. Hopefully, 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.
Maturation life cycle
In this article I will look at the life cycle of ripening in a very 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 basically 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 structures , etc., 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, and others - 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. The conventions for the 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.
Rigging
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 correctly use such things as
into , then everything is all the more adjusted. 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.SIMD
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 series 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 aspects of SIMD is that much more work has to be done in the compiler, largely for the sake of interoperability with the AVX-512 and non-x86 SIMD architectures. It is also possible that 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 = ...) interact badly. In my opinion, this is another question 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?Audio
There are convenient low-level audio containers, among which cpal should be especially 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. For 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 this work, check out the #synthesizer stream in our Zulip chat. In November, I gave a lecture on this, on the basis of which I soon plan to write a post.
GUI
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 it necessary to deploy to the web (using wasm)? Should the whole programming process be perceived as “Rust-native”, or should it be better adapted to conventions established in some mature GUI? Does the Rust community have enough resources to create a new GUI toolkit, and if so, is it worth it?
I started the Druid project to 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. Much can be learned from the examples of Conrod , ggez , as well as the wrappers of tools from other languages.
Not surprisingly, the most vigorous GUI development work 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 originated on the basis of the GUI-level from the xi client editor for Windows .
Markup
The pulldown-cmark library is used quite well, in particular, for rustdoc, but in some respects it is a bit 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
new_algo branch 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.
Source: https://habr.com/ru/post/433910/
All Articles