Guillaum a écrit 472 commentaires

C'est pas bête ça. Au moins un lien. C'est un langage de programmation considéré comme "fonctionnel, pure, paresseux" avec un système de type très expressif qui permet en théorie d'avoir du code plus robuste tout en s'amusant.

Après en dire plus sans faire une dépêche entière sur le langage c'est pas simple.

J'ai reçu un X1 il y a 2 mois. J'avais envie d'utiliser ce truc. Comme beaucoup, au début j'ai trouvé que cela manquait de précision, cela faisait des spirales, mais au bout de quelques temps, on s'y fait et on s'adapte et j'y ai pris beaucoup de plaisir.

Sauf que voila, la douleur est venue en même temps. J'ai mal aux index. C'est une douleur que je n'avais pas eu depuis 20 ans quand je jouais à Diablo II et que passer 6 heures d'affilé a cliquer frénétiquement sur la souris m'avait bien abîmé les index.

Bref, je suis retourné au bon vieux trackpad qui semble plus doux pour moi.

Merci.

Le domaine des numéros de téléphone étant assez réduit (en france c'est de l'ordre de 5 * 10^8), il me semble qu'"inverser" le hash se fait assez trivialement par bruteforce.

J'ai raté quelque chose ?

Une bonne solution pour avoir 0 à ce paramètre c'est de changer tous les mois les paramètres du formatage de code et de reformater toute la codebase.

Plus de perte de connaissance.

Hello,

Pour la dépéche GHC 8.8, on peut faire un tir groupé avec la sortie de GHC 8.10 et 9.0, qui ne devrait pas tarder.

J'aurais dû finir la rédaction de cette dépêche, mais je me suis vexé suite à une remarque dans l'espace de commentaire concernant la qualité de mon français. Puis cela a coulé en bas de ma todo liste et j'ai oublié.

J'admet que j'écris mal, cela me suis depuis des années et je n'ai pas trouvé de solution pour régler définitivement ce problème. Quand j'y pense, je passe un coup de LanguageTool https://languagetool.org/fr, mais j'ai tendance à le faire en phase finale de la conception d'un texte.

Je n'aurais pas dû me vexer, la remarque était justifiée, mais elle supposait que je ne faisais pas d'effort, ce que j'ai trouvé insultant. Le truc c'est que je me prend ces remarques dans les dents depuis de nombreuses années et c'est souvent associé à la supposition que je ne fais pas d'effort parce qu'en fait bien écrire ce serait facile.

De manière plus générale, c'est un peu le sentiment de burnout du développer (de logiciel libre) ou tu essayes de contribuer quelque chose en fonction de ton temps et de tes compétences et au lieu d'un message d'encouragement associée à une critique, on se prend une critique souvent froide qui juste casse l'envie.

Je ne jette pas la pierre à l'auteur de la critique, communiquer ce n'est pas facile, et il s'agit surement d'une personne comme moi, qui de son coté essaye de contribuer au maximum et qui se retrouve à relire des brouillons qui arrachent les yeux et qui aimerait plutôt consacrer son temps à améliorer la structure du texte plutôt que des détails aussi banals que des accords.

Bref, je me suis vexé, je n'aurais pas dû. Je vais finir cette dépêche.

je crois que Nix n'est pas un DSL mais un vrai langage turing-complet

Un DSL peut être un langage turing-complet, c'est juste un langage crée pour un besoin spécifique. Contrairement à un langage générique qui ne fait pas de supposition sur le besoin d'application.

