Le backend x86 auto-hébergé devient la valeur par défaut en mode debug

• Désormais, pour les cibles x86_64, le backend x86 auto-hébergé de Zig est appliqué par défaut en mode debug
• Il atteint un plus grand nombre de tests de comportement réussis et des temps de compilation plus rapides que l’ancienne base LLVM
• L’adoption du backend maison permet à Zig de réduire fortement les temps de compilation et d’améliorer l’efficacité de certaines tâches
• Plusieurs renforcements ont récemment été menés, notamment sur le système de build, l’élargissement du support des OS de la famille BSD et l’amélioration du runtime UBSan
• L’optimisation de la bibliothèque standard et des outils maison met en avant la compétitivité propre à Zig

---

Résumé des principales nouveautés

8 juin 2025 – Le backend x86 auto-hébergé devient la valeur par défaut en mode debug

• Sur les cibles x86_64, le backend x86 auto-hébergé de Zig est désormais utilisé par défaut
  • Auparavant, Zig utilisait LLVM pour convertir le bitcode en fichier objet
  • Sous Windows, le changement reste reporté car un travail supplémentaire est nécessaire sur l’éditeur de liens COFF
• Le backend x86 de Zig a validé 1 987 tests de comportement, montrant une stabilité supérieure à celle du backend LLVM (1 980)
  • Le total est de 2 084 tests, mais certains font doublon avec les tests propres à LLVM et ne sont donc vérifiés en plus que lors des tests du backend maison
• La principale raison pour laquelle Zig se concentre sur le développement de son propre générateur de code est de dépasser largement LLVM en vitesse de build
  • D’après les benchmarks, le temps de build moyen de zig build-exe hello.zig -fllvm (avec LLVM) est de 918 ms, contre 275 ms avec le backend maison
  • L’amélioration des performances est très nette sur tous les plans : mémoire consommée, cycles CPU, nombre d’instructions, cache misses, etc.
  • Même pour de gros projets comme le compilateur Zig lui-même, le temps de build passe de 75 secondes à 20 secondes
• La suite prévoit une parallélisation complète de la génération de code, un renforcement des fonctions de linkage et le développement du backend aarch64
  • L’introduction d’un nouveau passage Legalize doit aussi accélérer le travail sur aarch64
• Les changements les plus récents peuvent être testés directement via les derniers builds de la branche master de Zig

6 juin 2025 – Vidéo de présentation du système de build

• Une vidéo guide sur YouTube destinée aux débutants du système de build Zig a été publiée
  • Elle explique comment créer des modules et des packages Zig, puis comment les importer dans d’autres projets
  • D’autres vidéos sur le système de build doivent être ajoutées progressivement à la série

20 mai 2025 – Renforcement du support des cibles FreeBSD et NetBSD

• Avec la fusion des Pull Requests #23835 et #23913, zig cc et zig build peuvent désormais produire des binaires pour les cibles FreeBSD 14.0.0+ et NetBSD 10.1+
  • La stratégie déjà utilisée avec glibc pour extraire les informations sur libc et les bibliothèques associées a été étendue aux systèmes de la famille BSD
  • Les fichiers abilists générés sont distribués avec Zig, ce qui permet, lors de la cross-compilation, de créer des bibliothèques stub correspondant précisément à chaque bibliothèque libc
  • Les headers système et libc sont également fournis sur la base de la version la plus récente de l’OS
  • OpenBSD, Dragonfly BSD, SerenityOS, Android et Fuchsia figurent aussi parmi les cibles visées

9 avril 2025 – Le site officiel de Zig est désormais buildé comme un Zine autonome

• Le site officiel de Zig adopte désormais une structure où il est buildé comme un Zine autonome
  • Il a évolué depuis un script de build existant vers un exécutable unique
  • Le projet indique que c’est un bon moment pour l’essayer directement

Nouvelles de release et améliorations de fonctionnalités

• La release 0.14.0 doit être publiée prochainement, et plusieurs améliorations notables sont déjà en place
• Grâce aux améliorations de l’interop C et du runtime UBSan (Undefined Behavior Sanitizer), les erreurs SIGILL autrefois ambiguës sont remplacées par des messages d’erreur précis et utiles
  • Exemple : l’emplacement et la cause d’un overflow d’entier signé sont indiqués clairement, ce qui améliore fortement l’efficacité du débogage
