Retour à Zig — Zig → Rust → Zig

• Zig est parti comme un langage bas niveau visant à réduire les désagréments de C, et mérite aujourd’hui d’être réexaminé grâce à sa philosophie faite d’allocation mémoire explicite et d’absence de flux de contrôle caché
• Rust a été une alternative pragmatique pour s’éloigner des changements fréquents de Zig et de son écosystème immature, mais a montré ses limites sur des points comme la FFI, la compilation croisée et les allocations cachées
• Le retour à Zig s’explique aussi, au-delà des raisons techniques, par une perte de confiance envers le projet Rust autour de sa gouvernance et de sa politique sur le code généré par les LLM
• En 2026, Zig reste instable et Zig 0.17.0 devrait casser le système de build, mais les sensations du langage n’ont pas beaucoup changé depuis 2020 et l’expérience de gestion des paquets s’est améliorée
• Zig ne fournit pas la sécurité mémoire à la compilation à la manière de Rust ; il choisit plutôt un équilibre entre simplicité et sûreté à l’exécution via ReleaseSafe, les tests, le fuzzing et une philosophie des assertions

---

Le point de départ de l’attrait pour Zig

• J’ai découvert Zig en 2020 ; à l’époque, il ressemblait à un petit nouveau langage doté de l’exécution de code à la compilation et d’abstractions simples
• En apprenant C, j’aimais la sensation de contrôler directement l’ordinateur, mais ses abstractions anciennes et son outillage insuffisant étaient pénibles
• Même nouveau et instable, Zig promettait une alternative à C, et l’idée de pouvoir apprendre le « prochain langage » était séduisante
• Software Should Be Perfect d’Andrew Kelley a façonné mes critères pour juger les langages de programmation et les logiciels
  • Allocation mémoire explicite pouvant échouer
  • Aucun flux de contrôle caché
  • Réutilisabilité universelle
• En créant avec Zig un langage de programmation jouet, un outil de literate programming et un serveur web, il m’a semblé plus agréable que C tout en présentant moins de risques

Pourquoi je suis passé à Rust

• Le code Zig cassait souvent, et en tant qu’étudiant je n’avais pas assez de temps pour continuer à adapter mes projets aux dernières versions du langage
• À l’époque, anyzig n’existait pas, ce qui rendait difficile la gestion de plusieurs versions de Zig sur un même système
• En revenant sur un projet après quelques mois, il fallait parfois effectuer un gros refactoring que je ne comprenais pas vraiment pour qu’il fonctionne de nouveau
• L’écosystème était encore réduit
  • En tant que nouveau programmeur, je n’avais pas les compétences pour implémenter moi-même tout ce dont j’avais besoin
  • Il y avait peu de bibliothèques et d’exemples
  • La bibliothèque standard changeait continuellement
  • Même la documentation de base était instable
• Rust était déjà stabilisé depuis plusieurs années et disposait d’un écosystème solide
• Apprendre Rust a été difficile, mais une fois maîtrisé, le code fonctionnait de manière stable, et cette stabilité comptait
• C’était un langage rapide et bas niveau, offrant l’expressivité nécessaire, tout en réduisant le coût de l’instabilité que je rencontrais avec Zig
• Rust m’a aidé à construire un modèle mémoire utile même lorsque j’utilise des langages avec moins de vérifications intégrées
• Dans du code sans panic, il était possible d’écrire du code réutilisable sans flux de contrôle caché ni garbage collector
• Rust avait toutefois tendance à cacher les allocations mémoire et à rendre le travail avec C plus difficile

Les frustrations qui m’ont fait regarder Zig à nouveau

• Rust n’était pas le langage parfait pour créer les programmes réutilisables que je voulais
  • La FFI est difficile
  • La compilation croisée est contraignante
  • Les allocations mémoire cachées, traitées comme si elles ne pouvaient pas échouer, sont pénibles
  • Le lien avec LLVM peut rendre long, voire impossible, le support d’autant de plateformes que C
• La gouvernance est aussi restée un point inconfortable
  • La Rust Foundation compte plusieurs grandes entreprises parmi ses foundation members
  • Si les plus grandes entreprises du monde versent chaque année des centaines de milliers de dollars, il peut y avoir une influence sur l’orientation du développement de Rust
