Qu’est-ce qui rend le langage de programmation Zig unique ?

• Des experts ont souligné que du « code pouvant être exécuté à la compilation » était une « idée stupide », mais Andrew Kelley, le créateur de Zig, a continué et l’a implémenté
• Quelques années plus tard, c’est devenu l’une des fonctionnalités phares de Zig
• Dans Zig, ce qu’on appelle comptime est du code qui doit être exécuté à la compilation
  • Les développeurs Zig peuvent tirer parti du fait que du code Zig soit exécutable pendant la compilation pour écrire du code générique et faire de la métaprogrammation, même sans prise en charge des génériques/templates

[lifthrasiir]

Il y a déjà un problème dès le premier paragraphe... Du côté des langages de programmation, le calcul au moment de la compilation relève de ce qu’on appelle la programmation multi-étapes, qui est l’une des façons de mettre en œuvre la métaprogrammation. Ce n’est pas du tout une idée stupide.

Dans des langages comme C++, qui ont fini par implémenter la programmation multi-étapes un peu « par accident », on se retrouve avec le problème que le code diffère fortement d’une étape à l’autre (dans ce cas, entre le temps de compilation et le temps d’exécution) ; C++ a bien constexpr désormais, mais cela reste encore insuffisant à bien des égards. Zig, en revanche, a été conçu dès le départ avec la programmation multi-étapes à l’esprit, ce qui lui donne l’avantage de permettre l’utilisation d’un code presque identique au moment de la compilation et à l’exécution, tout en ayant aussi l’inconvénient qu’il y a relativement peu d’éléments prévisibles au moment de la compilation.

[bus710]

Donc… si je comprends bien, l’idée est de faire d’abord tourner, à la compilation, ce qui peut l’être via l’inévitable unittest,
et de faire remonter en erreurs de compilation ce qui deviendrait sinon des erreurs d’exécution… en gros, c’est comme ça qu’on peut le comprendre.
À voir rapidement la documentation et les questions-réponses, le fait de pouvoir remplacer le C en drop-in est aussi assez séduisant. Et contrairement à Rust, le fait que la syntaxe soit simple est appréciable. Bien sûr, ce ne sera sans doute pas aussi sûr que Rust… mais on a aussi l’impression qu’on ressentira moins ce côté suringénierie qu’on peut avoir en utilisant Rust. Go est lui aussi souvent cité comme point de comparaison, mais dans certaines situations, Zig, qui n’a pas de runtime, sera forcément moins contraignant. Surtout si l’on descend davantage au niveau bas, ou si l’on n’a pas besoin de traiter un très grand nombre de requêtes, cela peut devenir une option plus attirante que Go…
Du coup, je me dis que si Zig parvient à bien se positionner entre Rust et Go, cela pourrait être un choix étonnamment pertinent.