Andréas Livet a écrit 231 commentaires

L’installation (compilation) se poursuit sans problèmes et le temps dependent de la performance du système , j’ai essayé :

Il faut savoir que la compilation du binaire v se fait via gcc par défaut. En revanche la compilation des binaire issue de fichier écrit en v via la commande v ou v run se fait par défaut avec tcc et est extrêmement rapide. Le fait que tout le code se retrouve dans un fichier .c doit aider un peu je pense.

a.p.d. La version 0.4.0 les annotations sont balisées différemment ( par @[] )

Tu veux dire les attributs (genre [inline] etc.) non ?
Je viens de le voir dans la release note, dommage que la doc ne soit pas mise à jour en conséquence. Bon en même temps c'est en 0.4.1 qui est sortie la semaine dernière.

Je suis aussi assez enthousiaste par rapport à ce langage.

Par difference au C, les macros sont matérialisés par du code écrit en V, qui est interprété au pas de compilation.

C'est un des aspect du langage que je n'aborde pas dans la dépêche, mais il est en effet possible d'avoir du code qui s'exécute à la compilation, un peu à l'instar de comptime en Zig mais beaucoup moins générique. Ça reste néanmoins un outil de méta programmation assez puissant et un moyen de remplacer l'usage des maccros dans certains cas (cross compilation). La notion de file embedded est particulièrement intéressante je trouve. Voir la doc à ce sujet. Ce qui est marrant c'est que Zig a exclus cette possibilité dans comptime, car ce n'est pas cross platform.

le projet est financé

As-tu des informations la dessus ? J'ai l'impression que la situation est moins claire que pour d'autres projets qui sont sous l'égide de fondation par exemple.

Mais le projet se questionne sur ce qui semble une bonne idée pour créer de l'adoption mais pourrait les freiner dans le développement d'une toolchain plus efficace pour le langage lui-même.

Je ne savais pas qu'ils souhaitaient à long terme se défaire de LLVM. C'est un noble objectif et en même temps super ambitieux !
Ils ont l'air d'être déterminé et j'ai hâte de voir ce que ça peut donner.

Pour moi Rust est juste mieux quand on veut de la performance, il permet de tout optimiser:

Je ne comprend en quoi Rust est plus performant concernant l'allocation mémoire ?
Ni en quoi les macros de Rust sont plus efficaces que le comptime de Zig.

Pour moi, l'intérêt principal de Rust reste la garantie qu'il n'y aura pas de problème avec la mémoire (fuite etc.), mais niveau perf, ce sont deux langages qui permettent d'avoir des performances similaires.

Peut-être même que Zig encourage des façon de coder plus adaptés à la performance, comme le "Data Oriented Design", notamment avec des sucres syntaxiques pour pouvoir facilement boucler sur des structures de tableaux.

En tout cas, Zig est réputé pour permettre d'écrire du code extrêmement performant.

Zig a déjà des mécanismes permettant de détecter les fuites de mémoire (sauf en ReleaseFast), mais c'est vrai que le principe de RAII est intéressant.

ça s'implémente bien en C++ car il y a cette notion de destructeur. Dans un langage comme Zig, il faudrait trouver un moyen d'associer une fonction à une structure de donnée qu'on alloue.

Après, comme tu le dis, ça pourrait passé par une sorte de "super defer" ou peut-être justement par les allocateurs ?
Comme on passe l'allocateur, on pourrait peut-être préciser si la mémoire doit être libérée à la sortie du scope ? Bon dans tous les cas, tu pourrai oublié d'utiliser cet allocateur.

De ce que j'avais compris des premières présentation de Zig, Andrew semblait avoir des idées pour améliorer la gestion de la mémoire. Le langage est encore jeune, peut-être que ce genre de changement est encore possible ? Ça a peut-être été proposé (j'ai pas regardé) ?

Et bah voilà !

J'ai codé ça rapidement, j'utilise une petite bidouille avec le raw mode du module readline, mais ça fonctionne.

J'essaierai de voir si je peux pas faire plus simple au niveau de la récupération des inputs et du mode raw.

Pas encore pris le temps d'en faire un journal, mais ça va venir.

