Thoughts on Rust 2019

 3r3304. 3r3-31. Colleagues, good evening to all!
 3r3304.
 3r3304. We are pleased to offer you a translation of a truly programmatic article from 3r3-36. Rafa Levin
whose titanic work on the development of the Rust language evokes respect and piety:
 3r3304.
 3r3304. Thoughts on Rust 2019  3r3304.
 3r3304. 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. We hope it turned out interesting and life-affirming.
 3r3304. suggested writing articles with views on how Rust should evolve in 2019. Here is my opinion.
 3r3304.
 3r3304. 3r3195. Maturation life cycle [/b]
 3r3304.
 3r3304. 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, 3r3337. 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 will most likely turn into non-optimal results.
 3r3304.
 3r3304. 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 201? 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 , and also with many others.
 3r3304.
 3r3304. 3r3195. Rust language 3r3196.
 3r3304.
 3r3304. 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 still remain "on the fly" (under development): talking about async /await, const generics, and the interpreter (which will probably provide us with 3r3-355. Generalized associated types 3r33223.). However, I think that beyond this we should not be overly zealous with filling the pipeline with new features.
 3r3304.
 3r3304. Changes cost money. As of 201? Rust has written two excellent books, but both are already slightly out of date. Agreements for qualified paths are different in them, we now use 3r3205. dyn Trait etc. The more dynamic the changes, the greater the inconvenience for users.
 3r3304.
 3r3304. 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.
 3r3304.
 3r3304. 3r3195. Tooling [/b]
 3r3304.
 3r3304. 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 necessary 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.
 3r3304.
 3r3304. Naturally, RLS only half corresponds to this, users interact with it through the editor. Work with 3r3381. xi-editor
convenient, although it usually requires some guidance and support. This work was undertaken by a community led by 3r3383. By Colin Roflz
, and I just happily watch how this editor is improving (he has already become my main one). It provides support for the language server, as well as new features, such as the general annotation mechanism, will be significantly improved in 2019.
 3r3304.
 3r3304. 3r3195. Library ecosystem [/b]
 3r3304.
 3r3304. 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.
 3r3304.
 3r3304. 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 3r399. 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 3r3205. into then all the more getting better. A particularly convincing example of the second kind is mint 3r32323. , providing interoperability of a set of mathematical containers, even though they do not match the agreements used in the definition of vector types, etc.
 3r3304.
 3r3304. 3r3195. SIMD 3r3196.
 3r3304.
 3r3304. 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: 3r3115. simdeez
, 3r3117. packed_simd
, faster and, of course, my own fearless_simd . These compromises are far from unconditional, because some users will need to squeeze out all the performance from the tongue 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.
 3r3304.
 3r3304. 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 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 = ) 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?
 3r3304.
 3r3304. 3r3195. Audio 3r3196.
 3r3304.
 3r3304. There are convenient low-level audio containers, among which 3r3139 should be noted. cpal . 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 that would allow to correct specific problems. To do this, in particular, you need to carefully look at the C ++ libraries, for example, 3r3141. RtAudio , well solving these problems.
 3r3304.
 3r3304. For higher-level audio synthesis, I have big plans for 3r3147. 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.
 3r3304.
 3r3304. To keep track of this work, check out 3r3153. stream #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.
 3r3304.
 3r3304. 3r3195. GUI 3r3196.
 3r3304.
 3r3304. 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.
 3r3304. 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? Will the Rust community have enough resources to create a new GUI toolkit, and if so, is it worth it?
 3r3304.
 3r3304. I started the project 3r3171. Druid 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.
 3r3304.
 3r3304. In addition, a number of other GUI development projects are underway. In my opinion, the most promising of these is Azul because 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 3r3181. Conrod , 3r3183. ggez as well as on toolbox wrappers from other languages.
 3r3304.
 3r3304. It is not surprising that the most turbulent 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 3r3189. client editor xi for Windows .
 3r3304.
 3r3304. 3r3195. Markup [/b]
 3r3304.
 3r3304. Library pulldown-cmark It 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 have again r3r3203. returned to this work. and getting ready to release an algorithm. When 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.
 3r3304.
 3r3304. Thanks to everyone in the Rust community for finalizing the language that I enjoy living with. 3r33300. 3r3304. 3r3304. 3r3304.
3r3304. 3r33300. 3r3304. 3r3304.
Only registered users can participate in the survey. Enter , you are welcome.
3r3304. 3r3304.
3r3304.
3r3304.
Screenshot from Gitkhab - to be or not to be?
3r3304. 3r33300. 3r3304. 3r3304.
3r3304.
3r3304.
3r3304.
3r3304. 3r3304.
3r3304.
3r3304.
3r3304. 3r3304.
It is convenient to put a screenshot with the author’s profile over the cat: his competence and range of interests is immediately visible. 3r3304.
3r3304. 3r3304.
3r3304.
3r3304.
3r3304. 3r3304.
No, KDPV is somehow more familiar than 3r33283. 3r3304.
3r3304. 3r3304.
3r3304.
3r3304.
3r3304. 3r3304.
Here you do not have Instagram, please limit yourself to text headers!
3r3304.
3r3304. 3r3304.
3r3304.
3r3304. 3r3304.
3r3304. 3r33300. 3r3304.
9 users have voted. 5 users abstained. 3r33300. 3r3304. 3r33300. 3r3304. 3r3304. 3r3304. 3r3304.
+ 0 -

Add comment