Et c'est hyper flou (au moins autant que la difference entre POO et fonctionel, ou langage de script versus vrai programme). Les templates C++ sont un DSL (c'est fait pour faire de la manipulation de type) et sont pourtant considérés turing-complet (https://rtraba.files.wordpress.com/2015/05/cppturing.pdf). Est-ce que les C est un langage génerique, ou un DSL adapté à la programmation système bas niveau ? Est-ce que Haskell est un langage générique, ou un DSL adapté à la création de compilateur ?

Et parlons des EDSL, des DSL "embarqués" dans un langage. Quel est la différence entre un EDSL et une librairie avec une API bien pensée ?

Bref, pour moi c'est encore un de ces concept peu défini en informatique que tout le monde utilise sans que personne ne soit vraiment d'accord sur la définition.

Je ne sais pas pourquoi là tu parle de cascade d'opérations et en dessous tu parle d'un seul.

Je crois que cela fonctionne à base de comptage de référence. En gros, tu as un arbre qui représente ton filesystem à un instant T, et un autre arbre à un instant T', qui partage le plus possible avec le premier arbre. Chaque sous arbre partagé ayant un compteur de référence supérieur à 1.

Bref, supprimer une référence, c'est faire -1 sur le compteur. Si celui-ci est à 0, alors on "supprime" et cette opération peut être récursive et donc prendre du temps.

Tu remplace la suppression par des créations de liens ce qui a le même coût.

Oui, mais dans un cas tu supprimes + crée, alors que dans l'autre cas tu crée seulement (et tu supprimera plus tard).

Je pense que les coûts sont assez similaires. J'ai envie de Benchmark cela.

Avant de discuter je voulais juste repréciser un truc. Je suis rentré dans le débat parce que je vois pleins d'avantages à nix versus le snapshot avant upgrade. J'ai aussi fais des suppositions sur comment était fait ces snapshot. Je pensais que l'utilisateur faisait un snapshot avant toute intervention sur son système (i.e. installation de paquet, changement de config, …) et concevrait ses snapshot pendant une longue période, parce que c'est ce que j'aurais fais. J'ai aussi imaginé que l'utilisateur intégrait ces snapshot dans sa procédure de backup.

Bref, j'ai mal compris, donc pas mal des points de mon argumentation ne sont pas valable dans ce contexte. Je veux bien admettre que nous ne sommes pas d'accord sur la stratégie de mise à jour.

Maintenant, tu soulèves certains points sur btrfs qui m’intéressent fortement et que j'aimerais discuter.

En gros, je ne suis pas d'accord avec toi ;) Mais ma connaissance de btrfs est limité, donc si je dis une connerie, arrête moi immédiatement.

Je présume que tu parle de snapshot pre-zfs/hammerfs/btrfs. Avec la technique du CoW, c'est instantané et ça ne coûte que la place réellement nécessaire.

Non, je parlais bien de snapshot btrfs.

La place réellement nécessaire lors d'une mise à jour importante c'est généralement égale à tout ce que tu as changé pendant cette mise à jour. Ce qui peut être beaucoup et le CoW ne va pas faire grand chose ici à mon avis.

Si tu met à jour un paquet de la version X à la version Y, ta distribution va commencer par supprimer les fichiers du paquet, puis installer les nouveaux, ainsi:

• Le CoW ne va pas faire grand chose ici, car tu supprimes un fichier puis tu en met un nouveau (que tu sors généralement d'une archive que tu viens de décompresser). Il n'y a pas de copie dans ce processus et ce n'est pas une édition d'un fichier que le CoW pourrait traquer en ne changeant que les blocs différents.
• Quand bien même, il y a de grande chances que tous les blocs d'un fichier soient différents après la mise à jour.
• La de-duplication pourrait faire quelque chose ici. Je ne sais pas comment elle s'en sort quand le contenu d'un bloc est sensiblement le même, mais un peu décalé.

Donc je suis d'accord avec l'argument du snapshot instantané et qui ne prend que la place nécessaire, mais je pense que cette place nécessaire peut être très importante.

Supprimer un snapshot ne coûte rien. Ça ne ralenti pas ton build suivant, ça prend le même temps quelque soit la taille de ton fs ou des données contrairement à une suppression de 200Gio sur disque.

Ici je ne suis pas d'accord. Supprimer un snapshot va au moins lancer une cascade d'opération pour mettre à jour les meta données de ton file système. Toutes les données devenues orphelines après cette suppression vont devoir etre "collectée" et cela peut representer un gros travail.

La suppression des 200Gio par nix va faire sensiblement la même chose.

La grosse difference entre les deux? La suppression d'un snapshot se fera en un appel système et le reste c'est le file système qui fait. La suppression des 200 Gio risque de générer de nombreux appels pour chaque fichiers à supprimer.

Cependant, je vois un peu cela comme une analyse amortie. Dans le modèle snapshot + update, tu va supprimer et créer de nouveaux fichiers puis plus tard tu vas supprimer le snapshot. Dans le modèle "nix", tu vas seulement créer de nouveaux fichiers (donc pas d'appel système pour les suppressions) et plus tard, lors de la "purge", tu vas supprimer tes fichiers inutiles. Les deux sembles équivalents, mais pas au même instant.

(Je sais pas pourquoi tu parle de backup quand il est question de snapshot)

Je me sers de snapshot dans ma stratégie de backup du système, d'ou ma confusion.

Le stress dont je parle c'est que lors de ta mise à jour, tu vas "remplacer" plusieurs programmes. Généralement c'est plusieurs mega (voir giga) d'archives à récupérer et à décompresser.

Ton snapshot il va "stocker" la différence avant la mise à jour et après. Lors du mise à jour, il y a très peu de copy on write, parce qu'il y a beaucoup de choses qui changent. Donc tu as plusieurs giga de difference à stocker. La déduplication n'est pas non plus très performante car bien qu'il y ai des chances pour que les fichiers soient sensiblement les mêmes, il y aura plein de petites differences subtiles qui ne permettront pas un énorme partage. Si tu conserves plusieurs snapshot, c'est plusieurs fois plusieurs giga que tu as besoin de stocker. Ce n'est pas la fin du monde hein, mais cela prend vite de la place.

Et si tu fais des backups de cela, c'est la même chose, et tu payes en plus le temps de transfert vers le backup.

Après, si ta politique c'est de ne garder que deux snapshots locaux et qu'un nombre limité de snapshots dans ton backup, et de ne pas inclure le système dans le backup il n'y a pas de problème du tout.

Ton répertoire "home", contrairement au système, aura beaucoup plus tendance à évoluer "lentement". Généralement tu ne remplaces pas tout d'un coup, c'est bien plus incrémentale, moins "stressant" pour le système comparé à l'exemple précédant.

Maintenant j'admet (et j'ai admis) que je n'avais pas imaginé que mon interlocuteur faisait "peu" de snapshot. (En gros, il admet en faire un avant chaque grosse mise à jour, et en garder 2 ou 3, et ne pas faire de backup de son système, seulement son home). Bref, dans son cas, il n'y a pas trop de problème. On ne fait juste pas la même chose.

En effet, l'usage que tu as ne risque pas de beaucoup saturer le système avec des updates espacés et pas de "backup" du système.

J'imaginais (à tort) que tu réalisais un snapshot avant chaque interaction avec le système (changement de configuration, (de)-installation d'un paquet), ce qui arrive sans doute plus souvent et qui stresserait un peu plus le système de snapshot / backup.

En effet, erreur de compréhension de ma part ;)