Merci pour cette dépêche !

Plus je lis sur Zig et plus j'aime ce langage.
Je ne l'utiliserai certainement pas pour tous les usages, mais quand on fait de l'embarqué ou du système, c'est vraiment chouette.

Le système de build intégré au langage est au début assez déroutant, mais l'idée de pouvoir tout faire dans le même langage et avec un seul binaire est vraiment séduisante.

J'apprécie aussi particulièrement la possibilité de pouvoir utiliser une bibliothèque C par un simple @cImport
J'adore ce petit exemple, qui montre que Zig est plus lisible que C même en appelant des bibliothèques C. Bref, c'est un meilleur C, comme le dit son auteur.

Le comptime aussi c'est juste magique, je n'ai pas encore trop joué avec, mais ça donne plein d'idées. J'avais été impressionné par le code de print présenté dans la doc. Ça vaut le coup de passer un peu de temps pour comprendre une telle fonction.
Ce qui est fou c'est que comptime permet de faire de la généricité sans rien ajouter au langage !

Il y a plein d'autres aspects à explorer comme la gestion "sécurisée" des pointeurs.

Il y a aussi plein de conf intéressantes à voir sur le sujet, notamment celle sur le recodage de la libC, malheureusement je n'arrive pas remettre la main dessus, peut-être que c'était pas ça le titre…

Bref, c'est un beau projet qui a de beaux jours devant lui.

En lisant un peu plus sur l'historique de Go, ça semble même venir du langage Newsqueak de Rob Pike

Merci pour la découverte (ou peut-être redécouverte je ne sais plus :)) de ce langage.
Souvent, les bonnes idées viennent de langages académiques qui n'ont pas percés (par exemple la notion de channel de Go vient de Limbo il me semble).

Ça donne du code plutôt verbeux j'en conviens, mais tout est explicite. Et le fait que ça ne soit pas une feature de la syntaxe du langage fait une feature de moins à apprendre.

Ce point est à mon avis important.

