Les langages informatiques

À propos des langages C, C++, Python, Rust

1 — Compilateurs Rust (Windows, Mac, Linux)

Ce qui ne change pas

C'est le même compilateur, rustc (via cargo), qui existe pour Linux, Windows et macOS. Ce n'est pas "un compilateur différent par système" au sens où il faudrait apprendre un autre outil.

Ce qui change, en revanche

Le résultat est spécifique à la plateforme :

cargo build sur Linux produit un binaire ELF pour Linux ;
le même code compilé sur Windows produira un .exe (PE) ;
sur macOS, un binaire Mach-O.

Conclusion

Le code source Rust est portable, le binaire compilé ne l'est pas.

La méthode la plus simple : compiler sur chaque système

En pratique, la façon la plus fiable de produire une version Windows de votre appli, c'est de disposer d'une machine Windows (ou VM) avec Rust installé, et d'y lancer cargo build — chaque OS compile "chez lui".

La compilation croisée existe, mais elle est plus délicate. Rust permet en théorie de compiler depuis Linux vers Windows (via rustup target add x86_64-pc-windows-gnu par exemple), mais il faut alors un linker compatible avec la cible, parfois un SDK système. Pour des projets avec egui/eframe (qui dépendent de bibliothèques graphiques natives — winit, wgpu), ça se complique nettement : ces crates ont des dépendances propres à chaque plateforme (X11/Wayland sur Linux, Win32 sur Windows, Cocoa sur macOS).

En pratique, les projets Rust "réels" utilisent l'intégration continue (GitHub Actions, par exemple) : on déclenche des builds en parallèle sur des machines virtuelles Linux, Windows et macOS, chacune compilant nativement pour son propre système, et on récupère les trois binaires à la fin.

La formulation la plus juste

Le même code source Rust peut être compilé sur chaque système, mais il faut le compiler séparément sur (ou pour) chaque plateforme cible — ce n'est pas un compilateur différent, mais une compilation différente par plateforme.

Bon sujet de discussion en écho à PHP, qui lui s'exécute tel quel partout où un interprète PHP tourne (portabilité du code interprété vs code compilé).

Autres questions qui pourraient être abordées : le linking, les target triples, ou pourquoi wgpu a besoin de bibliothèques graphiques différentes selon l'OS.

2 — Les réticences envers Rust

Elles sont généralement assez identifiables :

La courbe d'apprentissage du borrow checker — illustrée par exemple avec livres_affiches.clone() dans l'exercice Bibliothèque : certains la trouvent frustrante plutôt que pédagogique, surtout venant de langages plus permissifs.
La verbosité perçue face à des langages comme Python — plus de cérémonie syntaxique pour des tâches simples.
Les temps de compilation, réels sur de gros projets (avec toutes les dépendances graphiques).
Une préférence pédagogique pour des langages où l'on voit un résultat plus vite, sans se heurter d'abord au compilateur — on pourrait par exemple préférer Python pour introduire les concepts algorithmiques sans la friction du typage strict et de l'ownership.
Un pythoniste chevronné voit sans doute le typage statique et l'ownership de Rust comme des contraintes qui ralentissent l'écriture, là où d'autres y voient plutôt un garde-fou qui enseigne en même temps qu'il contraint.

Conclusion : quel choix ?

Python pour la vivacité de prototypage et la lisibilité immédiate.
Rust pour la rigueur et la compréhension fine de ce qui se passe "sous le capot" (mémoire, ownership, typage).

Les deux ont leur place selon l'objectif visé.

Le cas Linus Torvalds

Une nuance importante :