• Limites restantes d’UBSan :
  • absence de prise en charge des vérifications de type dynamique et de cycle de vie liées à vptr en C++
  • indication encore incomplète de la position exacte pour des attributs comme assume_aligned, __nonnull, etc.

7 février 2025 – Refonte de l’allocateur de debug et avancées de SmpAllocator

• L’allocateur de debug a été repensé pour prendre en charge la taille de page à l’exécution et intégrer diverses optimisations
  • réduction de la création de memory maps, suppression des répétitions inutiles de memset 0xaa/0x00, retrait des structures de recherche et de trip, etc.
  • les métadonnées sont stockées inline dans la page, ce qui facilite l’implémentation des erreurs de compilation et de la validation
  • il gagne en lisibilité et en maintenabilité par rapport aux anciens malloc en C
• Le développement de SmpAllocator, optimisé pour les environnements concurrents, maximise l’efficacité de l’allocation mémoire en environnement multi-thread
  • des benchmarks comparatifs avec glibc ont démontré concrètement ses gains en vitesse et en usage des ressources
  • cela est présenté comme un tournant important où l’utilisabilité de Zig dépasse celle du C et de libc

24 janvier 2025 – Un environnement de débogage dédié à Zig

• Jacob a développé un fork de LLDB pour Zig, renforçant le support du débogage du backend auto-hébergé
  • La documentation du wiki explique comment build et utiliser ce fork de LLDB
  • Les développeurs utilisant le backend maison de Zig peuvent ainsi bénéficier d’un environnement de débogage plus fin

Conclusion

• Zig poursuit des changements ambitieux avec pour objectifs centraux l’amélioration des performances, l’efficacité du build et la facilité du débogage
• Le langage est en train d’affirmer une compétitivité différenciante à travers ses algorithmes, son compilateur et ses outils de build/runtime indépendants
• Avec l’élargissement du support de plateformes comme BSD, l’amélioration des messages orientés utilisateur et l’innovation autour du modèle mémoire, Zig continue d’apporter des avancées concrètement utiles aux ingénieurs logiciels

[GN⁺]

Commentaires sur Hacker News

• Si j’ai bien compris, Zig travaille chaque jour sur diverses fonctionnalités pour améliorer l’expérience de développement. Par exemple, il y a eu récemment cette PR. Le hot code swapping faisait aussi partie des plans de développement de Zig par le passé, et à ce rythme, j’imagine que ce sera probablement possible sur x86_64 d’ici un an. Le plus gros point de friction pour moi reste la vitesse de comptime. J’avais fait une expérience consistant à exécuter une DSL brainF** à la compilation, et c’était vraiment lent (même si l’expérience était amusante). Je me demande à quel moment cette partie du compilateur sera améliorée. J’attends aussi énormément les nouveaux backends, et j’aimerais même essayer de créer mon propre backend URCL pour Zig 😉

  • Concernant l’amélioration des performances de comptime, on sait déjà ce qu’il faut faire et une branche dédiée avait même été lancée il y a longtemps. Mais cela implique de retravailler à une échelle significative le code d’analyse sémantique, donc même si c’est un sujet important, il est en concurrence avec d’autres priorités

  • Le hot code swapping pourrait changer énormément de choses dans le développement de jeux. Le fait que Zig prévoit de le prendre en charge nativement avec un simple flag du compilateur me paraît étonnant. C’est le genre de chose qui est difficile à envisager avec clang

  • Je n’ai pas regardé URCL en profondeur, mais ça m’entraîne déjà dans un nouveau terrier de lapin. Ça fait imaginer un scénario vraiment étrange où un IR conçu pour Minecraft finirait par devenir une véritable cible de compilation pour un langage

  • Je me demande à quel point il est simple de créer un backend personnalisé. Je n’ai pas encore essayé moi-même, mais j’aimerais expérimenter un backend qui prenne l’AIR et produise un rapport de sûreté mémoire (par exemple pour détecter l’usage de valeurs non définies, l’échappement du pointeur de pile, les use-after-free, les double free, les alias xor mut, etc.)

  • Je me demande si le vrai problème est que comptime soit vraiment lent. Je travaille sur une bibliothèque JSON-RPC, et j’utilise fortement comptime à la compilation pour distribuer du JSON vers des fonctions arbitraires. Avec le typage statique puissant de Zig, il est impossible de faire au runtime une distribution dynamique vers des fonctions ayant des paramètres arbitraires, donc j’ai dû générer à la compilation une table de correspondance des types de fonctions. Ce qui m’inquiète, c’est qu’avec cette approche le code produit par comptime est dupliqué pour chaque fonction, donc la taille du binaire ne peut qu’augmenter

