Réflexions sur la rouille 2019

Chers collègues, bonsoir à tous!

Nous sommes heureux de vous offrir la traduction d'un article véritablement programmatique de Raf Levin , dont le travail titanesque sur le développement du langage Rust évoque le respect et la révérence:



Sans fausse modestie et sans haine, un auteur respecté objectivement et avec enthousiasme a répondu à l'appel de la communauté Rust, publié par référence au début de cet article. Nous espérons que cela s'est avéré intéressant et révélateur de vie.


Récemment, l'équipe Rust Core a proposé d'écrire des articles avec des opinions sur la façon dont Rust devrait se développer en 2019. Voici mon avis.

Maturation du cycle de vie

Dans cet article, je considérerai le cycle de vie de la maturation sous une forme extrêmement simplifiée. Qu'il se compose de seulement trois étapes: recherche, développement, polissage. Les différents éléments de la rouille diffèrent par leur degré de maturité variable. Ceci est important à considérer lorsque vous essayez de caractériser avec précision le stade actuel du développement du langage et, idéalement, de le faire passer au stade suivant. Par exemple, il me semble que la langue est principalement au stade du «polissage». Si vous persistez dans le fait que l'étape de «recherche» n'est pas encore terminée, alors le langage peut être enrichi de types dépendants, de structures virtuelles , etc., ce qui serait intéressant, mais contre-productif. L'inverse est également vrai: nous ne pouvons pas formuler exactement ce qui nous manque dans l'interface utilisateur graphique, de sorte que les tentatives prématurées pour amener ces recherches à une solution standard risquent d'entraîner des résultats sous-optimaux.

Dans de nombreux produits matures, les versions alternent, dont certaines sont consacrées à l'exécution de nouvelles fonctionnalités, tandis que d'autres sont consacrées à leur stabilisation. Tel est, par exemple, le système tick-tock d'Intel. Les versions Android de Kat Kit et Marshmallow étaient stables, tandis que Lollipop était activement en train de pelleter). En 2018, Rust a été enrichi de nombreuses nouvelles fonctionnalités, je pense donc que le moment est venu pour la phase de stabilisation. En cela, je suis d'accord avec Jonathan Turner , ainsi qu'avec de nombreux autres.

Langue rouille

Je pense que, dans l'ensemble, la langue Rust est prête. Il semble que la communauté ait convenu de la nécessité de «débarquer» les fonctionnalités qui sont toujours «à la volée» (en cours de développement): nous parlons d'async / wait, de const génériques et d'un interprète (qui est susceptible de nous fournir une révision types génériques associés ). Cependant, je pense qu'en plus de cela, nous ne devons pas être trop zélés pour remplir le pipeline de nouvelles fonctionnalités.

Le changement coûte de l'argent. En 2018, deux excellents livres ont été écrits sur Rust, mais les deux sont déjà légèrement dépassés. Les conventions pour les chemins qualifiés diffèrent en eux, maintenant nous utilisons dyn Trait , etc. Plus les changements sont dynamiques, plus les utilisateurs sont gênés.

Il existe de nombreux facteurs qui limitent le succès de Rust; Je ne pense pas que la plupart de ces lacunes soient inhérentes à la langue elle-même.

Gréement

Un gréement Rust aurait pu être bien mieux. J'ai expérimenté avec RLS, mais je suis toujours retourné à un éditeur de texte normal et à une boucle de ligne de commande (pour être honnête, je n'ai pas défini de telles expériences récemment). Je pense qu'à long terme, il est nécessaire de modifier considérablement les outils Rust pour au moins en quelque sorte faciliter la courbe d'apprentissage. J'ai quelques idées (j'espère qu'il est temps de les expliquer plus en détail) sur une langue plus chaude, dont je ne sais pas où c'est faisable, où il n'y aurait pas de différence claire entre la valeur et le lien, la valeur pourrait être utilisée après le déménagement, etc. . En principe, un tel langage permettrait à une chaîne d'être traitée comme un nombre. Le serveur accepte les programmes écrits dans cette langue, les corrige rapidement et les convertit en une rouille à part entière.

Naturellement, RLS ne correspond qu'à la moitié à cela, les utilisateurs interagissent avec lui via l'éditeur. Travailler avec xi-editor est pratique, bien qu'il nécessite généralement quelques conseils et assistance. Ce travail a été entrepris par une communauté dirigée par Colin Rofles , et je suis juste heureux de voir comment cet éditeur s’améliore (il est déjà devenu mon principal éditeur). Il prend en charge le serveur de langue, ainsi que de nouvelles fonctionnalités, par exemple, un mécanisme d'annotation général, qui sera beaucoup mieux finalisé en 2019.

Écosystème de bibliothèque

Le travail le plus en vogue bat son plein dans la création de bibliothèques pour Rust. Ci-dessous, j'énumère les choses que j'ai l'intention de faire moi-même.

L'un des sujets que je voudrais aborder est la «cohérence», qui, à mon avis, est l'une des caractéristiques les plus précieuses de Rust, avec la composante technique de son système de typage . De nombreux composants du «moteur de jeu» dans C ++ sont une sélection soigneusement préparée de bibliothèques qui interagissent bien entre elles. Mais à Rust, beaucoup de ces choses se produisent de manière organique. Les conteneurs sont généralement affûtés pour une utilisation en bundles, et si vous utilisez correctement des choses comme into , alors tout va de mieux en mieux. Un exemple particulièrement convaincant du deuxième type est la menthe , qui assure l'interopérabilité de nombreux conteneurs mathématiques, même si les conventions utilisées pour définir les types de vecteurs ne coïncident pas en elles.

SIMD