Torvalds n'a pas rejeté Rust : il l'a lui-même accepté comme second langage officiel du noyau Linux dès 2021-2022, porté par d'autres mainteneurs convaincus de ses garanties de sécurité mémoire. Il reconnaît même volontiers l'avantage de Rust sur ce point précis : "Le langage C est un langage très simple ; parce qu'il est simple, il est aussi très facile de faire des erreurs. Et Rust, non."
Sa préférence personnelle pour C ne vient donc pas d'un rejet de Rust, mais d'un attachement à la simplicité directe* de C : un code C, une fois compris, se traduit assez fidèlement en ce que fait la machine, sans couche d'abstraction à interpréter.
C'est en revanche C++ qu'il rejette beaucoup plus durement — non pas pour sa complexité en soi, mais parce qu'il estime que ce langage cache des opérations (allocations mémoire implicites, gestion des exceptions) que le programmeur système doit, selon lui, garder sous les yeux en permanence. Rust, à l'inverse, apporte une vraie sécurité mémoire en échange de sa complexité — ce qui explique qu'il ait fini par être officiellement intégré, même si Torvalds reste, à titre personnel, plus à l'aise dans la simplicité crue de C.

À noter aussi : depuis près de 20 ans, Torvalds ne programme quasiment plus lui-même le noyau. Son rôle actuel est celui de "development lead" : il accepte ou refuse les pull requests proposées par les mainteneurs de sous-systèmes, plutôt que d'écrire du code au quotidien.

3 — Rust : deux fichiers `.db`, avec quoi les lire ?

Deux pistes pour ouvrir un fichier .db SQLite :

En ligne de commande

Avec l'utilitaire sqlite3 (souvent déjà installé sur une distribution Linux, sinon sudo apt install sqlite3) :

sqlite3 bibliotheque.db
sqlite> .tables
sqlite> SELECT * FROM livres;
sqlite> .schema livres
sqlite> .quit

Avec une interface graphique

Plus confortable : DB Browser for SQLite (sudo apt install sqlitebrowser), qui permet de parcourir les tables façon tableur, exécuter des requêtes SQL, et voir la structure — un bon complément visuel à ce qui est déjà vu avec phpMyAdmin côté MariaDB.

Pourquoi deux fichiers ? C'est probablement lié à l'endroit d'où l'on a lancé cargo run. Le code ouvre Connection::open("bibliotheque.db") — un chemin relatif au répertoire courant. Si cargo run a été lancé une fois depuis la racine du projet et une autre fois depuis, par exemple, un terminal ouvert dans un IDE avec un répertoire de travail différent, SQLite aura créé deux fichiers distincts à deux endroits différents.

On peut vérifier avec :

find ~ -name "bibliotheque.db" 2>/dev/null

Un piège classique

Celui des chemins relatifs, qu'on retrouve aussi en PHP avec des include mal placés selon d'où le script est appelé.

4 — Comprendre jusqu'au bout de la chaîne (sans forcément tout auditer)

Pour MkDocs, la chaîne complète, au niveau conceptuel :

Vos fichiers .md — texte brut que vous écrivez.
mkdocs.yml — la configuration qui dit où trouver les pages et comment les organiser.
MkDocs (Python) — lit ces fichiers, les parse avec une bibliothèque Markdown, applique le thème Material, écrit du HTML/CSS/JS dans site/.
CPython — l'interpréteur qui exécute ce code Python ligne par ligne, sans compilation préalable.
Le système d'exploitation — CPython lui-même est un programme, exécuté par le noyau Linux, qui lui alloue mémoire et temps processeur.
Le matériel — au bout du compte, tout ça devient des instructions machine exécutées par le processeur.

Ce qui distingue cette chaîne de la boîte noire que redoutait Torvalds à propos de C++ : chaque niveau est documenté et son fonctionnement général est public, même si l'on ne lit jamais le code source ligne par ligne. Savoir que Python interprète au lieu de compiler, que le noyau gère la mémoire, pourquoi MkDocs choisit de transformer du Markdown en HTML plutôt qu'autre chose — cela suffit à dissiper l'impression d'opacité, sans nécessiter l'exhaustivité.

C'est d'ailleurs exactement la posture qu'on adopte en médecine ou en physique : on comprend le mécanisme de la coagulation sans reséquencer soi-même chaque protéine, on comprend la relativité sans redériver les équations de champ à chaque fois.