Bruno Michel a écrit 3285 commentaires

Aucune hésitation : casse-toi avec rupture conventionnelle.

Je n'en suis pas encore là. Pour le moment, j'espère que ma baisse de motivation n'est que passagère, j'en ai parlé à mon patron et on cherche des solutions pour améliorer ça. Mais si ce passage à vide devait se poursuivre, j'irais effectivement voir ailleurs.

Pour vraiment terminer, j'ai une question : après avoir posément fait le point ainsi, quels sont éléments qui te manquent aujourd'hui dans ce que tu fais ?

Autonomie : il y a des points améliorables, mais dans l'ensemble, j'en suis satisfait.

Maitrise : de ce côté là, ça pêche pas mal, ce que je fais me paraît trop facile, trop répétitif, avec des sujets qui ne m'intéressent pas trop. Ça pourrait changer avec de nouveaux projets mais ce n'est pas très clair quand ces projets pourraient commencer.

Sens : la vision long terme a du sens, mais il y a une certaine déconnexion entre cette vision long terme et le travail au jour le jour ; une partie de ce que je fais au quotidien n'est pas ou peu utilisé, ça le sera sûrement plus tard, mais ça limite quand même la motivation.

Lien avec la tribu : il y a eu des départs, je travaille de manière plus isolée, j'ai moins de contacts avec ma tribu.

En parlant de Iosevka, la version 3 vient de sortir : https://github.com/be5invis/Iosevka/releases/tag/v3.0.0. Si quelqu'un est motivé, ça pourrait faire une dépêche LinuxFr.org.

Sur le formulaire de candidature en ligne, la date limite est indiquée : le 12 juillet.

J'ai l'impression que vous ne parlez pas de la même chose. Pour toi, avoir une prod a l'air d'impliquer des SLA, et dans ce contexte, travailler en équipe est effectivement une obligation.

Mais, il existe d'autres contextes. Par exemple, flus est un service avec une seule personne derrière et ça reste parfaitement légal. Et si sa prod tombe le vendredi à 18h, je pense qu'il aura à cœur de la réparer rapidement, même s'il n'a aucune obligation.

L'URL https://mastodon.libre-entreprise.com/tags/MécénatCodeLutin ne passe pas dans la partie liens quand on essaye de prévisualiser une dépêche.

Et perso, c'est plus pour des fonctions/building block de concurrence que ça m'intéresse, ou un package math qui ne soit pas à appeler avec 20000 cast que j'y vois de l'intérêt.

Tout à fait, je parlais des boucles parce que c'est un exemple facile à expliquer, mais il y a d'autres endroits où les generics sont plus intéressants.

Je n'ai pas compris ce que tu cherches à démystifier. Le fait que Rust soit complexe ?

Rust est un langage complexe (tout comme C++). C'est une complexité qui n'est pas là juste pour faire jolie, on se doute bien. Elle est là pour avoir un maximum de performances et une bonne stabilité.

Mais, il n'y a pas que les deux extrêmes : des bidouilleurs qui font du Python et des développeurs super consciencieux qui font du Rust. Il y a un large spectre entre les deux, et on retrouve notamment Go dans cet entre-deux. Rust est bien plus complexe que Go, et je ne vois rien dans tes propos pour expliquer pourquoi Rust ne serait pas si complexe que ça pour des outils de type CLI, ou en quoi cette complexité apporte des choses.

Tu évoques la gestion de la concurrence, mais Rust est loin d'être exemplaire dans ce domaine. Il n'interdit pas les deadlocks par exemple, contrairement à Pony et a un fonctionnement de plus bas niveau que d'autres langages, ce qui permet d'avoir des performances optimales mais a plutôt tendance à augmenter les risques de mal gérer ça. Les goroutines et channels sont plus faciles à apprivoiser que les futures et async/await. Et je ne parle même pas d'Erlang qui a, pour le coup, bien plus d'arguments à faire valoir sur ce domaine.

A priori, clap prend ça aussi en charge, sous le nom de « subcommand ». Cf https://github.com/clap-rs/clap/blob/master/examples/20_subcommands.rs

Je n'ai pas été clair, je ne prétends pas que Rust soit mieux que les autres langages pour faire un outil CLI. En fait, si je devais choisir un langage pour faire un tel outil, je prendrais très probablement autre chose que Rust : Go, OCaml ou Crystal.