Tu te fais des millions avec nix? Tu embauches? (Je gagne bien ma vie, en partie avec nix, mais pas "des millions" ;)

Meme si je vois ce que tu veux dire (mon /nix/store fait à l'heure actuelle 230 Giga Octets), je trouve que c'est un peu se moquer de nix pour rien, car c'est principalement du cache. Sur ces 230 Giga, j'en ai 11 qui représentent le système installé (avec applications et configuration.). Ça je ne peux pas le purger. J'en ai 15 qui représentent des projets, perso ou pro. Cela peut se purger, j'aurais à le télécharger de nouveau quand je m’intéresserais de nouveau à ce projet.

Le reste, c'est du cache. D'ancienne configuration du système, ou même de build. Je me sers de nix comme build système chez certains client, donc j'ai des gigas d'artifacts intermediaires de build (type fichier .o de compilation C++). Je peux tout purger maintenant et récupérer environ 200 Giga d'espace disque. Tant que mon disque n'est pas plein, je m'en fous un peu. Je pourrais aussi purger basé sur l’ancienneté, mais pareil, je n'en vois pas l’intérêt. Ce cache me servira peut-être ou peut-être pas dans le futur (e.g. bisect sur l’environnent d'un projet). Bref, tant qu'il ne m’embête pas, je le garde.

Mais mon argument dans ce discours c'est que quoi qu'il arrive, ces données ne vont pas dans mon système de snapshot ni de backup. Ces données n'ont aucune valeur à être sauvegardés. Alors qu'avec un outil de snapshot système, chaque mise à jour augmente la taille de ton snapshot de plusieurs gigas octets, avec très peu de partage. Si tu fais un snapshot avant chaque commande sur ton gestionnaire de paquet, je veux bien parier une bière que rapidement ton système de snapshot va te prendre un disque entier et que tu vas devoir accepter de supprimer des snapshots. Pareil pour les backups, si tu fais une mise à jour système, c'est autant qui vont finir dans ton backup.

Je n'ai aucun souci avec le fait que timeshift te convient, c'est parfait. Mais je suis plus embêté par le fait que tu dise implicitement que NixOS est moins simple et moins "courant". Autant pour le simple, c'est discutable. Autant pour le moins courant, je ne vois pas en quoi c'est un argument.

Pour le simple, je ne sais pas trop. Installer timeshift va sans doute te demander un peu de travail, tout du moins de configuration pour obtenir le snapshot qui correspond à tes besoins (afin de ne pas snapshoter de trucs inutiles qui prennent beaucoup de place, comme tes containers / images docker).

La première installation de NixOS n'est pas forcement trivial, mais ce n'est pas non plus une horreur, tu boot sur un live cd, tu partitionnes des disques et tu edit un fichier de configuration. Cela manque d'un installer graphique qui configure un système "gnome" ou "kde" de base. Ce n'est pas forcement pire qu'une ubuntu fraiche ou tu passes une heure dans les menus pour installer / configurer tes applications et services et c'est bien mieux que tout autre distribution "un peu hard core" ou tu dois faire de nombreuses étapes pour réaliser l'installation.

Pour les "snapshot" à la mode NixOS, t'as une commande à connaitre, celle qui met à jour le système, et cela marche tout seul. Et tu y gagnes d'autres avantages liés à NixOS.

Mais au final, tu compares un outil de description de système et un outil de snapshot. Les deux traitent des problèmes différents et sont complémentaires.

L'outil de snapshot n'explique pas comment tu es arrivé à cette configuration là. L'outil de snapshot ne permet pas te partager ton installation entre plusieurs machines (avec des variantes). L'outil de snapshot ne te protège pas des dérives progressives de ta distribution qui mise à jour après mises à jour vas devenir différent d'un installation fraîche.

Par contre NixOS ne te protège pas de la perte de donnée accidentelle ou par erreur, et il faut faire des snapshot et des backups. Par contre NixOS peut te permettre de configurer ton outil de snapshot / backup.

Note que je ne backup / snapshot plus du tout mon système depuis que j'utilise NixOS, car je peux réinstaller mon système à l'identique à partir de ma configuration NixOS. Par contre, je continue à faire des snapshot et des backups de mes documents. Au final cela génère beaucoup moins d'activité sur mon système de backup. A titre d'information, mon système fait actuellement 27 Giga octet. C'est 27 Giga octet qui ne pollue pas mes backups chaque fois que je fais une mise à jour système qui remplace ceux-ci à neuf. Par contre, les fichiers importants de mon home font une dizaine de Giga octets, mais l'évolution est plus incrementale (i.e. je ne change pas tout d'un coup, donc on parle de quelques Mo de backup par jour).

L'outil de snapshot / backup ne te permet pas à ma connaissance de restaurer une configuration à l'identique sur une nouvelle machine en quelques minutes.

L'outil de snapshot / backup est plus lourd quand tu veux réaliser une bissection dans ton système. Cela ne m'a jamais servis sur une machine perso, mais sur un problème professionnel, on a cherché une régression de performance sur une de nos machine de production, il a suffit de "git bisect" la configuration nixos de la machine. En premier lieu on a pu le faire dans une VM et en second lieu, on aurait jamais pu le faire avec un outil de snapshot car on aurait pas gardé tous les snapshot sur la durée de vie de cette machine. Et puis, quand tu trouves le snapshot qui introduit la regression, après il faut chercher dedans ce qui est different. Avec NixOS, t'as directement le diff de ton fichier de configuration.

Tu peux aussi tester des configurations complètement différentes sans augmenter le poids de ton backup / snapshot. Par exemple, installer tout KDE, et finalement décider que tu veux tout GNOME, puis décider que finalement tu veux juste un système minimaliste. Autant ces changements apparaîtront dans le snapshot / backup de ta configuration, mais pas les gigabytes nécessaires au snapshot / backup des applications.

Bref, NixOS a d'autres avantages que juste faire des rollback d'install et même là, je trouve que NixOS est meilleure pour faire des rollback d'install que de nombreuses autre solutions.

Là où j'étais un peu railleur, c'est en te demandant la syntaxe choisie pour exprimer cela (de manière générale je me demandes quels genres de psychotropes prennent les responsables du standard C++, mais ils devraient réduire la dose, j'ai rarement vu une syntaxe aussi laide).

;)

Ça se tient. C++ étant orienté performance, avoir la commutativité permet de choisir un parcours de données plus efficace pour optimiser l'usage du cache du CPU, par exemple.

La commutativité et l'associativité sont des points super importants en calcul sur des gros volumes. Que ce soit en C++ ou en n'importe quoi.

• Associativité: tu peux séparer en morceaux indépendants
• Commutativité: l'ordre n'est pas important, ainsi tu peux traiter les morceaux quand ils arrivent et ne pas dépendre de la latence réseau par exemple.

Mais comment on prouve au type checker que l'opérateur + que l'on définit est bien commutatif ?
Dans les faits, elle ressemble à quoi la syntaxe pour ce genre de propriété ?

En coq, cela pourrait ressembler à ça:

Theorem plus_est_commutatif: forall a, b. a + b = b + a.
Proof. Admitted.

;) Mais je pense amicalement que tu me provoques un peu sachant que tu sais cela très bien.

Plus sérieusement,

On se contente de l'affirmer sans preuve ?

Oui. En Haskell, chaque "class" (qui est ce qui se rapproche le plus des concepts du C++) vient souvent avec des "lois" qu'un utilisateur peut s'attendre à voir pris en compte par tout type de la class. Par exemple map f (map g l) doit être la même chose que map (f.g) l. Appliquer g puis f sur un chaque élément de "la collection" l doit renvoyer la même chose qu'appliquer la composition de f et g (f.g) sur chaque élément de l.

Mais le langage ne le vérifie absolument pas. C'est laissé à la charge du développeur d'être cohérent et de s'assurer du respect des lois. Il existe des outils de tests qui peuvent tenter de prouver les propriétés, soit avec un solveur type z3, soit par génération de valeur aléatoires.

Mais alors, cela apporte quoi de plus ?

C'est juste un problème d'interface ou de contrat que tu passes avec ton développeur et la libraire. Si on reprend l'exemple de la commutativité, si en tant que développeur je sais que le type générique (e.g. template) que j'utilise est commutatif pour mon opération, alors je peux me permettre certaines choses. On peut me mentir, mais au moins j'aurais prévenu. Inversement, en demandant que le type en entrée soit commutatif, je préviens l'utilisateur et il ne peut pas rater la contrainte que je lui demande.

J'ai l'impression de devoir faire à la main un truc que le compilo pourrait me faire automatiquement

Qu'ai-je loupé?

Pas grand chose à vrai dire.

En premier lieu, les concepts vont te permettre de forcer "un peu plus" que ce que ta fonction demande vraiment. Par exemple si ta fonction ressemble à:

template T Foo(T a, T b){
return a + b;
}

Le compilateur sait que tu veux un operator+ sur T, mais c'est tout. Avec un concept tu pourra aussi demander à ce que + soit commutatif.

En second lieu, le compilateur sait des choses en observant ton code. De la même manière que tu sais des choses en observant un code. Mais il y a une partie ambigu qu'un lecteur (humain ou compilateur) ne pourra pas décider sans aide. Si j'appelle Foo en lui passant pour T une table qui ne possède pas d'opérateur +.

Est-ce le code de Foo qui est faux ? Est-ce que type T devrait avoir un opérateur + ou est-ce que c'est mon appel qui est faux et je voulais en fait additionner le prix des tables ? Pour chacun c'est une erreur différente avec une position différente.

En précisant grace à un concept ce que tu attend, tu vas pouvoir supprimer tout un ensemble d'erreur, réduisant ainsi le bruit.

Bref, c'est autant un moyen d'améliorer les erreurs que de rajouter (facilement) des contraintes additionnelles.

template <typename T>
void foo(T a)
{
   a.baz();

};

Si plus loin tu appelle foo(10), on va récuperer une erreur lors de a.baz() disant que le type int n'a pas de méthode baz. Les assomptions sur T sont implicites. Et le problème c'est que cela peut se propager très très loin. Si l'appel à baz se fait après plusieurs résolution de type / appels de fonctions qui travaillent sur T, tu vas récupérer une erreur dans un bout de code que tu ne maîtrise pas du tout et largement hors du contexte. Alors que on peut supposer que le code de foo est correct et que le problème est au niveau de a.baz().

En étant plus explicite sur le type de foo, l'erreur sera sans doute plus ciblée.

Je ne suis pas d'accord non plus avec lui pour plusieurs raisons. Mais aucune de ces raisons ne concerne (directement) la sécurité.

Je citerais juste sa conclusion:

I happen to disagree, and don’t think reproducibility makes a quality build, I think it adds unnecessary complexity.

Je ne suis tellement pas d'accord ici. En supposant que tu as un bon outil pour faire des build reproducibles (je pense ici à nix, il y a d'autres solutions), alors au contraire cela diminue la complexité, puisque que tout ce qui a été mis en place pour faire du reproducible permet normalement de s'affranchir de nombreuses autres questions que tu avais en terme de build. Fini les README de 10 écrans de long qui explique les étapes nécessaires (mais pas suffisantes, je n'ai jamais vu un README complets) pour obtenir ton build. Fini une bonne partie des "chez moi ça marche, pas chez toi ?". Fini les problèmes de bug amusant en production qui n'aurait pas du arriver parce que ce context était testé. Fini la matrice de test dans 200 configurations qui n'arriverons jamais mais qui "représentent" une vague idée de ce que tu va peut-être rencontrer.

