Discussion :

[Bill Fassinou]

Rust 1.45.0 est disponible avec la correction du problème de la conversion entre des entiers et des flottants
et de nombreuses fonctionnalités

L’équipe de développement de Rust a publié mercredi une nouvelle mise à jour pour le langage. Rust 1.45.0 est livré avec très peu de nouvelles fonctionnalités, mais plusieurs améliorations et correctifs de bogues. Il y a également dans cette version la stabilisation de certaines API. Voici en quelques lignes ce dont il s’agit.

Correction des défauts de solidité des casts

Le compilateur Rust dans Rust 1.44.0 et les anciennes versions du langage produirait un LLVM-IR qui ressemble à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
define i8 @_ZN10playground4cast17h1bdf307357423fcfE(float %x) unnamed_addr #0 {
start:
  %0 = fptoui float %x to i8
  ret i8 %0
}

Ce fptoui implémente le cast, c'est l'abréviation de “floating point to unsigned integer”. Mais selon l’équipe Rust, il y a un problème à cela. D'après la documentation du langage, l'instruction “fptoui” convertit son opérande à virgule flottante en la valeur entière non signée la plus proche (arrondie à zéro). Si la valeur ne peut pas tenir dans ty2, le résultat est une valeur “empoisonnée”. Cela signifie que si vous transformez un nombre à virgule flottante qui est grand en un nombre entier qui est petit, vous obtenez un comportement indéfini.
Ce comportement n’est par exemple pas défini :

Code Rust :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
fn cast(x: f32) -> u8 {
    x as u8
}
 
fn main() {
    let f = 300.0;
 
    let x = cast(f);
 
    println!("x: {}", x);
}

Avec Rust 1.44.0, il se trouve que cela imprime “x : 0”, mais il pourrait imprimer n'importe quoi, ou faire n'importe quoi. C'est un comportement indéfini. Mais il n’y a pas de code “unsafe” ici. On appelle cela un bogue de “solidité”, c'est-à-dire un bogue où le compilateur fait quelque chose d’inattendu. Cela dit, le problème est maintenant résolu. Selon l’équipe, ce bogue a pris beaucoup de temps à être résolu, car elle n’était pas du tout sûre de la bonne marche à suivre. Finalement, il a été décidé qu’il vous faudra ajouter un nouveau casting unsafe si vous vouliez sauter les contrôles.

Selon l’équipe, cela ressemble beaucoup à l'accès aux tableaux. Par exemple, array[i] vérifiera que le tableau comporte au moins i + 1 éléments. Vous pouvez donc utiliser unsafe { array.get_unchecked(i) } pour sauter la vérification. Toutefois, elle a mis en garde contre cette méthode. « Mais comme toujours, vous ne devez utiliser cette méthode qu'en dernier recours. Tout comme pour l'accès aux tableaux, le compilateur peut souvent optimiser les vérifications, rendant les versions sûres et non sécurisées équivalentes lorsque le compilateur peut le prouver », a-t-elle déclaré.

Stabilisation des macros procédurales de type fonctionnel dans les expressions, les modèles et les énoncés

Dans Rust 1.45.0, des fonctions comme les macros procédurales peuvent maintenant être utilisées dans les positions d'expression, de modèle et de déclaration. Cela signifie que vous pouvez maintenant utiliser une macro procédurale de type fonction partout où vous pouvez utiliser une macro déclarative (macro_rules !). Rust 1.45.0 introduit aussi d’autres améliorations au niveau du compilateur, dont :

• il est désormais possible de remplacer les entités cibles individuelles via l'indicateur target-feature. Par exemple, -C target-feature=+avx2 -C target-feature=+fmaest maintenant équivalent à -C target-feature=+avx2,+fma ;
• ajout du drapeau force-unwind-tables. Cette option permet à rustc de toujours générer des tables de déroulement, quelle que soit la stratégie de panique ;
• ajout du drapeau embed-bitcode. Cet indicateur de codegen permet à rustc d'inclure le bitcode LLVM dans les rlibs générés (c'est activé par défaut) ;
• ajout de la valeur tiny à l'indicateur codegen code-model ;
• ajout du support de niveau 3 pour la cible mipsel-sony-psp ;
• ajout du support de niveau 3 pour la cible thumbv7a-uwp-windows-msvc.