Je constate que les outils récents de type CLI que j'utilise sont quasiment tous écrits en Rust. Par récent, on va dire depuis 5 ans (ça correspond à peu près à la sortie de Rust 1.0). Les exemples que tu as donnés, httpie, vegeta et vtop, sont plus anciens et je ne les utilise pas (même si ça pourrait).

Je cherche une explication à cette observation. D'un côté, je comprends que Python, Ruby et Node.js soit mal adapté pour des outils de type CLI : ils ont un temps de chargement qui peut se ressentir en ligne de commande, notamment quand ils chargent pas mal de modules, et c'est plus compliqué à installer qu'un simple binaire à télécharger. Mais de l'autre, pourquoi Rust est privilégié par rapport à Go et d'autres langages comparables, ça m'échappe. Mon choix serait au contraire de préférer l'aspect pratique d'avoir un garbage collector, avoir des goroutines et channels, etc.

C'est possible. J'ai l'impression que cobra est un équivalent en Go de Clap qui n'a pas grand chose à lui envier, mais peut-être qu'il y a un écosystème et des ressources (articles, billets de blog) qui créent un contexte plus favorable en Rust.

OK, mes explications ne devaient pas être très claires. Je vais essayer de faire mieux.

Je considère qu'il y a deux groupes de langage pour faire un CLI : en gros, ceux qui peuvent faire un binaire rapide et facile à déployer, et ceux qui ont besoin de passer par un interpréteur qui va aller charger plusieurs modules, et va donc être à la fois plus compliqué à déployer et plus lent à charger. Et le premier groupe me paraît bien plus adapté pour des outils de type CLI.

Go et Rust font parti de ce premier groupe. Mais, à l'intérieur de ce groupe, je suis surpris par la place que prend Rust alors que, si c'était moi avait dû choisir, je serais plutôt parti sur un langage avec un garbage collector, comme Go ou OCaml. J'ai du mal à voir quel avantage Rust a par rapport à Go ou OCaml pour un outil de type CLI. Je vois bien l'intérêt de Rust dans d'autres contextes, mais pour un CLI, je suis vraiment perplexe.

Pourtant, j'observe que de plus en plus des outils récents de type CLI que j'utilise sont écrits en Rust, et j'imagine qu'il doit y avoir une raison derrière cela. Peut-être que c'est un effet de mode, peut-être qu'il y a une autre raison (un écosystème bien adapté ?), je ne saurais pas dire.

Absolument pas. Je considère que Rust est un bon langage pour des choses de bas niveau où avoir un runtime important est un gros handicap. Je pense par exemple à l'écriture d'extensions pour des langages de script. Mais pour écrire un outil en ligne de commande, je préférerais d'autres langages comme Go ou Crystal. J'ai choisi les outils de cet dépêche parce que je les ai utilisés, pas spécialement parce qu'ils sont écrits en Rust.

D'ailleurs, dans la première dépêche, j'écrivais :

Un fait remarquable est que les trois outils présentés sont écrits en Rust. Il faut croire que ce langage convient bien pour écrire des outils en ligne de commande. C’est un domaine où le temps d’exécution est important (quand on lance une commande, c’est appréciable que le retour soit instantané ou en tout cas très rapide). Les langages de script (JavaScript, Ruby, Python) ont un temps de lancement de leur machine virtuelle qui peut casser cette impression de vitesse, je comprends donc que les développeurs d’outils en ligne de commande puissent s’en éloigner. En revanche, il est plus surprenant de ne pas retrouver d’outils en Go, en D, en OCaml ou en Haskell. Peut‐être que les lecteurs de LinuxFr.org auront une explication à cela.

Je m'attendrais à l'inverse, d'autant que dans la doc, tu indiques qu'il y a une option "-r" qui met le répertoire racine en bas.

Je ne suis pas l'auteur de ses outils, je ne fais que les présenter ici. L'option -r permet d'avoir le répertoire racine en haut. Je me serais également attendu à l'ordre inverse par défaut.

Pour la représentation des barres, quelle est la signification des nuances de gris ?

Ça permet juste de voir quels sont les sous-répertoires qui sont dans un même répertoire.

Et serait-il possible, pour les barres, de faire que visuellement elles soient séparées les unes des autres ?

Je ne vois pas d'option existante pour ça, mais si tu crées une issue sur github, l'auteur saura sûrement mieux te répondre que moi.

Tu as testé watchexec sous Haiku ? A priori, il utilise le même mécanisme de polling comme fallback générique que fswatch.