• Le fait que de nombreux projets open source commencent à accepter du code généré par des LLM a été un choc
• Dans plusieurs projets, mainteneurs et utilisateurs ont rédigé ou réclamé des politiques relatives aux LLM
• Zig a totalement interdit les LLM dans son projet
• Rust a mené une enquête et le sentiment général de la communauté était anti-LLM, mais aucune politique officielle n’a été immédiatement adoptée
• La proposition de politique de Rust contenait une clause empêchant d’aborder les sujets suivants dans les commentaires de PR
  • Les effets sociaux et économiques à long terme des LLM
  • L’impact environnemental des LLM
  • Le statut des droits d’auteur des sorties de LLM
  • Les jugements moraux à l’égard des utilisateurs de LLM
• Cette clause a été retirée après les réactions, mais le simple fait qu’elle ait existé a réduit ma confiance envers le projet Rust
• La politique elle-même me semblait acceptable dans l’ensemble, car elle limitait surtout les LLM et réduisait le slop
• Cette expérience m’a poussé à réexaminer sérieusement Zig pour la première fois depuis des années

Zig en 2026

• Zig reste instable
• J’ai essayé de partir d’un exemple Zig 0.16.0 trouvé sur le web, mais il était déjà obsolète
• Pour être productif avec Zig, le mieux est de garder une copie des sources de la bibliothèque standard à portée de main et de s’y familiariser
• Zig 0.17.0 doit sortir bientôt et cassera les systèmes de build de tous les projets
• Les mainteneurs essaient d’aller vers la stabilisation, et ces ruptures font partie de ce processus
• Heureusement, le langage lui-même n’a pas beaucoup changé depuis 2020
  • La plupart de mes intuitions fonctionnaient encore
  • Certaines parties des bibliothèques ont été retravaillées, mais le code restait facile à lire
  • Je pense pouvoir encore reconnaître le code Zig actuel dans six ans
• Zig dispose désormais d’un gestionnaire de paquets
  • Je me souviens qu’avant, on utilisait des git submodules pour gérer les dépendances
  • L’outil intégré est bien meilleur
  • Les projets peuvent définir leurs dépendances via git et des tarballs
  • Le vendoring fonctionne facilement
• L’écosystème n’est toujours pas immense, mais ce n’est pas non plus ce que Zig visait
• Il n’existe pas de registre officiel de paquets, et l’idée est qu’il n’est pas nécessaire d’avoir un autre NPM ou crates.io
• Zig semble aujourd’hui avoir trouvé un bon équilibre

La manière d’envisager la sécurité mémoire

• Zig ne fournit pas les mêmes garanties de sécurité mémoire que Rust
• C’est un compromis en faveur de la simplicité, et je ne pense pas que la complexité des types affines de Rust vaille les gains de sécurité obtenus
• Cela ne signifie pas pour autant que Zig renonce à la sécurité
• Selon la perspective de Zig is safer than unsafe Rust, Zig peut être un meilleur choix dans les situations où il faudrait écrire du Rust unsafe
• Zig travaille aussi à rendre le langage plus sûr
  • L’approche ne se concentre pas sur des zones de code unsafe, mais sur les modes de release
  • Aujourd’hui, le mode ReleaseSafe de Zig plante en cas d’échec d’assertion et initialise toute la mémoire
  • Andrew Kelley s’intéresse à une direction où ReleaseSafe intégrerait quelque chose comme Fil-C
• Cette approche n’offre pas la sécurité mémoire à la compilation de Rust quand on évite unsafe, mais je ne pense pas qu’elle constitue la death spiral décrite par certains
• La sécurité mémoire est un spectre, et il n’existe pas une seule approche optimale pour toutes les situations
• L’approche de Zig consiste à rendre ReleaseSafe aussi sûr que possible à l’exécution, puis à vérifier la correction par les tests et le fuzzing
• Les illegal behaviors non vérifiés doivent être trouvés dans ce processus ; une fois la correction démontrée, on peut déployer en sécurité des binaires produits avec d’autres modes de release
• Cette méthode a des inconvénients par rapport au modèle de Rust, mais dans l’orientation de Zig, qui privilégie fortement la simplicité, je ne la considère pas comme strictement inférieure
• Si la sécurité mémoire à la compilation est assez importante pour justifier le coût d’un système de types complexe et de longs temps de compilation, il faut choisir Rust
• Le modèle de sécurité mémoire de Zig se prolonge aussi dans sa philosophie des assertions
  • Plutôt que de désactiver les assertions en ReleaseFast, on fait confiance aux tests pour avoir prouvé que les assertions sont correctes et que ces chemins sont unreachable
  • Cela permet à Zig d’optimiser le code
  • Un article lié est your assertions are correct

Orientations d’usage à venir

