La documentation du langage Rust (le langage qui veut remplacer le C et le C++ en sécurisant l’accès mémoire et en supprimant le ramasse-miette) est écrite en Markdown.
Comme cette documentation doit pouvoir suivre l’évolution du langage (et donc évoluer avec chaque version de Rust) l’équipe Rust a créé mdBook pour pouvoir générer un livre en PDF à partir de chapitres HTML écrits en Markdown.
Licence de mdBook
mdBook est un logiciel libre sous licence Mozilla Public Licence v2.0.
Vous pouvez en trouver les sources pour y contribuer sur GitHub (https://github.com/rust-lang/mdBook).
Pour savoir comment contribuer à améliorer mdBook suivez le guide en anglais (https://github.com/rust-lang/mdBook/blob/master/CONTRIBUTING.md).
Installation de mdBook 0.52
Les fichiers sources d’installation sont disponibles sur GitHub pour MacOS, Windows, et Linux.
Vous pouvez aussi installer mdBook, si vous avez installé au préalable le langage Rust sur votre ordinateur en écrivant dans une fenêtre de Terminal la commande :
cargo install mdbook
Comme cela vous pourrez voir en direct comment cargo compile un programme Rust.
Création de votre mdBook
Mettez mdBook dans la variable PATH de votre poste, pour lancer les commandes mdbook depuis n’importe quel endroit.
Pour créer un mdBook, utilisez votre terminal pour lancer la commande mdbook init livre-exemple.
Cette commande créera le répertoire vide « livre-exemple ».
mdBook vous posera alors plusieurs questions pour créer votre premier livre vide.
Allez dans ce nouveau répertoire avec la commande cd livre-exemple (\home\nom_utilisateur\livre-exemple sur un ordinateur GNU/Linux).
Puis lancez le serveur Web local de votre livre avec la commande mdbook serve --open.
Cette commande va lancer le serveur Web local et ouvrir votre navigateur par défaut sur votre mdBook vide.
Fichiers de configuration
book.toml
Ce fichier contient le titre de votre futur livre dans le champ "title".
Il contient aussi un champ « author » à renseigner avec votre nom (ou votre pseudo-littéraire) et un champ « langage » qui par défaut à la valeur « en », mais que vous pouvez évidemment modifier en « fr » avec votre éditeur de texte favori (gedit par exemple sous GNU/Linux).
src/SUMMARY.md
Ce fichier contient la structure de votre futur livre (la liste des chapitres).
Pour créer facilement un chapitre, une préface, une introduction, une annexe… ajoutez des lignes dans ce fichier Markdown.
Par exemple :
# Summary
- [00-Introduction](./Introduction.md)
- [01-Mon premier chapitre](./01-mon-premier-chapitre.md)
Les chapitres seront créés vides dans le répertoire src au fur et à mesure de votre saisie dans le fichier src/SUMMAY.md par le programme mdBook.
Publication de votre mdBook
Une fois vos chapitres créés en Markdown avec votre éditeur de texte, publiez votre mdBook avec la commande :
mdbook build.
Cette commande créera un répertoire \livre-exemple\book. Vous pourrez diffuser ce sous-répertoire « book » sur votre serveur Web en le transférant par FTP.
Astuce : rien ne vous empêche de renommer ce répertoire « book » en fr-livre-exemple-2026 avant de le transférer en FTP sur votre serveur Web.
Les 4 fonctionnalités de votre mdBook
1) La table des matières s’affiche en cliquant sur le menu hamburger en haut à gauche de votre page Web.
2) Vous pouvez changer le thème de votre page Web en cliquant sur le pinceau (par défaut le thème affiché est « Auto »).
3) Vous pouvez chercher un mot dans votre mdBook en cliquant sur la loupe.
4) Vous pouvez imprimer ce livre (au format PDF, ou sur votre imprimante) en cliquant sur l’icône de l’imprimante en haut à droite de votre page Web.
Utilisations possibles de mdBook
Vous pouvez utiliser mdBook pour créer la documentation multilingue de votre logiciel libre (par exemple un mdBook en français et un mdBook en anglais), voire de votre distribution GNU/Linux préférée.
Vous pouvez préciser la licence de votre livre en créant un chapitre licence, et par exemple choisir de publier votre livre en licence Creative Commons, Cecill ou Art Libre.
Aller plus loin
- Langage Rust (43 clics)
- La traduction non-officielle de la documentation de Rust (51 clics)
- La documentation de mdBook (en mdBook) (118 clics)
- L'article de Korben sur le mdBook (142 clics)
# Quel ramasse-miettes ?
Posté par Jona . Évalué à 4 (+2/-0).
La première ligne dit :
À quel ramasse-miettes fait-on référence (et il y a une coquille: ramasse-miette -> ramasse-miettes) ?
[^] # Re: Quel ramasse-miettes ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+9/-0).
https://fr.wiktionary.org/wiki/ramasse-miettes
et
https://fr.wiktionary.org/wiki/ramasse-miette
Les deux écritures sont donc possibles.
[^] # Re: Quel ramasse-miettes ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Sans doute celui de Java (par exemple), mais qui n'est pas mentionné.
Avant Rust (plus ou moins), il n'y avait que deux choix :
1. Un langage sécurisé mais avec un ramasse-miettes (langage de haut niveau).
2. Un langage sans ramasse-miettes, mais moins sécurisé (langage de bas niveau).
Rust combine les avantages des deux.
[^] # Re: Quel ramasse-miettes ?
Posté par steph1978 . Évalué à 4 (+2/-0). Dernière modification le 15 mars 2026 à 07:15.
De Lisp, de lua, de python, de ruby, de perl, de go,…
Tous les langages dit de haut niveau, ont une gestion automatique de la mémoire par ramasse-miettes.
[^] # Re: Quel ramasse-miettes ?
Posté par gUI (Mastodon) . Évalué à 9 (+6/-0). Dernière modification le 17 mars 2026 à 08:35.
Au prix d'un enfer pour le programmeur.
Ce n'est pas un défaut en soit, tant mieux si le programmeur doit se creuser la tête au profit d'un produit final de meilleure qualité, mais il faut le savoir. Rust est un langage compliqué.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quel ramasse-miettes ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Est-ce que l'absence de GC donne vraiment de meilleurs résultats en général ?
Sur des cas extrêmes où de toute façon il faut faire super attention aux allocations mémoires, même avec un système à la Rust, je veux bien, mais sinon les ramasse-miettes modernes me semblent plus efficaces sur 99% des cas que la tête (même bien creusé) des développeurs ?
Ça rappelle un peu les débats sur les boites de vitesse automatiques et manuelles :-)
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Quel ramasse-miettes ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
ou un Débat déjà refait, zic souvent entendues, et mars :-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Quel ramasse-miettes ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . Évalué à 4 (+2/-0). Dernière modification le 20 mars 2026 à 16:35.
Rust force à avoir une meilleure architecture de code, et permet d'éviter en grande partie ce que j'appelle l'« architecture spaghetti » où tout dépend de tout (« sea of objects » en anglais, mais en bon français ça sonne moins bien ;) ).
(L'expression « code spaghetti » est plus général et peut ne concerner qu'un seul fichier source / une seule classe).
Rust, en d'autres mots, force à avoir une architecture ressemblant à un arbre :
- Il y a les feuilles : fonctions et classes utilitaires ne dépendant de rien d'autres de ce module (ça peut évidemment dépendre d'autres bibliothèques).
- Puis d'autres classes dépendant des « feuilles ».
- Et ainsi de suite en remontant l'arbre, on construit des trucs au-dessus des autres.
- Pour arriver à la fonction
main()qui est le nœud tout au-dessus de l'arbre (le point d'entrée pour le programme ; pour une bibliothèque il y a plusieurs points d'entrées : les symboles exportés).(Pour rester compréhensible j'utilise le vocabulaire usuel de la POO, pas le vocabulaire spécifique à Rust).
Le truc à éviter est si une classe feuille dépend d'une classe proche de la racine. Une classe proche de la racine a potentiellement accès à tout le reste du module. Donc c'est comme ça que « tout dépend de tout » et c'est entremêlé comme des spaghetti (cuits).
Avoir une architecture de classes sous forme d'arbre, ou un DAG (directed acyclic graph) est tout à fait possible dans n'importe quel langage orienté objets. Ça ressemble plus à un grand gâteau à plusieurs étages, ou encore une lasagne (mais je préfère le gâteau).
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.