En outre, à partir de cette version, Rust prend désormais en charge le code barré dans Markdown. Enfin, plusieurs API sont stabilisées dans Rust 1.45.0, notamment :

• Arc::as_ptr ;
• BTreeMap::remove_entry ;
• Rc::as_ptr ;
• rc::Weak::as_ptr ;
• rc::Weak::from_raw ;
• rc::Weak::into_raw ;
• str::strip_prefix ;
• str::strip_suffixe ;
• sync::Weak::as_ptr ;
• sync::Weak::from_raw ;
• sync::Weak::into_raw ;
• char::UNICODE_VERSION ;
• Span::resolved_at ;
• Span::located_at ;
• Span::mixed_site ;
• unix::process::CommandExt::arg0.

Source : Note de version de Rust 1.45.0, Page GitHub de Rust

Et vous ?

Que pensez-vous des nouveautés apportées dans Rust 1.45.0 ?

Voir aussi

Rust 1.43.0 est disponible avec de nouvelles API stabilisées, des améliorations de performances du compilateur et une petite fonctionnalité liée aux macros

Rust 1.44.0 est disponible et apporte la commande cargo tree à Cargo pour l'impression d'un graphe arborescent des dépendances

Rust 1.42.0 : Pin::{map_unchecked, map_unchecked_mut} ne nécessite plus le type de retour pour implémenter Sized, Error::description est désormais obsolète

Rust et WebAssembly - Tour d'horizon des points philosophiques régissant son développement, par Anthony Defranceschi

[Uther]