Plus généralement, la portabilité pour ce genre d'outils est compliquée. Chaque OS a une API propre, avec un mode de fonctionnement légèrement différent du voisin, mais ses différences rendent vraiment compliqué d'avoir un outil générique.

Sous GNU/Linux, c'est inotify. On dit que l'on veut surveiller tout fichier ou répertoire et l'OS va nous envoyer des événements quand il y a des appels système qui concernent le fichier ou répertoire.

Sous macOS, c'est fsevents : par rapport à inotify, les événements pour un même fichier sont regroupés quand ils arrivent suffisamment proches. Par exemple, on peut recevoir un événement pour un fichier avec des flags « fichier créé », « fichier modifié » et « fichier déplacé » pour un fichier temporaire.

Sous Windows, ça s'appelle ReadDirectoryChangesW, et ça marche un peu comme inotify, mais en plus, il y a l'aspect recursif qui est pris en compte : quand on demande à surveiller un répertoire, on reçoit des événements quand un fichier dans un sous-sous-sous-répertoire est modifié (alors que pour inotify, il faut explicitement parcourir les sous-répertoires et mettre en place la surveillance de ces sous-répertoires). Par contre, dans les points négatifs, c'est plus compliqué de suivre les fichiers et répertoires déplacés.

Sous BSD, c'est kqueue. Je n'ai pas pratiqué, mais j'ai entendu dire que c'était plus efficace comme alternative pour epoll que comme alternative à inotify.

Pour Haiku et les autres, je ne saurais même pas dire ce qui est en place.

Par contre, sauf erreur, en Ruby ton exemple fait un cast que tu n'as pas vu : site.foo() donnerait une erreur runtime si tu passes un objet sans cette méthode.

En Ruby, ça lève bien une exception au runtime si tu passes un objet sans cette méthode. Mais ça ne fait pas pour autant un cast.

En Go quand on appelle une méthode sur une interface comme en Ruby quand on appelle une méthode, le runtime va regarder une table de méthodes virtuelles pour trouver le code à appeler (ou plusieurs tables s'il y a des question d'héritages).

Qu'est-ce que tu reproches à « mon point » ? Ça me paraît être tout à fait français. https://www.cnrtl.fr/definition/point/1 donne comme définition possible :

Partie d'une démonstration intellectuelle, élément d'un ensemble de propositions.

Si tu veux implémenter any ou filter en go, il y a en gros deux possibilités : passer par interface{} ou utiliser de la génération de code.

Pour la première approche, tu as des bibliothèques comme https://github.com/chrislusf/gleam, mais tu perds le typage statique et les casts rendent la lecture du code assez moche, je trouve.

Pour la seconde approche, https://github.com/elliotchance/pie est un exemple. Mais la génération de code a aussi ses mauvais côtés (par exemple, ça allonge le temps de compilation). Et dans le cas de pie, ça oblige à déclarer un type spécifique sur lequel attacher la génération de code, ce qui rend compliqué à utiliser avec des bibliothèques tierces.

Pour en revenir à la question initiale, on ne peut pas utiliser d'interface en Go pour un comportement identique entre objets car il n'y a pas de généricité, et même si le comportement est le même, les types sont différents et les types apparaissent dans la déclaration de l'interface.

Je vais prendre un exemple dans la base de code sur laquelle je travaille :

func containsReferencedBy(haystack []couchdb.DocReference, needle couchdb.DocReference) bool {
    for _, ref := range haystack {
        if ref.ID == needle.ID && ref.Type == needle.Type {
            return true
        }
    }
    return false
}

// RemoveReferencedBy removes one or several referenced_by to the file
func (f *FileDoc) RemoveReferencedBy(ri ...couchdb.DocReference) {
    // https://github.com/golang/go/wiki/SliceTricks#filtering-without-allocating
    referenced := f.ReferencedBy[:0]
    for _, ref := range f.ReferencedBy {
        if !containsReferencedBy(ri, ref) {
            referenced = append(referenced, ref)
        }
    }
    f.ReferencedBy = referenced
}

On a une structure FileDoc, dont un des champs contient une liste de ReferencedBy, et on veut retirer de cette liste un ou plusieurs éléments.

La même chose en Ruby, ça donne :

class FileDoc
  def removeReferencedBy(ri)
    self.referencedBy.reject! do |ref|
      ri.any? {|r| r.ID == ref.ID && r.Type == ref.Type }
    end
  end