• Le simple fait d’en être déjà arrivé là est impressionnant. Comme indiqué dans le devlog, la suite donne encore plus envie. L’idée que le compilateur ne modifie, pendant le build, que les parties nécessaires du binaire semble à la fois nouvelle et radicale, et grâce au projet Zig cela devient maintenant un objectif réalisable. La période à venir s’annonce vraiment passionnante

• Il est mentionné que, pour un gros projet comme le compilateur Zig, le temps de build est passé de 75 secondes à 20 secondes.
  Je suis vraiment curieux de voir jusqu’où cela pourra encore être amélioré. J’ai l’impression que les développeurs de Zig sont extrêmement brillants.
  Je me demande aussi à quoi ressemble la gestion de paquets. J’avais autrefois essayé de faire une appli QuickJS + SDL3 en Zig, mais j’ai fini par passer à Rust, dépassé par la complexité de C++. J’aimerais bien retenter en Zig

  • La gestion de paquets de Zig est plus manuelle que celle de Rust. On récupère directement l’URL du paquet en CLI, puis on importe les modules dans le script de build. L’avantage, c’est qu’on peut facilement utiliser même des archives arbitraires comme dépendances, et beaucoup de paquets Zig pour des bibliothèques C se contentent de raccorder directement des releases non modifiées (tarballs) dans le script de build. En revanche, cela peut être un peu complexe pour les débutants
    Pour SDL3, il existe deux options : un wrapper Zig natif (https://github.com/Gota7/zig-sdl3) et https://github.com/castholm/SDL, qui expose plus simplement la bibliothèque / l’API C dans un style Zig
    QuickJS ne prend en charge que l’API C (https://github.com/allyourcodebase/quickjs-ng)
    Zig permet d’utiliser très facilement des paquets C directement, mais comme le typage est strict, il faut parfois faire souvent des conversions de types pour manipuler l’API

  • Le compilateur D dmd peut se compiler lui-même en environ 18,4 secondes en build debug.
    Mon processeur est un très vieux AMD Athlon 64 X2 (4400+), mais comme il reste très rapide, je ne l’ai même pas encore remplacé
    (liste détaillée des informations CPU incluse)

  • Je me demande s’il existe un guide pour compiler Zig en 20 secondes afin d’avoir un cycle de développement rapide. La dernière fois que j’ai essayé de builder Zig, il y avait plusieurs stages, surtout le bootstrap en WASM, et cela prenait vraiment longtemps

  • Le fait que Zig compile encore lui-même en 75 secondes tout en utilisant LLVM est déjà extrêmement impressionnant

• Je n’ai absolument pas l’intention d’exiger quoi que ce soit de Zig, et je sais bien que c’est de l’open source, mais ce qui m’intéresse le plus, c’est un calendrier réaliste pour la sortie de la 1.0.
  Zig est quasiment le langage bas niveau que j’attendais, et je suis maintenant dans l’attente de sa stabilisation.
  Et j’admire sincèrement sa philosophie de conception minimaliste

  • De ce que je sais, des projets réels comme tigerbeetle utilisent généralement une version de release figée et réservent les nightly à l’expérimentation

• En tant que parfait débutant, je me demande quels sont les avantages de Zig par rapport aux autres langages. Je le vois comme un C plus moderne, mais je me demande ce qui est exactement « moderne »

  • Quelques avantages qui me viennent tout de suite à l’esprit
    • un système de build intégré, sans avoir à combiner plusieurs outils et langages distincts
    • des slices dont la longueur est explicitement connue, au lieu des tableaux C (et des problèmes de buffer overflow)
    • un type optional explicite, où les pointeurs null ne sont pas autorisés par défaut (et le type l’indique clairement quand c’est nécessaire)
    • des enum, tagged union, et une vérification exhaustive imposée dans les switch
    • une gestion des erreurs explicite (un peu à la Rust). Si une fonction peut renvoyer une erreur, l’appelant ne peut pas l’ignorer. Ce n’est pas comme en C, où l’on peut passer outre en ignorant la valeur de retour. En revanche, c’est dommage qu’il n’existe pas de syntaxe standard pour renvoyer à la fois une erreur et des données
    • les blocs defer et errdefer pour exécuter automatiquement le nettoyage au retour de fonction ou en cas d’erreur
    • de la génération de code via comptime à la place des macros, avec réflexion de type (@typeInfo, etc.)
    • les allocateurs mémoire sont gérés directement par l’appelant (ce qui donne plus de contrôle sur l’emplacement et la manière d’allouer)
    • avec GeneralPurposeAllocator, il est plus facile (pour un débutant) de suivre les fuites mémoire
      Je n’étais pas familier avec C, et j’ai toujours ressenti une barrière d’entrée vers la programmation bas niveau à cause de ses nombreux aspects peu raisonnables et peu intuitifs. Zig est le premier langage qui m’a fait trouver la programmation système amusante et intéressante

• Je me demande s’il existe un guide pour compiler Zig en 20 secondes. Je voulais accélérer mon cycle de développement, mais j’ai déjà trouvé qu’il était difficile de contribuer parce que stage1/2/3 prenaient tous longtemps à builder

• Si zig init produit un hello world de 9,3 Mo en build par défaut dans Zig, l’utilisation du flag -Doptimize=ReleaseSmall le réduit à 7,6 Ko
  Un seul flag peut donc produire un écart de plus de 1000x

  • En réalité, 82 % de cette différence vient des informations de debug
    -OReleaseSmall -fno-strip donne 580 Ko, et -ODebug -fstrip peut descendre à 1,4 Mo
    Le backend x86 de Zig offre une bien meilleure expérience de débogage avec un fork LLDB dédié à Zig
    Je ne me souviens plus très bien si on peut déjà suivre pas à pas la logique comptime pendant le débogage, mais c’était récemment un sujet de discussion

• Je me dis que Julia pourrait envisager Zig comme compilateur pour obtenir des gains de performance. Je me souviens aussi de l’inquiétude récurrente des développeurs Julia à chaque release à cause du risque de régressions de performance

  • Julia est en réalité très fortement lié à LLVM. De nombreuses parties de son écosystème dépendent de l’existence des intrinsics LLVM, de l’autodiff (Enzyme), de la compilation GPU, etc.
    Le compilateur devient progressivement assez retargetable, et ce point fait aussi l’objet de recherches actives actuellement.
    À l’avenir, on peut imaginer Zig comme compilateur alternatif pour certaines parties du langage

  • Certains estiment qu’LLVM constitue en lui-même l’API publique de Julia. Il existe d’ailleurs des macros comme @code_llvm qui exposent directement l’IR

  • Cela aiderait certainement à réduire le temps de compilation, mais il reste encore beaucoup de travail côté Julia
    Il y a par exemple un cache de compilation à rendre plus granulaire, des outils pour éviter l’invalidation, la suppression de l’optimisation world splitting, une meilleure exploitation du multithreading dans le compilateur, la précompilation automatique pour certaines signatures, ou encore la compilation lazy / le hot swap du code

• C’est une avancée énorme pour Zig, et je pense que cela deviendra l’un de ses principaux éléments de différenciation face à Rust. Au passage, j’ai écrit moi-même une grande partie du code de rendu de l’outil d’analyse de performance, et je suis content que mon code soit largement utilisé en ligne
  lien vers le projet poop

  • Rust a lui aussi une tentative similaire basée sur cranelift
    Voir rustc_codegen_cranelift

• J’ai l’impression que c’est justement l’une des conditions préalables au retour d’async/await dans Zig
  La FAQ officielle de Zig sur async vaut aussi le détour

  • Tout cela est déjà bien cadré, et nous devrions pouvoir partager des mises à jour intéressantes d’ici 2 à 3 mois. Nous sommes en train de retravailler l’ensemble de l’I/O, presque comme si nous recréions la bibliothèque standard

  • D’après le lien, on dirait qu’async pourrait ne jamais revenir, ou en tout cas qu’il ne faut pas en rêver avant 2028 au minimum