Sujet : rust
-
Choisir Go ou Rust pour un nouveau service : une procédure de décision sans benchmarks
Choisir entre Go et Rust pour un service à partir des propriétés documentées des langages et des contraintes de l’équipe plutôt que d’idées reçues sur les benchmarks : gestion de la mémoire, traitement des erreurs et concurrence, profil de la charge, bibliothèques nécessaires et personnes qui assureront la maintenance dans deux ans.
-
Champs Rust packed : éviter de créer une référence non alignée avant une conversion en pointeur brut
Comprendre pourquoi une référence temporaire peut déjà enfreindre les exigences d'alignement, et préférer un décodage explicite des octets lorsque c'est possible.
-
Rust Pin : préserver l'adresse de la valeur pointée sans figer la variable de pointeur
Diagnostiquer les erreurs d'épinglage en identifiant la valeur sensible à l'adresse et l'opération susceptible de la déplacer.
-
Cargo, crates et éditions : comment un projet Rust est construit et versionné
Cargo construit un crate à partir de Cargo.toml, résout les dépendances avec des plages compatibles SemVer dans Cargo.lock, et peut inclure deux versions majeures incompatibles d'un même crate dans une seule build. Les éditions sont des versions du langage par crate, à activation volontaire, qui restent interopérables : monter l'édition d'un crate n'oblige jamais ses dépendants à suivre.
-
CString à une frontière FFI : distinguer un pointeur emprunté d'une propriété transférée
Maintenir le propriétaire du CString en vie pour les appels par emprunt et n'utiliser la conversion de propriété brute que sous un contrat de retour explicite.
-
Propriété et emprunt en Rust : vue d'ensemble
Chaque valeur Rust a exactement un propriétaire et est détruite (drop) lorsque celui-ci sort de portée ; passer une valeur la déplace, sauf si le type est Copy, et les références l'empruntent selon la règle d'une seule référence mutable ou d'un nombre quelconque de références partagées à la fois. Le vérificateur d'emprunts (borrow checker) applique cette règle à la compilation, ce qui est la source de la sécurité mémoire sans ramasse-miettes.
-
Disposition FFI en Rust : repr(C) sur une structure externe ne répare pas les champs imbriqués
Examiner chaque champ qui traverse une frontière d'ABI C et vérifier la disposition mémoire sur chaque cible prise en charge.
-
Propriété des ressources en FFI Rust : associer le constructeur étranger à son véritable destructeur
Rendre explicites l'allocation, la libération et la durée de vie des rappels (callbacks) dans un wrapper Rust étroit autour de ressources étrangères.
-
Combien de temps supplémentaire faut-il à un ingénieur venu d'un langage dynamique pour devenir productif en Rust par rapport à Go, et quels concepts expliquent l'écart ?
Question ouverte : Go est souvent décrit comme rapide à prendre en main et Rust comme exigeant, et l'enquête State of Rust 2024 rapporte qu'environ 31 % des non-utilisateurs citent la difficulté perçue ; mais peu de sources mesurent le temps jusqu'au premier changement fusionné, le temps jusqu'à une relecture de code sans supervision, ou les concepts (possession/ownership, durées de vie, async, traits) qui consomment ce temps pour des ingénieurs venant de Python, Ruby ou JavaScript.
-
Erreurs Send de Tokio : examiner l'état conservé à travers un await
Corriger un futur (future) lancé en examinant ce qui survit à la suspension, plutôt qu'en ajoutant des implémentations de trait non sûres (unsafe).
-
Traits Rust contre interfaces Go : impl explicite, satisfaction implicite
Les deux langages permettent d'abstraire un comportement sans hiérarchie de classes, mais un type Go satisfait une interface par le simple fait de posséder les méthodes, tandis qu'un type Rust n'implémente un trait que par un bloc impl explicite, soumis à la règle de l'orphelin (orphan rule) ; Rust distingue en outre les génériques à la compilation (monomorphisés) des objets trait dyn (répartition dynamique), un choix que Go fait à la place du programmeur.
-
Result, Option et l'opérateur ? : la gestion des erreurs en Rust
Rust ne connaît ni exceptions ni null : les opérations faillibles renvoient Result<T, E>, les valeurs absentes sont représentées par Option<T>, et les deux sont des énumérations que le compilateur oblige à traiter par filtrage (match). L'opérateur ? renvoie Err ou None de façon anticipée et convertit les types d'erreur via From ; un Result ignoré déclenche un avertissement du compilateur, car le type est marqué #[must_use].
-
Déroulement de pile (unwinding) en Rust FFI : choisir explicitement une frontière de panique et d'exception
Distinguer les retours d'erreur ordinaires, les paniques (panics) Rust et les exceptions étrangères avant de choisir l'ABI de la frontière.
-
Chez les ingénieurs découvrant Rust, le temps d'attente des builds dépasse les erreurs du borrow checker comme principale friction consignée dans les deux premiers mois
Hypothèse : les erreurs du borrow checker dominent la friction que les ingénieurs découvrant Rust consignent au cours de leurs premières semaines, mais leur part diminue rapidement, tandis que les entrées portant sur l'attente des builds (malgré cargo check, que la documentation de Cargo décrit comme sautant la génération de code et donc plus rapide que cargo build) augmentent et deviennent la catégorie la plus importante en l'espace de deux mois ; un test proposé fondé sur un journal de friction, sans résultat avancé.
Lisible par machine : JSON