Je pense que les bibliothèques SIMD sont toujours sous enquête. Il existe de nombreuses bibliothèques d'encapsuleurs, chacune offrant une perspective légèrement différente et un ensemble différent de compromis: simdeez , pack_simd , plus rapide et, bien sûr, mon propre fearless_simd . Ces compromis sont loin d'être inconditionnels, car certains utilisateurs devront éliminer toutes les performances de la langue jusqu'à la dernière goutte et, si vous gravitez à de tels extrêmes, vous devrez recourir aux meilleures instructions pour des processeurs spécifiques. D'autres apprécieront la portabilité et la sécurité.

L'un des bogues SIMD les plus importants est que beaucoup plus de travail doit être fait dans le compilateur, principalement pour l'interaction avec les architectures SIMD AVX-512 et non x86. Il est également possible que les bibliothèques d'encapsuleur nécessitent des modifications au niveau de la langue pour rendre le travail aussi pratique que possible; Donc, pour le moment, l'intégration et cfg(target_feature = ...) interagissent mal. À mon avis, c'est un autre problème qui nécessite des recherches. Il est intéressant de comprendre jusqu'où nous pouvons aller sans prise en charge supplémentaire au niveau de la langue, et quelles fonctionnalités exactement aideront à augmenter fondamentalement la commodité de travailler avec elle?

Audio

Il existe des conteneurs audio de bas niveau pratiques, parmi lesquels cpal doit être particulièrement noté. Cependant, il peut y avoir des difficultés au niveau des performances (le conteneur n'utilise pas toujours le flux en temps réel), quelques possibilités. Il est nécessaire de trouver le moyen optimal: soit modifier cpal, soit développer un nouveau conteneur qui corrigerait des problèmes spécifiques. Pour cela, en particulier, vous devez examiner attentivement les bibliothèques C ++, par exemple, RtAudio , qui résolvent bien ces problèmes.

Pour une synthèse audio de niveau supérieur, j'ai de grands projets pour synthétiser-rs . Cette option ne convient pas à tout le monde, mais je pense que c'est une bonne base pour une variété de techniques de synthèse et d'effets audio. Il semble qu'aujourd'hui ce domaine se situe entre les étapes de la recherche et du développement.

Pour suivre cela, consultez le flux #synthesizer dans notre chat Zulip. En novembre, j'ai donné une conférence à ce sujet, sur la base de laquelle je prévois d'écrire prochainement un article.

GUI

Les interfaces utilisateur graphiques sont actuellement l'un des points faibles de Rust. Je pense qu'en 2019, nous verrons beaucoup d'articles sur ce sujet dans la communauté Rust.
Personnellement, il me semble que les GUI de Rostov devraient désormais être attribuées à la phase «recherche». De nombreuses approches alternatives sont en cours d'élaboration et, jusqu'à présent, il n'y a pas de consensus sur la meilleure d'entre elles. Dans quelle mesure les graphiques 2D et les autres primitives d'interface utilisateur doivent-ils être utilisés activement dans l'architecture du système, ou devons-nous implémenter cette pile entièrement par nous-mêmes? Le déploiement sur le Web est-il nécessaire (à l'aide de wasm)? Le processus de programmation dans son ensemble doit-il être perçu comme «natif de Rust», ou vaut-il mieux s’adapter aux conventions établies dans certaines interfaces graphiques matures? La communauté Rust dispose-t-elle de suffisamment de ressources pour créer une nouvelle boîte à outils GUI, et si oui, cela en vaut-il la peine?

J'ai commencé un projet Druid pour créer une interface graphique pour mon synthétiseur et mon jeu, mais ce projet est un projet de recherche. Il présente mon point de vue, mes réponses à toutes les questions formulées ci-dessus et, à mon avis, ce projet se développe bien. Mais, je le répète, il s'agit d'un projet de recherche, et il serait très stupide à ce stade de l'introduire dans d'autres projets.

En outre, un certain nombre d'autres projets de développement d'interface graphique sont en cours. À mon avis, le plus prometteur d'entre eux est Azul , car j'aime WebRender comme base pour la construction d'une interface graphique. Un autre projet très prometteur est OrbTK , réalisé sur la base de Redox, mais multiplateforme et vraiment avancé. Vous pouvez apprendre beaucoup des exemples de Conrod , ggez , ainsi que des wrappers d'outils d'autres langues.

Sans surprise, l'activité de développement d'interface graphique la plus intense dans Rust est étroitement liée aux jeux, et il me semble que c'est bien. Les innovations prennent mieux racine dans le segment des jeux, et le besoin d'outils matures n'est pas si aigu ici. Mais, dès qu'une excellente approche de la mise en œuvre de l'interface graphique dans Rust apparaît, je pense qu'elle trouvera l'application la plus large. Je note également que mon Druide est né sur la base du niveau GUI de l' éditeur client xi pour Windows .

Marquage

La bibliothèque pulldown-cmark est assez bien utilisée, en particulier pour rustdoc, mais est déconseillée à certains égards. Son évolution ne suit pas le développement de la spécification CommonMark. L'une des raisons pour lesquelles il est resté un peu bloqué est l'algorithme d'analyse; J'ai déjà une idée de comment écrire un nouvel algorithme à cet effet, bien mieux qu'auparavant; mais je n'ai pas encore travaillé sur les détails. Récemment, je suis revenu sur ce travail et je me prépare à publier un algorithme. Lorsque la branche new_algo ajoutée à master, je pense que la communauté devrait poursuivre son développement, l'enrichir de nouvelles fonctionnalités. Je pense à la compatibilité GFM complète, aux mathématiques et peut-être à quelque chose d'autre comme ça.

Merci à tous les membres de la communauté de Rust d'avoir finalisé la langue avec laquelle j'aime vivre.