A noter également une amélioration du support des macros (position d'item, hygiène) qui va permettre de rendre le framework web Rocket utilisable avec la version stable de Rust.

[yoshi_120]

Mon dieu ce langage est vraiment horrible ! Pourquoi remplacé le C++ par un langage aussi illisible ! Et oui le langage Go est supérieur sur le plan conceptuel et de l'élégance ! Rien que l'immondice d'avoir ajouter un mot clé dans rust juste pour les boucle infinie avec "loop"... Sérieux les créateurs ont fait un kamoulox pendant la définition de la syntaxe !

Rust viens à peine d'être créé et il se complexifi déjà et devient de plus en plus insupportable à lire et à comprendre ! Si Go à réussi et Rust à échouer c'est pour ça et plein d'autre chose ! La documentation de Rust (https://docs.rs/) est moche et pas agréable à lire alors que la doc de Golang (https://golang.org/pkg/) est bien plus lisible ! Go est plus simple à lire et le gofmt simplifie la participation de nouveaux développeurs et surtout l'historicité de la réflexion car en réalité derrière Go il y a Plan 9 From Bell Labs et le C version Plan 9 qui contenait déjà les bases de Go sur les imports et sur la gestion de la cross compilation :

• http://harmful.cat-v.org/software/
• http://doc.cat-v.org/plan_9/
• http://doc.cat-v.org/plan_9/programm...ming_in_plan_9

Bref je respecte Golang car je comprends pourquoi il a été créer et je comprends car les concepteurs ont su l'expliquer ce qu'ils cherchaient à résoudre alors que Rust il y se côté bordel et cette conception où plein de gens viennent rajoutés leurs délire ! Et le pire ce sont les lifetimes en Rust qui sont dégueulasse avec des <'a,'b> partout

[Uther]

Je ne sais pas s'il est utile de répondre à ce qui à manifestement l'air d'un gros troll, mais je vais quand même tenter.
Rust n'est visiblement pas le langage que tu recherches, ce n'est pas grave : aucun langage n'est fait pour répondre à tous les besoins, ou alors il le ferait mal. Si tu vises la simplicité absolue de la syntaxe, si un Garbage Collector te convient et que tu n'as pas besoin d'abstraction complexes, Go est clairement ce qu'il te faut.

Rust vise d'autre objectifs. Je passe outre les critiques sur la forme pure comme les choix de mots clé, qui sont très subjectives et de toute façon pas importantes. Par contre c'est vrai que Rust a des concepts bien plus complexes que Go. Les lifetimes, la propriété des variables, la gestion des allocations, ... c'est vrai que ça demande un vrai effort d'apprentissage et ça peux alourdir la syntaxe par rapport a des langages qui garantissent moins de maitrise ou de sûreté.

Mon dieu ce langage est vraiment horrible ! Pourquoi remplacé le C++ par un langage aussi illisible ! Et oui le langage Go est supérieur sur le plan conceptuel et de l'élégance ! Rien que l'immondice d'avoir ajouter un mot clé dans rust juste pour les boucle infinie avec "loop"... Sérieux les créateurs ont fait un kamoulox pendant la définition de la syntaxe !

Le problème avec des notions aussi vague que l'élégance c'est que c'est des curseurs très personnels qui correspondent a nos attente personnelles à un moment précis. J'ai l'impression que ce qui n'est pas élégant pour toi, c'est surtout ce qui ne correspond pas a tes habitudes.
Avec un peu de recul, je ne pense pas que Rust ait fait des choix si étranges que ça car il y a pas mal de points de la syntaxe de Rust qui me paraissaient bizarre au premier abord et qui me semblent bizarre dans les autres langages aujourd'hui. Pourtant Rust est toujours loin d'être le langage que je pratique le plus.

Rust viens à peine d'être créé et il se complexifi déjà et devient de plus en plus insupportable à lire et à comprendre ! Si Go à réussi et Rust à échouer c'est pour ça et plein d'autre chose !

Rust est de base un langage assez complexe par rapport au Go ou au Java, mais on ne peut pas dire qu'il se soit beaucoup complexifié syntaxiquement depuis sa sortie. La plupart des changements visibles visant plutôt à le simplifier visuelement.
Quant a dire qu'il a échoué, c'est vraiment trop tôt pour donner de telles affirmation. Son usage semble toujours sur une solide pente ascendante ce qui est plutôt bon signe étant donné qu'il s'attaque a des domaines qui sont historiquement plutôt résistants au changements.
Et encore une fois la comparaison directe au Go n'a pas de sens : il est sorti plus tard et ne vise pas les mêmes domaines.

La documentation de Rust (https://docs.rs/) est moche et pas agréable à lire alors que la doc de Golang (https://golang.org/pkg/) est bien plus lisible !

Pour la documentation, je suis en partie d'accord avec toi. Sans aller jusqu’à dire qu'elle est moche (là encore c'est très subjectif), je trouve en effet qu'elle n'est pas aussi pratique qu'elle pourrait l'être. c'est pour ça que je cherche à voir comment l'améliorer.

Go est plus simple à lire et le gofmt simplifie la participation de nouveaux développeurs

Il y a aussi rustfmt

et surtout l'historicité de la réflexion car en réalité derrière Go il y a Plan 9 From Bell Labs et le C version Plan 9 qui contenait déjà les bases de Go sur les imports et sur la gestion de la cross compilation

Et Rust est tout lui aussi basé sur beaucoup de travaux de recherche sur la sécurité et les typage avec des inspiration du coté de langages fonctionnels comme OCaml, Hashkell et des travaux de recherche universitaires comme Cyclone. qui ont été travaillé pour obtenir un ensemble cohérent quitte a sortir des fonctionnalités qui ne s'intégraient pas bien.

Bref je respecte Golang car je comprends pourquoi il a été créer et je comprends car les concepteurs ont su l'expliquer ce qu'ils cherchaient à résoudre alors que Rust il y se côté bordel et cette conception où plein de gens viennent rajoutés leurs délire ! Et le pire ce sont les lifetimes en Rust qui sont dégueulasse avec des <'a,'b> partout

Je pense surtout que tu n'as pas compris l'idée de base qu'il y a derrière Rust et particulièrement les lifetime qui est au contraire très consistante et a été très réfléchie. Et après tout, c'est probablement que tu n'en as pas besoin et donc pas besoin de Rust. Ça ne veut pas dire qu'il n'a pas d’intérêt pour beaucoup de gens qui veulent garder un contrôle sur ce que fait leur programme à plus bas niveau.