end

Merci pour l'explication.

Learn you some Erlang a un petit passage sur le sujet :

Through the years, there were some attempts to build type systems on top of Erlang. One such attempt happened back in 1997, conducted by Simon Marlow, one of the lead developers of the Glasgow Haskell Compiler, and Philip Wadler, who worked on Haskell's design and has contributed to the theory behind monads (Read the paper on said type system). Joe Armstrong later commented on the paper:

One day Phil phoned me up and announced that a) Erlang needed a type system, b) he had written a small prototype of a type system and c) he had a one year’s sabbatical and was going to write a type system for Erlang and “were we interested?” Answer —“Yes.”

Phil Wadler and Simon Marlow worked on a type system for over a year and the results were published in [20]. The results of the project were somewhat disappointing. To start with, only a subset of the language was type-checkable, the major omission being the lack of process types and of type checking inter-process messages.

Tout à fait. Le typage dynamique d'Erlang n'était pas une volonté des créateurs du langage, mais juste le fait qu'un certain nombre de personnes se sont cassées les dents sur ce problème. Il y a deux aspects compliqués : le redémarrage à chaud et les communications inter-process. Pour le redémarrage à chaud, cela semble encore inatteignable aujourd'hui et le choix fait par Gleam est de ne pas prendre en charge le redémarrage à chaud. Pour les communications inter-process, j'ai cru comprendre qu'il n'y avait pas de solution toute prête mais que ça paraissait jouable de s'y attaquer. Pour Gleam, il y a quelques expérimentations autour de otp_process, otp_agent et otp_supervisor. Je suis curieux de voir ce que ça va donner.

Tu parles d'outillage, et c'est vrai que c'est un élément de plus en plus important pour qu'un langage de programmation réussisse.

Pour Go, j'en fais pas mal. J'apprécie l'outillage et la simplicité du langage. Mais je suis de plus en plus frustré par certaines limitations, et surtout le fait qu'il n'y ait toujours pas de solution en vue. Tu as parlé de généricité, c'est quelque chose dont je comprenais bien l'absence il y a quelques années pour laisser le temps à la core team d'y réfléchir et de trouver une solution qui colle au langage, mais ces dernières années, le langage n'évolue quasiment plus et on n'a toujours rien pour écrire des fonctions map ou filter, c'est très frustrant.

Pour la gestion des erreurs, les panic me dérangent assez peu. Par contre, je trouve très compliqué de bien gérer les erreurs remontées : on en sait jamais trop la liste des erreurs possible qu'une fonction peut remonter. Il y a des techniques pour enrober des erreurs et regrouper des erreurs de plusieurs traitements, ainsi que des paquets comme github.com/hashicorp/go-multierror, golang.org/pkg/errors et github.com/pkg/errors. Mais, dans la pratique, quand on utilise des bibliothèques externes, on se rend vite compte qu'il y a différentes stratégies pour exposer les erreurs et que les prendre correctement toutes en compte dans son application est un casse-tête.

Dans les autres points, il y a les pointeurs nils (plutôt que des optionals), l'absence de types somme, le manque d'un équivalent d'OTP pour ne pas avoir à constamment réinventer la roue avec les goroutines et channels (surtout que je vois régulièrement des gens utiliser incorrectement ces primitives lorsque je relis du code, signe que c'est loin d'être aussi simple que ce que les concepteurs du langage peuvent dire).

Pour Rust, j'ai l'impression que c'est un super langage pour faire des gros projets (un navigateur, une suite office, un système d'exploitation), mais c'est vraiment trop complexe et bas niveau pour mes besoins de développeurs d'applications principalement web. J'en vois pourtant passer de plus en plus : rien que dans les langages cités dans le journal, gleam et Scryer-Prolog sont codés en Rust. J'arrive généralement à lire le code, mais ça ne me donne pas envie d'en écrire.

J'ai également l'impression que le choix d'une courbe en S, avec une accélération et une décélération de même vitesse était un mauvais choix à posteriori. Sur le graphique, on voit que ça a grimpé très rapidement (exponentielle) mais que la descente est bien plus lente (linéaire ?).

Pour les outils pour valider du HTML5 :

• il y a le validateur officiel du W3C (en Java) : https://validator.github.io/validator/
• html5validator qui permet de mettre ça plus facilement en place sur de la CI
• et potentiellement, tidy qui fait du nettoyage, mais doit aussi pouvoir faire de la validation.