La version 0.9.0 de ZIG, le langage de programmation compilé, inspiré de Rust et conçu pour concurrencer le C, est disponible,

Avec une amélioration de l'interface mem.Allocator et bien plus

La version 0.9.0 de ZIG, le langage de programmation compilé, inspiré de Rust et conçu pour concurrencer le C, est disponible,
avec une amélioration de l'interface mem.Allocator et bien plus

La Zig Software Fondation, organisme en charge du langage ZIG, a annoncé le 22 décembre la disponibilité de la version 0.9 du langage de programmation ZIG. L’objectif du langage inspiré de Rust, selon ses concepteurs, reste de concurrencer (et d'améliorer) le langage C. Cette nouvelle version apporte une amélioration de l'interface mem.Allocator, une correction des caractéristiques CPU de l'assemblage RISC-V. Cependant, certains pensent que Zig pourrait facilement récupérer la plupart de ces optimisations s'il existait une sorte de membres immuables.

Conçu par Andrew Kelley, Zig est un langage de programmation compilé impératif polyvalent, typé statiquement. Selon la documentation de Zig, le langage est conçu pour la « robustesse », l'« optimalité » et la « maintenabilité », prenant en charge les génériques et la réflexion au moment de la compilation, la compilation croisée et la gestion manuelle de la mémoire. Zig possède de nombreuses fonctionnalités pour la programmation de bas niveau, notamment des types composés (struct) avec zéro padding, des entiers de taille arbitraire et différents types de pointeurs.


Le compilateur est écrit en Zig et C++, utilisant LLVM 11 comme back-end, prenant en charge plusieurs de ses cibles natives. Le compilateur est un logiciel libre et open source, distribué sous la licence MIT. Le compilateur Zig fournit la possibilité de compiler du C et du C++, similaire à Clang en utilisant respectivement la commande zig cc et zig c++. Le langage de programmation Nim prend en charge l'utilisation de zig cc comme compilateur C.

WebAssembly

« Avec la version 0.9.0, nous avons franchi quelques étapes importantes. Le linker autonome pour wasm a été réécrit, avec les connaissances acquises lors de la construction d'un linker autonome pour wasm », indique la Zig Software Fondation. En effet, le linker est maintenant capable de construire une disposition de la mémoire avec une pile virtuelle, ainsi que d'effectuer des relocations. Ce sont là quelques-unes des fonctionnalités nécessaires à l'implémentation de zig test.

À ce jour, le backend wasm auto-hébergé est maintenant capable de passer 13 % de tous les tests comportementaux. Avec tous ces changements, la contribution au backend wasm est beaucoup plus facile. L'éditeur de liens est maintenant suffisamment performant pour que seule une connaissance de wasm soit nécessaire pour contribuer au backend.

RISC-V

Correction des caractéristiques CPU de l'assemblage RISC-V. Auparavant, Zig ne communiquait pas correctement les caractéristiques du CPU pour RISC-V à l'assembleur Clang, car Clang a une manière différente de transmettre les caractéristiques du CPU pour le code C et pour le code assembleur. Ce commit fait passer à Zig un tag RISC-V -march afin de communiquer les caractéristiques du CPU à Clang lors de la compilation des fichiers d'assemblage.

Allocgate

L'interface mem.Allocator a été modifiée dans la version 0.9.0 de ZIG. Pour modifier le code, La Zig Software Fondation recommande de :

• changez *Allocator en Allocator dans les types de paramètres de fonctions et les types de champs de structures ;
• au lieu de prendre le pointeur vers un champ allocateur, tel que &gpa.allocator, il serait mieux d’utiliser un appel de fonction comme ceci : gpa.allocator().

L'interface rand.Random a été modifiée de manière équivalente aux modifications de l'interface Allocator, tous motivées par la recherche des performances.

Zig aurait utilisé le pointeur vtable à l'intérieur de l'objet pour la bibliothèque standard, mais cette approche semblait lente car le compilateur n'était pas en mesure d'effectuer de nombreuses optimisations possibles en C++. « La propriété la plus cruciale qui bénéficie de la conception du C++ est que le pointeur vtable ne peut pas changer pendant toute la durée de vie de l'objet, même si l'objet est transmis par pointeur/référence à une fonction externe », « Chers tous, l'annonce de l'allocgate m'a fait réfléchir. Il y a généralement deux façons d'implémenter le polymorphisme d'exécution par le biais des vtables : le pointeur vers la vtable à l'intérieur de l'objet, et le pointeur vers la vtable à côté du pointeur vers l'objet (fat pointer). Le premier est utilisé par le C++, tandis que le second est utilisé par Rust. », ajoute-t-il.

Notons qu’un objet immuable, en programmation orientée objet et fonctionnelle, est un objet dont l'état ne peut pas être modifié après sa création. Ce concept est à contraster avec celui d'objet variable. Avant l'apparition de la programmation orientée objet, les variables d'exécution dont le contenu n'était pas destiné à changer en cours d'exécution (par exemple, le facteur de conversion permettant de transformer des livres en kilogrammes, ou encore la valeur de pi avec plusieurs décimales) étaient connues sous le nom de constantes, pour les différencier de celles qui pouvaient être modifiées.

Dans la plupart des langages orientés objet, les objets sont manipulés par des références. C'est le cas, par exemple, de Java, des objets de type class de C# et de Swift (contrairement aux objets de type struct), de Python, de JavaScript et de Ruby. Dans ce cas, le fait que l'état d'un objet partagé par référence puisse ou non être modifié est important.

Lorsqu'un objet est réputé immuable, on peut en obtenir une copie en dupliquant simplement sa référence, au lieu de copier l'objet entier. Comme une référence (qui n'occupe typiquement en mémoire que la taille d'un pointeur) est habituellement bien moins volumineuse que l'objet lui-même, cette technique permet à la fois d'économiser de la mémoire et d'améliorer la vitesse d'exécution.

Système de construction Zig

Le système de construction Zig est invoqué par la commande zig build, qui exécute un script déclaratif build.zig pour collecter les options et décrire le graphe des étapes, puis fournit des options pour exécuter ces étapes. Bien qu'il soit déjà essentiel à presque tous les projets Zig, le système de construction Zig est encore expérimental et instable. En tant que système de compilation, la stabilité est particulièrement importante, mais elle ne peut être atteinte tant que le langage n'est pas stabilisé. La stabilité du langage est le prochain point d'attention de la feuille de route.

Pour certains programmeurs, « Zig pourrait facilement récupérer la plupart de ces optimisations s'il existait une sorte de membres immuables (les membres d'un objet qui ne peuvent pas changer après sa création). » Si le pointeur de la vtable n'a pas changé depuis sa création (et pointe vers une vtable const), alors le compilateur devrait être capable de dévirtualiser les appels, même si l'objet peut changer, car il connaît la valeur de la vtable, estiment ces derniers. « Je ne dis pas que nous devrions revenir au fat pointer, mais j'aimerais être capable d'implémenter le polymorphisme d'exécution dans les deux sens de manière efficace. »

Zig peut-il concurrencer le langage C ?

Le langage C a toujours été un langage à feuilles persistantes et a joué un rôle prépondérant dans la plupart des développements de systèmes qui ont eu lieu au cours des dernières décennies. La programmation C a été développée à l'origine par Dennis Ritchie entre 1969 et 1973 aux Bell Labs et a été conçue pour la programmation informatique impérative à usage général, qui supporte la programmation structurée, les variables lexicales, la portée, la récursion, etc. Aujourd'hui, il existe une multitude de langages de programmation à choisir et à apprendre, mais en tant que débutant, tout le monde se pose la...