A vrai dire je trouve même que mes builds sont moins complexes depuis qu'ils sont reproducibles.

Et le coté reproductible a un avantage en terme de sécurité, c'est que tu peux faire du post mortem dans le même contexte que celui de l'attaque (ou de l'accident / incident / bug critique qui as tué 400 personnes).

Résumer ce que l'on sait: 99% du boulot ! J'y ajouterais qu'il faut vraiment faire très attention à comment sait on ce que l'on sait. Je ne compte plus le nombre d'heures de debug passées sur une supposition fausse.

Cette belle chanson résume le problème de partir de croyance et non de faits.

https://www.youtube.com/watch?v=YA3XKIAGRuE

Well, j'ai raconté des conneries sur Haskell sur /r/haskell et j'ai été contacté par le CTO d'une boite de consulting qui était intéressé par mon profil et qui avait une mission sur Lyon qui pourrait m'aller.

J'ai fais un pari, d'un coté j'avais:

• Un job très bien payé, aussi en remote, pour une entreprise de cinéma (mon expertise initiale c'est la synthèse d'image, j'avais obtenu mon précédant job suite à mon PhD). Beaucoup de liberté, je travaillais sur un produit et j'étais en position d'expert technique et scientifique. Mais je commençais à m’embêter. J'avais envie de faire d'autres choses, de tirer la qualité vers le haut. Je m’intéressais beaucoup à nix / haskell et j'étais persuadé que ces outils pouvaient être utiles dans mon boulot.
• De l'autre, un boulot un peu moins bien payé, en remote. Devenir consultant (impliquant de la variété), l'opportunité de faire de la qualité, de bosser avec Haskell, de faire de la compilation, des méthodes formelles, de monter en compétence sur un domaine qui m’intéresse beaucoup…

J'ai fais le pari de changer de travail. Mais le temps que je me décide (un an), l'opportunité pour le client Lyonnais était close, et on m'a proposé un autre client qui semblait avoir les même avantages, et qui faisait des avions. Cela semblait super.

Au final, je ne fais pas rien de tout ce qui me faisais envie.

Et j'ai un contrat français.

Très peu de motivation. Je fais un travail qui ne me motive pas du tout, avec des technologies qui ne me motivent pas. Avec zéro difficulté, si ce n'est la motivation de se coller à faire une tache à la con.

Pourquoi je reste?

• La finalité du projet me plait. En gros, mon travail aide des gens à faire le leur (je fais du build system, de la CI, du tooling, …), et le leur c'est la création d'un avion. J'aime l'aéronautique. J'aime que les autres travaillent dans de bonne conditions.
• Le remote. Je travaille de Lyon, pour un client qui est à Palo Alto. Je fais ce que je veux de mon emploi du temps. J'ai des loisirs qui se font en journée, quand il fait beau, et que je ne peux pas faire le week-end si je veux garder mon épouse et mes enfants ;)
• Communiquer en anglais. Je suis mauvais en anglais, je le serais toujours. Mais comme je ne travaille exclusivement qu'en anglais depuis 2 ans, je commence à ne plus être ridicule. Au final, c'est un jeu qui m'amuse.
• La flemme de chercher, et le doute de changer. J'ai eux des propositions, mais rien de parfait sur le papier, que ce soit en terme de techno, de problématiques, …
• J'ai initialement changé de boulot parce que je voulais faire autre chose en terme de techno. En gros, je voulais faire du Haskell, du nix, faire du code de qualité, des choses reproductibles, des compilateurs, du formel, … J'ai rejoins une société de consulting qui fait ça, et mon client fait cela. Mais comme je ne suis pas initialement compétant dans ce domaine, on m'a demandé de faire du build system. J'ai espoir qu'un jour on me confie un bout de projet dans ces domaines.

C'est mes raisons. Mais plus le temps passe plus je commence à en avoir marre de faire des choses qui ne m'amuse pas. Et mes avantages d'organisation sont morts depuis le covid, puisque je ne peux pas pratiquer mes activité tant que la situation sanitaire n'est pas réglée (je vais déprimer un max dans les mois à venir moi ;)

Mais bref, en gros, je fais un avion et je travail comme je veux (sur des trucs qui ne m'amusent pas). Voila ma motivation. Pour répondre à tes trois points:

• autonomie: totale. Je gère mon temps comme je veux. C'est super.
• maîtrise: je m'ennui. Une horreur. Je n'ai presque rien appris en 2 ans, si ce n'est comment taper très fort sur les outils à la con que j'utilise.
• sens: 50/50 ici. Je fais des technos que je ne considère pas bonne pour le problème en question, mais j'ai un impact énorme sur un projet qui me tient à cœur. Mais le projet a beau me tenir à cœur, cela reste un projet qui n'a pas de sens dans le monde actuel à mes yeux, donc c'est complexe.
• la tribu: je suis le gars le moins diplômé et le plus idiot de ma société de consulting. Ils sont tous beaux, intelligent, super compétant, productifs et sympathiques. C'est super de travailler avec eux. Pareil chez le client. Mais je suis en remote, alors "le lien avec la tribu", il est cassé.

Je dirais même plus que le plus gros progrès à faire en terme de frappe, avant de penser à changer de layout, c'est apprendre à frapper à l'aveugle.

Je suis passé au dvorak quand j’étais en terminale (~2004) parce que le fait de changer vers un layout totalement différent aide à apprendre à taper à l'aveugle ;)

Les tags c'est ni plus ni moins que des types phantom, qui sont tout aussi disponible en OCaml. Cela commence à devenir amusant quand tu fais des opérations non triviales entre les tags, voir que tu transformes des valeurs connue seulement à l’exécution en type. Je crois que ce qui t'as posé problème en OCaml c'est le manque de surcharge d’opérateur (si je ne me trompe pas), mais si tu as de la surcharge, cela peut être très confortable à utiliser.

https://www.opengroup.org/face

Merci, je vais jeter un œil, je ne connaissais pas, pourtant les trucs qui volent c'est un peu mon truc ;)

Tous les cas que tu cites ne sont pas des cas d'erreurs fréquents ou des difficultés particulières à détecter rapidement au runtime.

Pas fréquent, cela dépend. Pas difficile à détecter au runtime, c'est bien possible. C'est un compromis et je ne prétend pas avoir la réponse. En plus c'est un exercice difficile puisque il n'est pas aisé de quantifier l'impact dans un projet de ces méthodes. Si tu as un bug, tu peux juste imaginer ce que cela t'aurait coûté de ne pas l'avoir, mais si tu n'as pas de bug, c'est dur de savoir combien tu as économisé grâce à ta solution actuelle.

Si vous pouviez trouver un truc pour les API REST,

En haskell il y a https://www.servant.dev/, tu définis un type assez trapu et à partir de ce moment là tu as énormément de choses qui se font automatiquement, et tu ne peux pas compiler ton API REST tant qu'elle n'est pas implémentée correctement (pour une certaine définition de correctement). Qu'est ce que tu aimerais ?

ou encore, la gestion de la compatibilité ascendante lors d'un changement de version ("est-ce que le futur $ go get ./.. va tout péter ou pas ?").

Alors ça c'est un super problème, mais je pense que c'est indépendant du problème de typeage décrit dans ce journal.