La force de Go est d'être épuré au maximum (je crois qu'il n'y a que 18 mots clés) et donc de reduire au maximum l'effort cognitif pour appréhender le langage : pas trop de nouveaux concepts (bon, les coroutines et les channels c'est déjà pas mal) et un syntaxe claire et explicite.

Là où V se démarque, c'est justement dans ces petits choix syntaxiques qui apportent beaucoup de fluidités à l'écriture. Alors c'est vrai, c'est pas toujours très explicite (les variables "magiques" it, err etc.), mais ça rend le code assez léger.

Il y a un aspect moins formel que l'on retrouve généralement plus dans des langages comme python et javascript. Je viens personnellement du C++ à la base et j'ai rapidement été écœuré par le côté ésotérique de la syntaxe et les lenteurs de compilation, puis après j'ai plus codé dans des langages de scripts et ce qui m'écœure aujourd'hui c'est le manque de compilation en amont, le typage faible.

V tente de continué dans la lancé de Go, tout en allant peut-être plus loin dans l’expressivité du code et j'aime bien le résultat.

Après, je code "peu" en V, je lis beaucoup dessus, suit son développement de près, mais ça reste au stade d'expérimentation. Je comprends à 100% que l'on ne veuille pas s'y mettre.

PS : je suis allé voir la gestion des erreurs en zig, c'est de l'implicite couplé à la gestion implicite des optional, ça me file la nausée ^

Ah c'est assez étonnant comme remarque, car Zig est justement connu pour être explicite. Dans ce sens où il n'y a pas d'appel de fonction caché, pas d'allocation implicite.
Je trouve le choix d'intégré la gestion d'erreur comme un élément de la syntaxe plutôt judicieux. Cela limite la verbosité du code et rend la gestion d'erreur plus confortable.

J'ai tout de même l'impression qu'avec ces notions de Optional/Result on arrive à une sorte de consensus (ou plutôt de convergence) où beaucoup de langages récents ont fait le choix de traiter les erreurs et les retours de fonction de cette manière.

Malheureusement j'ai l'impression après la lecture de cette dépêche qu'une bonne partie du langage est encore à l'état de promesses.

Oui, il y a un "déjà là" fonctionnelle et tout de même plutôt abouti, mais l'écart entre ce qui est annoncé et la réalité est assez important.
C'est pour moi la plus grosse erreur des concepteurs du langage : de mettre en avant certains aspects qui sont encore très très expérimentaux (gestion de la mémoire, ui etc.).

Non V a utilise aussi un ramasse miette. Il cherche aussi à développer d'autres méthodes de gestion automatique de la mémoire, mais ce n'est pas un langage où l'on est responsable de la mémoire.

Comment faire pour avoir un code plus long dans un map ? (Genre 2 lignes, ou assigner une variable externe lors de l'itération?).

Il est possible de passer aussi une fonction callback à map.

Après sinon je suis d'accord, ces "compile magic" sont déroutant et ça donne un côté très bidouille au langage, mais dans l'histoire des langages, c'est pas forcément les langages les mieux défini (ou les plus pures) qui ont eu les faveurs des programmeurs.

Dans le cas de V, les concurrents sont bien en place, je doute qu'il arrive un jour à devenir mainstream.

Quoiqu'il en soit, c'est une belle expérimentation, j'aime notamment l'idée de vsh. Poussé un peu plus loin, ça peut donner quelque chose de très séduisant.

Perso, je verrai bien une sorte de zx mais codé en V. J'avais commencé un truc, mais sans aller bien loin…

Ce n'est pas une killer feature, juste un choix de syntaxe issue de Go.

Disons que c'est plus cohérent, car l'exemple sans accolade ne fonctionne que si on a qu'une seule instruction.

Oui c'est cette approche minimaliste qui m'a plu dans V.
Après, la bibliothèque d'interface graphique n'est vraiment pas du tout au point.

J'ai essayé de faire un petit logiciel d'édition de sprite avec il y a quelques année et je m'étais bien cassé les dents.

Y a de bonnes idées, mais pas assez de réflexion sur la notion d'état de la vue, ce qui aujourd'hui est dommage quand on voit les apports de la programmation réactive.

Récemment j'ai découvert une mini lib Javascript qui permet de faire un peu la même chose que du React mais tellement plus simplement. J'adorerai voir ce genre de concept porté dans d'autres langages comme V par exemple.

c’est ainsi que la POO est présentée dans beaucoup trop de cas.

Oui, mais c'est aussi ainsi qu'elle est mise en pratique dans certains langages comme tu le dis bien dans ton billet.

Franchement, j'ai du défaire tout l'enseignement que j'ai eu à ce sujet, ça été douloureux, car j'y ai cru à toutes ces choses !

Je crois que le pire c'est les design pattern, j'ai essayé de m'y mettre ! J'y ai mis du cœur, mais dans bien des cas, je trouve que ça complexifie le code…

Le fait d'installer V nécessite une connexion internet et il a sa propre version de tcc.

Mais même s'il pointait sur une release de TCC officielle par exemple, je ne vois pas en quoi ça serait plus dangereux.

C'est une question de confiance, si tu fais confiance à ce projet pour télécharger du code sur son dépôt, alors tu as aussi confiance au code dont il dépend.

A noté que V ne nécessite pas de droits super utilisateur pour s'installer.

C'est à la personne qui installe de prendre la responsabilité de réaliser le lien symbolique.

C'est sûr, c'est un choix contestable. Perso, ça m'a choqué au début, mais finalement j'aime bien, c'est très compact et comme c'est des variables qu'on nomme souvent de la même manière, ça force une consistance dans le code.

qui empêche (du moins, je l'espère) l'utilisation de ces noms partout ailleurs

Non on peut les utiliser ailleurs.

fn get_ten_or_none(val int) !int {
    if val == 10 {
        return 10
    }
    return error('${val} not found')
}

fn main() {
    err := "yooo"
    if val := get_ten_or_none(10) {
        println('val : ${val} ${err}')
    } else {
        println('${err}')
    }
}

Ce qui me fait dire que la redéfinition de variable est finalement possible dans ce cas là…

Oui c'est possible et ça a été tenté, il semble exister un backend Go (en tout cas il y a un canal discord sur le discord officiel), mais je ne crois pas que ce soit allé bien loin.

De manière générale, je trouve que V est pour l'instant tellement lié au C (certains attributs sont directement liés à C) que je ne pense pas qu'un autre backend viable verra le jour d'ici peu.

Ou alors, il faudra revoir certains éléments du langage.

Oui une variable immuable c'est pas très logique, mais c'est pour les différenciées des constantes comme ça a été dit.

Pour le cas du for, c'est un cas particulier où le compilateur ne nécessite pas le mot clé mut (voir le guide).

Si je comprends, le langage ne contient pas de Null

Oui c'est l'idée, après je ne suis pas allé dans le détail, mais comme V permet de travailler avec des bibliothèques C sans couche d'interopérabilité, la notion de nil est présente dans le langage, mais a utilisé avec précaution.

Il est aussi possible de déclarer des champs de structure avec comme  soit un pointeur null…

J'ai un peu du mal à comprendre pourquoi un des cas doit être marqué unsafe et l'autre non.

Personnellement, je n'aime vraiment pas cette notion de unsafe dans V, tout comme je ne l'apprécie pas dans Rust. Je préfère de loin l'approche de Zig sur ce point.

Comme je le dis dans la dépêche, V cherche à faire un grand écart entre facilité d'utilisation, typage fort, rapidité et lien direct avec le C. Forcément, certains compromis doivent être fait, la notion de unsafe en est un.

et passe par un type ['a] Optionnal

Oui, c'est peut-être mieux détaillé dans cette partie du guide (voir l'exemple à la fin).

Donc pas de pattern matching pour gérer les Optional mais soit via or, soit via un if/else comme décrit dans cette doc.

Exemple :

fn get_ten_or_none(val int) ?int {
    if val == 10 {
        return 10
    }
    return none
}

fn main() {
    if val := get_ten_or_none(9) {
        println('val : ${val}')
    } else {
        println('no value')
    }

    val2 := get_ten_or_none(10) or { 5 }
    println('val2 : ${val2}')
}

J'ai vérifié et en fait je me suis trompé ou c'est que ça a changé depuis que j'ai commencé la rédaction de la dépêche (il y a plus de 2 ans !).

En fait, une version transpilée du compilateur V est compilée avec gcc par défaut (voir le Makefile).

Par contre, tcc est bien utilisé pour compiler les binaire une fois que le compilateur V à transformé le code V en C.

Et il semble bien téléchargé par make (si on en croit la doc), je ne trouve juste pas où se fait ce téléchargement.

En quoi est-ce si mal ?

On a aussi réussi à faire "revivre" de vieux portables donnés par l'école de notre village grâce à antixlinux.

Par contre, ils ont 1Go de ram, mais 512 ça devrait passer.
Bon après, faut pas imaginer faire du web avec :).

Mais ne serait-il pas préférable de produire du texte puis ensuite de générer un fichier audio avec l'outil ad'hoc (de ce que j'ai lire - sans l'avoir essayé moi-même - ça fonctionne très bien) ?

Tu perdrai tout l'intérêt du podcast. Ce que j'aime avec ce genre de contenu c'est aussi le fait d'entendre les gens parler, avoir leur intonation, parfois y a aussi des bruitages, de la musique. Bref, c'est une œuvre à part entière.

Après, c'est possible de faire une retranscription, mais c'est souvent fastidieux, ou alors peut-être que de nouveaux outils permettent de le faire automatiquement, je ne sais pas.
Souvent les podcasts sont accompagnés de commentaires, de notes qui renvoient vers les éléments cités et ça fonctionne bien je trouve.

Déjà merci beaucoup pour cette superbe interview.

Je ne connaissais pas Jean-Marc Manach et ça fait vraiment plaisir de voir un journaliste d'investigation aussi compétent et, surtout, qui sait se remettre en question et dire qu'il s'est trompé.

J'avoue de pas m'être trop intéressé à la problématique de la surveillance de masse, j'avais juste lu quelques articles, vu le film d'Oliver Stone et écouté des interviews de Snowden. Et comme dis Jean-Marc Manach, j'avais assez de biais cognitifs sur ces sujets pour que ce que je lise me conforme dans le fait qu'il y avait une surveillance de masse de la part de l'état.

C'est quelque part "rassurant" d'apprendre que c'est sans doute plus complexe et moins facile que ça de faire de la surveillance de masse en Europe, mais pour le coup je trouve l'auteur peut-être un peu naïf dans certains de ses points de vue. Mais c'est peut-être moi qui n'ait pas assez de connaissances sur le sujet, donc je vous livre ici ma réflexion, si jamais quelqu'un de calé sur le sujet pouvait me répondre, ça serait top :).

Déjà, il parle très brièvement de la surveillance de masse des GAFAM qui, elle, est omniprésente et incontestable. Les GAFAM ont accès à nos mails (si on est chez eux), à tout notre historique de visionnage, navigation, ils connaissent même les mouvements de notre souris, notre position géographique etc.

Donc, pour le coup, eux ont une masse de données totalement folle et passent leur temps à catégoriser cela, afin de mieux nous connaître.
Je me souviens avoir réalisé très tôt (genre en 2007) qu'avec Facebook les personnes renseignaient elles-mêmes des informations que tous les services secret du monde rêveraient d'avoir sur leurs administrés.

Jean-Marc Manach semble avoir une sorte de confiance envers le discours officiel des autorités et des GAFAM, et c'est la où je pense qu'il y a naïveté.
Il dit que les GAFAM font preuve de "transparence" vis à vis des demandes de agences gouvernementales et de ce qu'elles leur transmettent ou non. Mais, qui nous dit qu'elles ne transmettent pas plus de données ? Qui nous dit qu'il n'y a pas d'accord secrets pour donner un accès aux bases de Facebook, Youtube, Gmail ou autre à la NSA ou autre ?
Rien. Juste la parole de ces entreprises et institutions qui ont plutôt pour habitude de mentir.
On sait maintenant qu'il y a des portes dérobés dans des produits Intel, AMD, Qualcomm, Cisco et autre, pourquoi les GAFAMs seraient différents ?

Quand bien même la NSA n'aurait pas un accès direct aux GAFAM, il est connu que ceux-ci vendent les données personnels des utilisateurs. La NSA pourrait donc tout simplement acheter ces données comme d'autres le font.

Alors ça ne serait plus de la surveillance de masse, mais ça permettrait beaucoup de choses.

Aussi, qui nous garantie que WhatsApp fait vraiment du chiffrement bout en bout sur ses communications ? Y a-t-il un moyen de s'assurer qu'ils ne font pas une sorte de "man in the middle" permanent ? Ou qu'ils n'enregistrent pas ce qu'on écrit dans l'app et l'envoi à leur serveur ? Ça serait techniquement possible et peu étonnant de leur part. Quand on sait que les téléphone portable et autres enceintes connectées nous écoutent en permanence…
Personnellement, je considère qu'un ordiphone est, dès l'achat, "compromis" par soit son constructeur (on sait que certains téléphone bas de gamme ont des keylogger installés), soit par le logiciel (iOs et Android envoient tous les deux plein de données personnelles), donc on peut même difficilement avoir confiance en l'utilisation de Signal (sauf peut-être sous LineageOS ?)

Finalement, est-ce que le fait que la surveillance soit "de masse" ou pas est important ? Si les autorités ont la possibilité de très facilement connaître, par exemple, toutes les personnes activistes (de près ou de loin) dans un domaine et ensuite d'avoir très facilement toutes les infos qu'ils veulent sur eux, alors le résultat sera le même non ?

Ce que j'ai compris de l'interview, c'est que visiblement, le "très facilement" serait à nuancer et qu'il faut passer par pas mal d'étapes de validation pour déclencher des procédures légales d'accès aux données. Permettez moi de douter de ces affirmations.

Déjà en 2006, dans mes cours de droits liés à l'informatique, j'apprenais que les procédures légales de mise sur écoute par les services de renseignements pouvaient être totalement court-circuitées quand il y avait la mention "suspicion de terrorisme" sur une personne.

Il n'y a plus qu'à déclarer que tel mouvement est "terroriste" alors pour faire sauter tous les verrous…