Introduction au Zig

Bonjour. Je suis entrain d’écrire un tutoriel sur le langage Zig qui est bien moins connu que C++, Java, PHP, etc. mais qui n’en est pas moins intéressant!

Je vous laisse découvrir le tuto.

Bonjour,

La bêta du contenu « Introduction au Zig » a été désactivée.

Oyez oyez les agrumes !

Je vous annonce avec plaisir la ré-ouverture de la bêta du contenu « Introduction au Zig » ! Je vous souhaite une agréable lecture à l’adresse suivante :

Merci pour votre participation.

Le tuto est absolument loin d’être complet, je veux juste avoir des retours très tôt dans l’écriture

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Salut,

C’est une idée de tuto intéressante. Il n’est pas facile de commenter l’approche générale comme le plan est encore assez succin. Qu’est-ce que tu comptes aborder ? Essentiellement le contenu de la doc présenté à ta sauce ? Ou tu as aussi des idées pour rendre la chose un peu plus originale ?

En particulier, c’est un langage de niche en compétition directe avec notamment Rust mais avec une philosophie bien différente (simplicité et caractère explicite du langage d’un côté, quitte a perdre en expressivité et en robustesse pour Zig ; exposition d’énormément de subtilités importantes en programmation système de l’autre qui rendent le langage très complexe mais aussi très puissant pour Rust). Je pense que le contenu pourrait être rendu très intéressant en présentant des cas de figures où l’approche de Zig offre un avantage précieux (ou l’inverse). On voit beaucoup de discussions à l’emporte-pièce sur ce sujet (qui ne sont pas convaincantes pour être franc), y compris sur le site de Zig lui-même, et avoir des exemples concrets réalistes serait ultra-intéressant. Enfin bref, c’est une idée comme ça.

J’ai par ailleurs quelque remarques sur ce qui est déjà écrit. Je ne suis pas spécialiste de Zig, donc il y a sûrement des choses qui m’échappent par endroits. J’ai surtout relevé des petits problèmes de rigueur. Je pense qu’il est important de faire attention à ce que tu écris, et préférer ne rien dire plutôt qu’essayer de combler ce qui n’est pas clair. La tâche est rendue difficile par le manque de documentation, et il y a probablement beaucoup de choses et de petits détails qui vont bouger avant une version stable de Zig. Je mets à la suite des remarques en vrac qui me sont venus en lisant le tuto.

La façon idiomatique d’écrire sur stdout est de demander explicitement un Writer

const stdout = std.io.getStdOut().writer();

La documentation de la bibliothèque standard étant encore très succincte, il est difficile de comprendre si il y a une différence effective entre les deux à l’usage. Y-a-t-il une raison particulière derrière cette élision de ta part ? Si non, je serais tenté de dire qu’il vaut mieux rester explicite vus les choix forts du langage en ce sens.

Un paquet est en fait juste beaucoup de code qu’on aurait entassé dans une sorte de gros paquet, j’utilise cette appellation dans ce tuto car la métaphore est plus simple à comprendre, mais on dit plus généralement "bibliothèque".

Réutiliser le terme de paquet dans la définition de paquet rend le discours obscur si on ne sait pas déjà de quoi tu parles. Le terme de package est utilisé dans la documentation par ailleurs pour parler de ce qu’on peut passer à import. La distinction avec library n’est pas fait clairement, je pense que tu peux te contenter d’éclaircir la définition et dire que les deux terms sont essentiellement synonymes dans ce contexte.

il est uniquement là car Zig considère qu’afficher un texte dans l’invite de commandes est "dangereux"

Le terme de "dangereux" est nébuleux ici, je pense que dire que l’opération est faillible serait plus correct.

« writeAll » veut dire « tout écrire » en français, « écrire » parce que on va écrire dans l’invite de commandes qu’on a obtenu précedement, et « tout » car on veut s’assurer que notre message arrive en entier, pas par moitié ou seulement la fin.

Je doute sérieusement que write tout court se contente d’écrire seulement la moitié de ses arguments. Là encore le manque de documentation m’empêche de comprendre la différence rapidement à part que write renvoie un u64 en cas de succès (ce qui me fait pencher vers le fait que c’est une interface pour faire de l’IO avec buffer). Par ailleurs, l’idiome semble être d’utiliser print plutôt que writeAll, avec un args vide si inutilisé.

Dans ton paragraphe sur les variables, tu parles surtout des constantes au début. Des variables constantes, c’est assez particulier pour mériter son propre paragraphe, et ça rendrait les choses plus claires.

C’est moins compliqué pour les nombres décimaux (les flottants) car il n’y a pas de valeur maximum ou minimum (mais par contre moins de précision pour les grands nombres) et pas d’histoire de signé ou non-signé, mais il n’y a pas autant de liberté sur le nombre de bits.

Heu… Les nombres flottants sont notoirement plus compliqués que les entiers avec justement les problèmes de précision (beaucoup plus subtils que des bêtes overflow), mais aussi de nan (qui sont contaminants et enlèvent beaucoup de propriétés pratiques sur les comparaisons de flottants comme la réflexivité de l’égalité !). Par ailleurs, il y a effectivement des valeurs maximales représentables avec des flottants ! Pour les flottants f64, tout ce qui est au-dessus d’environ 1.8e308 est projeté sur Infinity. Pour les flottants f32, c’est tout ce qui est au-dessus d’environ 3.4e38. La situation est symétrique dans les négatifs. En terme de valeur absolue, tu as aussi des limites basses non-nulles sur ce que tu peux manipuler avec le cas particulier des nombres dénormalisés.

La précision d’un f32 suffit pour 99% des cas, un f64 peut aussi être utilisé pour plus de précision mais elle ne se sent qu’avec au moins 10–15 chiffres après la virgule, il n’y a pas d’autres types de nombre décimaux avec lesquels s’embêter (mis à part c_longdouble, f16 et f128 dont je ne parlerais pas dans ce tutoriel).

Mouais, les propagations d’erreurs en calcul flottant rendent la question beaucoup plus subtile. Bref, l’arithmétique des nombres flottants est très compliquée par rapport à celle des entiers bornés. C’est bien évidemment en dehors du cadre du tutoriel, et je pense donc qu’il serait plus sage de se contenter de quelque faits bruts sur les types f32 et f64 sans rentrer dans les détails ni l’écueil d’une comparison avec les entiers.

Zig sait qu’une chaîne de caractères est toujours de type []const u8

Il faudrait expliciter ce type.

const std = @import("std");

pub fn main() !void {
  const stdout = std.io.getStdOut();
  try stdout.write("Hello World !");
}

Ce code ne compile pas, parce que la valeur de retour de write est ignorée.

const writer = stdout.writer();
try writer.format("{} + {} = {}\n", .{a, b, a + b});

format n’existe pas, tu veux dire print j’imagine.

Bref, prends le temps de poser les explications (insister sur les notions de type, dire que le type est statique etc me semble important mais est manquant par exemple) et bien vérifier ce que tu écris plutôt que t’enferrer sur des détails que tu ne connais pas forcément très bien (comme les flottants).