• Je suis prêt à aborder des problèmes logiciels avec Zig en gardant la bibliothèque standard et l’historique des changements de release à portée de main
• Quand je ne voudrai pas gérer les détails bas niveau, j’utiliserai mon langage de script préféré
• Je compte faire de Zig un outil central dans mes futurs logiciels
• Il reste possible que je ne reste pas durablement avec Zig
  • Si j’ai besoin de la stabilité ou du système de types de Rust, je pourrai utiliser Rust
  • Mon avis sur l’approche de Zig pourrait changer complètement
  • Plusieurs langages peuvent et doivent coexister
• Zig représente une vision du logiciel centrée sur l’utilisateur, qui accepte la qualité logicielle au lieu de l’ignorer
• Les gens méritent des logiciels fiables et puissants, et à l’ère des LLM, les logiciels conçus avec soin se raréfient tandis que l’on pousse les gens à accepter un slop de plus en plus mauvais

[clastneo]

J’ai déjà abandonné l’apprentissage de Zig en cours de route après avoir entendu qu’une nouvelle version allait sortir.
Quand une version stable sera disponible, cela vaudra peut-être la peine de le remettre sur ma liste d’apprentissage, mais pour l’instant les breaking changes sont encore trop importants, donc j’ai peur de m’y mettre.

[click]

Zig modifie sans cesse les spécifications du langage en abandonnant la rétrocompatibilité ; dans ces conditions, je pense qu’il est difficile de l’utiliser dans des systèmes critiques, au moins tant que la version 1.0 n’est pas sortie.
Ghostty semble avoir pas mal souffert du changement de std.IO : issue
Pour prendre un exemple dans un autre langage, si, après l’apparition de Future en Java, l’API JDBC avait été modifiée pour retourner des Future ou des CompletableFuture, cela aurait certainement représenté une grande avancée, mais au prix d’une énorme confusion.

[GN⁺]

Avis sur Lobste.rs

• J’aimerais réessayer Zig un jour
  J’en ai vraiment envie, mais jusqu’ici j’ai été pris par d’autres choses
  La dernière fois que j’ai touché à Zig, je suis tombé sur une erreur du compilateur au bout d’environ 3 heures, et ça m’a pas mal marqué. Pour être juste, ce bug était déjà corrigé dans la branche la plus récente

• Je suis dubitatif face à l’affirmation selon laquelle « comme il est lié à LLVM, il lui faudra très longtemps, voire ce sera impossible, pour prendre en charge autant de plateformes que C »
  Je me demande quelles plateformes non prises en charge par LLVM on voudrait cibler, et en quoi Zig serait meilleur sur ce point
  J’aimerais savoir si l’idée est que Zig génère du code C tier-4, que GCC pourrait ensuite compiler pour hppa, alpha ou sh

  • D’après ce que j’ai compris, Zig travaille activement à réduire sa dépendance à LLVM, donc cela voulait plutôt dire qu’à l’avenir, pour implémenter de nouvelles cibles dans le compilateur Zig, il ne sera peut-être pas nécessaire de toucher au projet LLVM lui-même
  • Actuellement, cela se fait via la génération de code C
    Le problème, c’est que Zig dispose de backends officiels autres que LLVM, alors que Rust utilise LLVM
    Un langage système qui cherche à maximiser la réutilisabilité du logiciel devrait pouvoir s’exécuter aussi largement que possible, et c’est particulièrement vrai s’il vise à remplacer C comme Zig
  • De mémoire, assez vaguement, il me semble que l’inquiétude portait davantage sur les temps de compilation que sur la prise en charge des plateformes

• Vu le succès de ghostty, je compte essayer Zig pour le développement de jeux lorsqu’il atteindra la version 1.0
  Cela dit, je ne suis pas sûr que les types de jeux que je crée aient réellement besoin d’un tel niveau de performance

  • Si vous connaissez Godot, vous pouvez essayer https://github.com/godot-zig/godot-zig

• On entend assez souvent des phrases du genre « Zig n’a pas renoncé à la sécurité, et il est plus sûr que unsafe Rust. Si de toute façon vous devez utiliser unsafe Rust, Zig peut être un meilleur choix », mais chaque fois que je les vois, j’ai du mal à comprendre
  En particulier, je trouve étrange que l’auteur reconnaisse que la sécurité est un spectre, tout en recommandant de passer à un langage où tout reste constamment unsafe, au lieu d’utiliser des zones unsafe localisées
  Même si la machine abstraite est peut-être un peu plus facile à raisonner, cet échange ne me convainc pas