Zig ça me fait penser à l'expression "C'est qui l'autre zig ?" 🤣 Première fois que j'entends parler de ce langage, merci pour la découverte. Les afficionados du JS, ils osent pas le dire mais ils sont de plus en plus nombreux à utiliser TS. 😉
Super vidéo! Merci! Pour un néophyte, tu t'es très bien débrouillé. Ça me fait plaisir d'entendre parler de Zig sur un canal francophone. La duplication plutôt que l'abstraction est le slogan du langage. Il y a de la métaprogrammation via les comptimes (qui ressemblent à des formes de macros que j'ai connues en Common Lisp mais sans générer de syntaxe additionelle). Le comptime est mieux que les macros/XMacros: n'importe quel linter ou code analyzer peut comprendre le code (de plus, les macros C, c'est une zone grise que je trouve dangereuse; l'absence de l'homoiconicité y est pour quelque chose aussi). C'est aussi pourquoi il n'y a pas de polyadisme: on n'a pas d'arguments optionnels pour les tokens comme sur un `printf` comme en C mais un tuple (`struct` anonyme comme unique second paramètre du `print`). Zig est pur procédural avec un paradigme orienté "data oriented programming" avec un niveau de sécurité que C/C++ n'ont pas pour l'instant. Tout doit être explicite donc attention lorsque l'on crée une `literal string`, le système d'inférence le type en `C string`. Pour avoir un Zig string sans terminateur et sliceable, il faut le déclarer explicitement (un piège pour les débutants). J'aime en Zig des choses très cools comme les slices, le payload capturing pour la gestion d'erreurs/optional et, dans la bibliothèque standard, des allocators déjà bien construits. J'ai découvert Zig il y a deux ans via le `zig build` un système déclaratif remplaçant cmake ou ninja pour compiler des projets (en C): et oui, comme tu l'as dit dans ta vidéo, Zig peut compiler du C, du C++ et du Zig. Pour le temps de compilation, il faut savoir que le projet n'est pas fini (le comptime utilise toujours du code python pour remplacer les outputs dans l'AST). Une fois, les caches faites, c'est bien plus rapide (évitez les versions avant l'actuel release 0.13). Et concernant la syntaxe `.*` pour déréférencer, c'est totalement justifié par le cascading: en fait, on peut écrire `pointer_foo.bar()` pour `pointer_foo.*.bar()`. Le futur de Zig prévoit de se passer de LLVM. Cerise sur le gâteau: la communauté Zig et Andrew Kelley (le créateur ) sont très dynamiques et "friendly" (comme les communautés de Roc: un nouveau langage que je teste en ce moment, inspiré de Elm et développé en Rust). Conseil pratique pour les éditeurs VSCode/Neovim ou Emacs, faites attention que la version de ZLS (le Language Server Protocol) matche bien la version. Encore merci! 👍
C'est chouette de voir Zig toucher un peu à la francophonie. Je sais que tu n'es pas allé très loin dans ton apprentissage du Zig, tu le dis toi-même. Mais je ne peux pas laisser une coquille comme celle à 9:20. Zig est parfaitement capable de faire de la compilation conditionnelle. À dire vrai c'est même un de ces points forts à mon avis, la compilation conditionnelle se fait très naturellement. Par exemple: ```zig // comme "std", le nom "builtin" référence un module spécial. Ce module contient des informations sur les options de compilations // notamment mode de build (Debug, ReleaseSafe, ReleaseFast, ou ReleaseSmall), mais aussi la plateforme cible. const builtin = @import("builtin"); const implementation = if (supportMainImplementation(builtin.target)) @import("main_implementation") else @import("fallback_implementation"); ``` Il est possible grâce à comptime d'exécuter du code quasiment arbitraire à la compilation. Les opérations interdites à ma connaissance sont: - l'inline assembleur, - modifier une valeur externe au bloc comptime, - leaker une référence variable comptime. L'analyse sémantique en Zig est paresseuse. C'est-à-dire que dans mon example, même si "main_implementation" ne pouvait pas compiler pour ma plateforme cible, le code compile malgré tout, puisque de toute façon @import("main_implementation") ne sera même pas analysé. Bref, à part ça chouette vidéo. Zig a une philosophie particulière qui ne convient ni à tout le monde ni à tous les usages, mais j'apprécie beaucoup le côté explicite et le sentiment de contrôle qu'il confère.
C'est peut-être expliqué dans la vidéo :-) Idées personnelles : par rapport à Rust, c'est parce que je ne pige rien au borrow checker et à son modèle de mémoire, par rapport à Go, c'est parce que Zig ne dépend pas d'un runtime, ce qui est pratique pour l'embarqué.
Pas de GC par rapport à Go, gestions des ressources explicite (defer, ...) par rapport à Rust (qui est plus implicite de ce côté), mais la syntaxe est pas hyper fun/consistante je trouve (un entre deux vs Go et Rust). La toolchain est lente par contre mais efficace
@bortzmeyer j'ai vu le vidéo mais cela ne me permet pas de me dire que je vais changer pour cela. Changer c'est prendre un risque et cela ne me semble pas valoir le coût.
Le Rust ca m a fait penser a Eiffel :D Truc de vieux ... donc j ai bien aime :D apres les langages qui annoncent qu ils vont remplacer le C ... on s'comprends :D
Perso j'adore Zig. C'est simple efficace et avec un design vraiment cool. Typiquement un moment "ooohhh" dans la compréhension du language c'est de comprendre le système de struct anonymes. Quand on déclare une struct, il faut faire const myStructName = struct { ... }; Et quand on import un fichier, on fait const file = @import("blabla.zig"); ou const somePartOfAFile = @import("blabla.zig").foo; Et si on se rappel que les structs en Zig peuvent contenir des fonctions et de méthodes, et qu'on explore les fichiers de la lib standard comme Build.zig. On comprend qu'en faite il n'existe en Zig que des variables, des fonctions et des structs anonymes et un fichier importé est traité comme une struct anonyme. Vu qu'on a du code qui s'exécute à la compilation en Zig, ça veut dire qu'on peut écrire une boucle for qui print tous les symboles d'un fichier qu'on import.
Encore un qui veux tous révolutionné et recrée la roue... Java, JavaScript, Rush, et tous les language de programmation de type pointer ne sont bon que pour la poubelles. Pq ? L'interpretation de ces language prend énormément de temps machine et en plus comporte des failles de sécurité. ( Oui un pointer et par nature une faille de sécurité, car ci la mémoire est sécurisée, c'est justement pour empêché d'utilisé des pointers ). Je suis un vieux, mais vraiment un très vieux, même ci je comprend l'utilisé du C et C++, pour moi le seul language valable est l'ASM qui une fois compilé est jusqu'a 2 fois plus rapide que de c++. Le phyton est génial pour du proof of concept ou apprendre a la programmation, mais l'ASM restera le maitre toutes catégorie. PS: Le premier qui me dit que le C est un language de bas niveau, je lui met mon pied au cul.
Clairement Zig est moins puissant que Rust (moins sécurisé, optimisable...) mais il est parfait pour les réfractaire au Rust car il est plus proche du C et "plus simple" dans son approche. Zig reste supérieur au C (productivité). Il est beaucoup utilisé pour les petits soft qui doivent s'interfacer avec du C... notamment on le retrouve beaucoup chez les hacker ;)
Pour le coup, je ne suis pas spécialement convaincu par certains aspects du Zig, notamment certaines syntaxes, mais comme je l'ai dit, je suis encore peu avancé sur ce langage
Hello, Bonne intro ! Pour appuyer ce que dit Martial plus bas, le "comp time" n'est pas comme les génériques et va au dela des macros. Il s'agit de générer du code pendant la phase de compilation, en utiisant la même syntaxe que lors que le code sera compilé ensuite. La génération de code permet donc de faire des optimisations très pointues et bien sur qui s'adapteraient au processeur.
Oui, c'est un mix entre l'inlining, les macros et la généricité. Je reste convaincu que l'absence de macros (comme en C, C++, Rust, ...) est dommageable pour certains usages. Mais c'est un avis probablement biaisé du fait que je ne maitrise pas encore ce langage
@@ponceto91 bon ben est pas daccord sur les termes alors pour moi - statique = variable & data ont un type et ils doivent match - fort = seul le data a un type et il ne peut pas changer - dynamique = le data a un type qui peut changer en fonction du contexte (je connais que javascript qui fait ca puisque php n'est pas un langage)
Le dynamique est à comparé avec le static: - static: une fois qu'un type a été déclaré de manière explicite ou inferé, il ne pourra plus jamais changé - dynamic: le type d'une variable peut changer au cours du temps Par contre la difference entre typage fort et faible vient du fait qu'un type n'a pas le meme 'poids' dans son utilisation: - faible: JavaScript va permettre implicitement la comparaison entre un string du genre "10" avec un int 10 sans problème - fort: en Python les types doivent etre respecté quand ils sont comparés et utilisés ensemble (même si de souvenir des types comme les float et les ints peuvent se comparer)
![⏳ [Etienne Klein] Peut-on voyager dans le temps ?](http://i.ytimg.com/vi/DyVEU71Azno/mqdefault.jpg)
![⏳ [Etienne Klein] Peut-on voyager dans le temps ?](/img/tr.png)
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Zig ça me fait penser à l'expression "C'est qui l'autre zig ?" 🤣 Première fois que j'entends parler de ce langage, merci pour la découverte. Les afficionados du JS, ils osent pas le dire mais ils sont de plus en plus nombreux à utiliser TS. 😉
Super vidéo! Merci! Pour un néophyte, tu t'es très bien débrouillé. Ça me fait plaisir d'entendre parler de Zig sur un canal francophone.
La duplication plutôt que l'abstraction est le slogan du langage. Il y a de la métaprogrammation via les comptimes (qui ressemblent à des formes de macros que j'ai connues en Common Lisp mais sans générer de syntaxe additionelle). Le comptime est mieux que les macros/XMacros: n'importe quel linter ou code analyzer peut comprendre le code (de plus, les macros C, c'est une zone grise que je trouve dangereuse; l'absence de l'homoiconicité y est pour quelque chose aussi). C'est aussi pourquoi il n'y a pas de polyadisme: on n'a pas d'arguments optionnels pour les tokens comme sur un `printf` comme en C mais un tuple (`struct` anonyme comme unique second paramètre du `print`).
Zig est pur procédural avec un paradigme orienté "data oriented programming" avec un niveau de sécurité que C/C++ n'ont pas pour l'instant. Tout doit être explicite donc attention lorsque l'on crée une `literal string`, le système d'inférence le type en `C string`. Pour avoir un Zig string sans terminateur et sliceable, il faut le déclarer explicitement (un piège pour les débutants). J'aime en Zig des choses très cools comme les slices, le payload capturing pour la gestion d'erreurs/optional et, dans la bibliothèque standard, des allocators déjà bien construits.
J'ai découvert Zig il y a deux ans via le `zig build` un système déclaratif remplaçant cmake ou ninja pour compiler des projets (en C): et oui, comme tu l'as dit dans ta vidéo, Zig peut compiler du C, du C++ et du Zig.
Pour le temps de compilation, il faut savoir que le projet n'est pas fini (le comptime utilise toujours du code python pour remplacer les outputs dans l'AST). Une fois, les caches faites, c'est bien plus rapide (évitez les versions avant l'actuel release 0.13). Et concernant la syntaxe `.*` pour déréférencer, c'est totalement justifié par le cascading: en fait, on peut écrire `pointer_foo.bar()` pour `pointer_foo.*.bar()`.
Le futur de Zig prévoit de se passer de LLVM. Cerise sur le gâteau: la communauté Zig et Andrew Kelley (le créateur ) sont très dynamiques et "friendly" (comme les communautés de Roc: un nouveau langage que je teste en ce moment, inspiré de Elm et développé en Rust). Conseil pratique pour les éditeurs VSCode/Neovim ou Emacs, faites attention que la version de ZLS (le Language Server Protocol) matche bien la version.
Encore merci! 👍
Merci à toi pour ce commentaire très complet et tes retours 🙏
C'est chouette de voir Zig toucher un peu à la francophonie.
Je sais que tu n'es pas allé très loin dans ton apprentissage du Zig, tu le dis toi-même.
Mais je ne peux pas laisser une coquille comme celle à 9:20.
Zig est parfaitement capable de faire de la compilation conditionnelle. À dire vrai c'est même un de ces points forts à mon avis, la compilation conditionnelle se fait très naturellement. Par exemple:
```zig
// comme "std", le nom "builtin" référence un module spécial. Ce module contient des informations sur les options de compilations
// notamment mode de build (Debug, ReleaseSafe, ReleaseFast, ou ReleaseSmall), mais aussi la plateforme cible.
const builtin = @import("builtin");
const implementation = if (supportMainImplementation(builtin.target))
@import("main_implementation")
else
@import("fallback_implementation");
```
Il est possible grâce à comptime d'exécuter du code quasiment arbitraire à la compilation. Les opérations interdites à ma connaissance sont:
- l'inline assembleur,
- modifier une valeur externe au bloc comptime,
- leaker une référence variable comptime.
L'analyse sémantique en Zig est paresseuse. C'est-à-dire que dans mon example, même si "main_implementation" ne pouvait pas compiler pour ma plateforme cible, le code compile malgré tout, puisque de toute façon @import("main_implementation") ne sera même pas analysé.
Bref, à part ça chouette vidéo. Zig a une philosophie particulière qui ne convient ni à tout le monde ni à tous les usages, mais j'apprécie beaucoup le côté explicite et le sentiment de contrôle qu'il confère.
@themathophage8238 Merci pour ton retour et Ton petit correctif 👌 comme je le disais, je peux dire des erreurs par méconnaissance.
Pourquoi les français dissent "Python" à la française mais tout les autres langages vous le dites avec l'accent anglais ?
Moi je prononce tout à la française 😁
@@tigidou3344 c'est lié au fait que le mot "python" existe en français avec exactement la même orthographe.
Parce-que si on le prononçait à l’Anglaise et tous les autres langages avec l’accent français, tu aurais posé exactement la même question
Et en plus ces "f*cking" th (excuse my french) on sait jamais comment prononcer ça :)
Haha ^^
Hello. Je ne vois pas bien pourquoi utiliser Zig comparé a Rust ou Go.
C'est peut-être expliqué dans la vidéo :-) Idées personnelles : par rapport à Rust, c'est parce que je ne pige rien au borrow checker et à son modèle de mémoire, par rapport à Go, c'est parce que Zig ne dépend pas d'un runtime, ce qui est pratique pour l'embarqué.
Pas de GC par rapport à Go, gestions des ressources explicite (defer, ...) par rapport à Rust (qui est plus implicite de ce côté), mais la syntaxe est pas hyper fun/consistante je trouve (un entre deux vs Go et Rust). La toolchain est lente par contre mais efficace
@bortzmeyer j'ai vu le vidéo mais cela ne me permet pas de me dire que je vais changer pour cela. Changer c'est prendre un risque et cela ne me semble pas valoir le coût.
Le Rust ca m a fait penser a Eiffel :D Truc de vieux ... donc j ai bien aime :D apres les langages qui annoncent qu ils vont remplacer le C ... on s'comprends :D
@@drakkhenn42 Eiffel le truc de la fac? Genre le langage ou tu fais nimp mais ça tourne quand-même... Pas fan de ce truc.
Perso j'adore Zig. C'est simple efficace et avec un design vraiment cool. Typiquement un moment "ooohhh" dans la compréhension du language c'est de comprendre le système de struct anonymes.
Quand on déclare une struct, il faut faire
const myStructName = struct { ... };
Et quand on import un fichier, on fait
const file = @import("blabla.zig"); ou const somePartOfAFile = @import("blabla.zig").foo;
Et si on se rappel que les structs en Zig peuvent contenir des fonctions et de méthodes, et qu'on explore les fichiers de la lib standard comme Build.zig. On comprend qu'en faite il n'existe en Zig que des variables, des fonctions et des structs anonymes et un fichier importé est traité comme une struct anonyme.
Vu qu'on a du code qui s'exécute à la compilation en Zig, ça veut dire qu'on peut écrire une boucle for qui print tous les symboles d'un fichier qu'on import.
Encore un qui veux tous révolutionné et recrée la roue... Java, JavaScript, Rush, et tous les language de programmation de type pointer ne sont bon que pour la poubelles.
Pq ? L'interpretation de ces language prend énormément de temps machine et en plus comporte des failles de sécurité. ( Oui un pointer et par nature une faille de sécurité, car ci la mémoire est sécurisée, c'est justement pour empêché d'utilisé des pointers ).
Je suis un vieux, mais vraiment un très vieux, même ci je comprend l'utilisé du C et C++, pour moi le seul language valable est l'ASM qui une fois compilé est jusqu'a 2 fois plus rapide que de c++. Le phyton est génial pour du proof of concept ou apprendre a la programmation, mais l'ASM restera le maitre toutes catégorie.
PS: Le premier qui me dit que le C est un language de bas niveau, je lui met mon pied au cul.
Mais pourquoi tant de haine ? 😂
@@ponceto91 Parse que je suis un vieux de la génération de BILL and co qui a appris d'abord l'ASM et le hardware avant le C. XD
Clairement Zig est moins puissant que Rust (moins sécurisé, optimisable...) mais il est parfait pour les réfractaire au Rust car il est plus proche du C et "plus simple" dans son approche. Zig reste supérieur au C (productivité). Il est beaucoup utilisé pour les petits soft qui doivent s'interfacer avec du C... notamment on le retrouve beaucoup chez les hacker ;)
Pour le coup, je ne suis pas spécialement convaincu par certains aspects du Zig, notamment certaines syntaxes, mais comme je l'ai dit, je suis encore peu avancé sur ce langage
@ponceto91 je ne suis pas développeur Zig mais je me tiens informé et c'est le ressentiment général après avoir lu les avis de développeurs.
Hello,
Bonne intro !
Pour appuyer ce que dit Martial plus bas, le "comp time" n'est pas comme les génériques et va au dela des macros.
Il s'agit de générer du code pendant la phase de compilation, en utiisant la même syntaxe que lors que le code sera compilé ensuite. La génération de code permet donc de faire des optimisations très pointues et bien sur qui s'adapteraient au processeur.
Oui, c'est un mix entre l'inlining, les macros et la généricité. Je reste convaincu que l'absence de macros (comme en C, C++, Rust, ...) est dommageable pour certains usages. Mais c'est un avis probablement biaisé du fait que je ne maitrise pas encore ce langage
javascript a un typage dynamique mais pas.python.
python a un typage fort
@@konkerouf python est bien un langage à typage dynamique, fort mais dynamique
@@ponceto91 bon ben est pas daccord sur les termes alors
pour moi
- statique = variable & data ont un type et ils doivent match
- fort = seul le data a un type et il ne peut pas changer
- dynamique = le data a un type qui peut changer en fonction du contexte (je connais que javascript qui fait ca puisque php n'est pas un langage)
Tu as une mauvaise interprétation de typage dynamique
Le dynamique est à comparé avec le static:
- static: une fois qu'un type a été déclaré de manière explicite ou inferé, il ne pourra plus jamais changé
- dynamic: le type d'une variable peut changer au cours du temps
Par contre la difference entre typage fort et faible vient du fait qu'un type n'a pas le meme 'poids' dans son utilisation:
- faible: JavaScript va permettre implicitement la comparaison entre un string du genre "10" avec un int 10 sans problème
- fort: en Python les types doivent etre respecté quand ils sont comparés et utilisés ensemble (même si de souvenir des types comme les float et les ints peuvent se comparer)