barmic 🦦 a écrit 5744 commentaires

AMHA le point le plus essentiel c'est pas une question d'init uniquement ou pas. C'est des approches différentes.

Quand tu conçois un système tu peux avoir 2 approches différentes (c'est une dichotomie il y en a d'autres) :

• la méthode sysv : tu est simple et basique et tu expose la complexité à tes utilisateurs
• la méthode systemd : tu prend pour toi la complexité, les utilisateurs ne l'ont pas

Tu retrouve ce découpage dans pleins de choses : pour le web en python les micro framework face à django par exemple. Les outils de builds à la maven face à make ou ant.

Ces dernière années on a tendance à décrire les simples comme non-opiniated et les autres comme opiniated. On parle aussi du principe de convention over configuration pour les second.

Comprendre cette différence c'est à mon avis important pour comprendre la démarche à adopter face à chacun d'eux.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le message initial de questionne pas l'utilité, il demande autre chose. Tu va voir le 5ème boulanger et tu lui dis qu'il aurait été judicieux d'ouvrir une pâtisserie.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si ce n'est que ça :)

perl -ne'while(/O/g){print chr(65+$-[0])}' input.carte

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Waow vous utilisez des tellement concis !

perl -ne'while(/O/g){print chr(97+$-[0])}' < input.carte

:p

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Du coup, dans ce cas, les performances apportées par le service de cache ne serviront à rien car un cache local ferra le boulot, non?

Quel cache ? Par défaut tu as un cache en lecture sur le système de fichier et tu peux avoir quelque chose au niveau de ton driver de base de données. Ce sont des caches pour les quels tu as très peu de contrôle (politique d'éviction par exemple, politique d'insertion,…). Imaginons un cas tu accède à une API qui est payante ou qui limite ton débit (elle te demande à ne pas lui envoyer plus de N requêtes par seconde), tu va trouver dommage de te contenter d'un cache local.

Je loupe surement quelques choses, car il "semble" (https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/) que les threads sont plus rapides à démarrer que les processus, et le temps de "context switch" est plus court pour les threads.

Tout à fait, si tu fait du calcul intensif. Et tu as même la possibilité de partager de la donnée entre tes threads sans sérialisation. Mais tu as pleins d'autres paramètres que ça à prendre en compte. Le plus classique c'est que si tu as un gc tu veux des processus les plus petit possibles. Au niveau du système d'exploitation, tu perds toute flexibilité de monitoring et d'administration. Si tu veux privilégier les réponses aux requêtes (qui ne sont pas forcément toute en lien avec ton cache), tu va peut être demander à ton OS de privilégier l'un sur l'autre. Ton process va aussi être une cible de choix pour l'OOM killer. De manière moins précise je n'ai toujours eu que du positif à découper ce genre de chose mais là je n'ai rien de plus à présenter que ça donne l'impression que la machine « respire mieux ».

Il est possible de le faire en PHP, voir https://www.php.net/manual/en/book.shmop.php

S'il est activé et que tu utilise fpm ou en module de ton serveur web.

souvent les caches c'est le premier truc que tu veux virer au démarrage d'une appli pour être dans un état connu,donc à priori, stable

Alors si tu es instable à cause de ton cache le problème c'est pas le cache :) Ce comportement vient surtout du fait qu'on veut mettre à jour le cache au démarrage on est pas sûr qu'il soit à jour et on préfère le détruire (c'est l'équivalent du shift+F5 sur ton navigateur). Si tu as la possibilité de savoir qu'il est à jour, il n'y a pas de raison de le détruire.

Ce "problème" (ou "faux problème"), […]

Et hop ! On file dans la rhétorique. C'est toi qui te demandais si on est toujours dans l'informatique ?

[…] tu l'as pour les bases de données sous le nom de "driver" JDBC/ODBC/etc… développés et fournis par les développeurs des bases de données.

Alors ODBC c'est du "système" et l'idée c'est d'implémenter sous forme d'une bibliothèque partagée et que les langages puisse juste s'interfacer à un driver ODBC sans avoir à réimplémenter le driver… Comme quoi c'est un problème qui n'existe tellement pas que des gens essaient de le résoudre.

Tu trouvera JDBC et DBI qui sont des API respectivement en java et en perl qui définissent un driver standard (en natif dans leur langage ou ODBC) et proposent une API dessus. C'est la même idée.

Bon toutes ses API sont liées à SQL quand tu es un NoSQL tu peut abandonner l'idée de ce type de partage. Il y a quelques tentatives, mais c'est pas tr_s développé et plutôt compliqué.

Maintenant, si on regarde plutôt que de juger. Prenons quelques base de données NoSQL :

• MongoDB : supporte 39 langages (officiel + communauté)
• Apache Cassandra : supporte 16 langages
• CouchDB : 23 langages
• redis : supporte 50 langages

C'est une corrélation et pas forcément une causalité, mais disons que si des développeurs disent « on fait ça pour simplifier, la vie des développeurs de drivers » et ils ont semble-t-il¹ plus de driver que les autres. C'est peut être un faux problème, hein ? Mais bon, il va falloir des arguments en plus pour me faire remettre en cause leur dire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais je peux me tromper…

D'après toi pourquoi ils ont appelé ça un fairphone ?

Ce sont les tenants du système ; et dans la mesure où ils ont un impératif : maximiser leurs revenus (via leurs volumes) et minimiser leurs coûts (via nos salaires), j'ai comme l'impression qu'il y a une incompatibilité quelque part…

Le « système » ? C'est quoi ? Ici la société qui vend le fairphone explique travailler pour que les ouvriers de productions soient mieux payé, limiter autant que possible les matériaux à problème et faire attention aux importations de terres rares entre autre. Ils ne disent clairement pas que c'est parfait, mais qu'ils travaillent en ce sens.

Il est possible de remettre en cause ce qu'ils font. Mais on est dans une démarche bien plus concrète que « le système il est pas bien, on peut rien faire ».

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pardon je ne suis pas allé jusqu'à lire vraiment le fameux main.rs. Je ne lis pas encore couramment le rust. C'est la référence à dwm qui m'a trompée.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je me suis même dit : « Encore un journal bookmark ! ».

Pétard ça va vite ! Il a codé un truc il le partage avec nous, c'est loin d'être un journal bookmark (quelque soit sa forme).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça c'est parce que tu fais un procès d'intention. Tu peux penser qu'une 2ème distribution Linux c'est utile, mais qu'une 2563254ème ne l'est peut être pas autant.

1. Qui est juge de l'utilité ?
2. Pourquoi ça devrait être utile ?

Ou dis autrement pourquoi est-ce que le fait que ça ne soit pas utile à une ou plusieurs personnes ici devrait remettre en cause ce projet/code/partage ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Bravo ! Et merci de partager :)

DWM au niveau de la configuration (fondée sur du code).

J'ai utilisé un temps tout ce que fais suckless, mais au final je suis pas super fan de cette manière là. Je préfère xmonad.

• dwm on fork le code pour le modifier et se faire notre propre build.
• xmonad est une bibliothèque haskel, tu récupère la bibliothèque et tu écris la fonction main qui lance cette bibliothèque.

Cette seconde solution est bien plus simple à appréhender. Elle est aussi plus élégante je trouve. Enfin on est moins sujet, comme c'est le cas avec dwm à avoir des séries de patch à appliquer potentiellement dans un ordre donné et qui sont très sensibles aux mises à jour du code upstream.

Voila c'était juste au cas où ça te donne l'idée.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ah ! Ah ! Ça fais des années que j'utilise xournal, mais jamais que pour éditer des PDF. Je ne savais qu'il pouvait servir à autre chose :) Bon je n'ai pas besoin des autres usages, mais c'est quand même bon à savoir .

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Contrairement à ce que tu penses, cela m’intéresse de comprendre pourquoi on a arrive à des architectures logicielles compliquées pour des résultats catastrophiques sans que personne ne se remette en question (d'où les quelques exemples cités).

Je vais réessayer alors. J'ai du mal à construire un fil conducteur donc ça va être une série de remarques et il faudra probablement que tu veuille faire l'effort de comprendre pour… comprendre.

Pour une utilisation comme cache (c'est la première idée qui vient en tête). Un cache ça sert à stocker le résultat d'un traitement pour y accéder plus rapidement. Tant que le traitement en question est significativement plus long que la lecture depuis cette base de données, ça peut rester pertinent.

Le fait de séparer les processus qui servent au cache plutôt que de l'intégrer dans ton logiciel peut avoir pleins d'intérêts différents :

• d'une part un système d'exploitation préfère avoir 2 processus de 4Gio qu'un seul de 8, mais là tu n'es même pas symétrique tu peut avoir une partie applicative peut être bien plus petite en déléguant tout le stockage de grande quantité de données en mémoire à quelque chose d'autre. Si tu sais que tu n'en manipule qu'une quantité faible, ça peut être intéressant ;
• tu peux ne pas avoir le choix, comme je le disais plus haut avec PHP et du cgi tu ne peux pas faire autrement (de même avec du serverless) ;
• tu peux vouloir que ton cache survive à un redémarrage de ton applicatif ;
• tu peux vouloir que ton applicatif scale horizontalement et ne pas en avoir besoin pour ton cache. Tu peux lancer autant de fois ton appli la faire pointer vers ton serveur de cache et ton cache n'est pas limité à chaque instance. Bien sûr avec une solution comme robert pour le moment ça t'empêche de le faire coté cache, mais il n'y en a pas forcément besoin. Tu pourrais aussi imaginer faire interagir tes applicatifs pour qu'ils fassent les échangent eux-même :
  • ça complexifie l'auto scaling (il faut du service discovery, du graceful shutdown, etc)
  • cette complexité peut être très dommageable, la vitesse de démarrage et d'arrêt peut être un enjeu important pour limiter les coûts de ton infra si tu es dans cloud par exemple
  • ça augmente la complexité de ton application, elle fait pleins de choses différentes ça multiplie les droits que tu va devoir lui donner et rends son observation plus compliquée

Il y a probablement pleins d'autres points.

Pour ce qui est du protocole texte, je ne peux que paraphraser ce que dis redis. Ça simplifie le développement des bibliothèques et simplifier la vie des développeurs pour ne pas avoir toi même à créer un client pour chaque langage de l'univers c'est plutôt sympa. Ça simplifie aussi le debug parce que tu peux facilement voir sur le réseau ce qui se passe sans avoir à implémenter sur wireshark et éventuellement d'autre logiciel, le décodage de ton protocole.

Voila c'est quelques points lancés comme ça, juste pour avoir quelques critères qui peuvent remplacer ta dichotomie cluster de cache/dictionnaire dans ton langage.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais si ton appli est capable d'avoir des infos, pourquoi elle freeze ? Quand l'appli freeze, c'est qu'elle est en attente sans en savoir plus. Que veux-tu dire à l'utilisateur qui permettra à lui de changer la situation, quand tu es en attente d'une machine à l'autre bout du réseau ?

Ok en fait on ne s'est pas compris.

Le freeze c'est le fait qu'une interface graphique ne réponde plus.

Tu peux très bien organiser ton code pour que le fil d'exécution qui gère l'interface ne fasse que la gestion de l'UI et interactions avec le gros du logiciel. C'est l'architecture qui était généralisée sur BeOS (d'où le commentaire plus bas). C'est ça qui est reproché.

Mon point de vue c'est de vous demander de pousser la réflexion plus loin que la première étape qui est le feedback visuel, en se demandant ce que ça va changer à l'issue de la tâche qu'est en train d'effectuer l'utilisateur.

Déjà avoir systématiquement ce retour ce serait énorme. C'est ce feedback qui permet à l'utilisateur de mieux comprendre ce qui se passe et pourquoi des choses prennent du temps. Et ça lui permet de faire des choix plus éclairé que ce que son imagination va donner.

Ensuite la logique voudrait que tu ne puisse pas modifier un traitement en cours, uniquement l'annuler. Mais c'est un pas bien plus compliqué à mettre en place.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Bref, l'idée n'est pas de donner des leçons ou d'arriver avec mes gros sabots

alors que plus haut :

N'as tu pas une petite liste dans un coin des technos/logiciels bien mauvais que tout le monde utilise?
Démontrant ainsi que la popularité n'a rien à voir avec la qualité?

Tu n'a pas l'air d'être particulièrement intéressé parce que je t'explique jugeant que je prends pour exemple de mauvais logiciels sous seul prétexte qu'ils ne suivent pas tes préceptes.

Les choses ne te plaisent pas tant pis pour toi. Ton objectif semble ne pas être d'échanger, mais de te plaindre en multipliant simplement les exemples sans liens (autre que d'être des logiciels) et d'en tirer des conclusions aussi intéressantes que « tout le monde il est méchant, ils ne comprennent pas ce que je leur explique ». Je ne serais pas ton client plus longtemps. Passe un bon week-end.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est écrit donc c'est vrai?

J'ai pris Redis car c'est LA référence¹ du domaine et qu'il est massivement utilisé. Ils ont considéré que le gain en performance ne valait pas les autres avantages. Il existe des alternatives à redis, qui font des choix différents. Mais force est de constater qu'il reste une place pour redis, malgré l'API ASCII et pendant longtemps l'absence de cluster.

Personne n'est donc plus "au courant" que par exemple le nombre 2 milliards, transféré en ascii va prendre 10 octets, et en binaire seulement 4 octets?
Et que dire du temps CPU pour convertir l'ascii ?

Ce que disent les mainteneur de redis, c'est que ce n'est pas la seule chose qu'il faut regarder et qu'ils sont prêt à payer ce coût face à d'autres avantages. On parle d'un projet qui fonctionne et qui fonctionne très bien depuis longtemps. Il a des challengers qui ont des protocoles binaires, mais ça n'a semble t'il pas suffit à le détrôner. Je veux bien te proposer d'aller en discuter avec eux, mais si tu viens avec tes gros sabots comme ici je doute que tu sois bien accueilli…

Je ne vois pas l’intérêt de Redis pour un seul serveur, une librairie faisant le même boulot, ne suffirait-elle pas?

Intéresse toi au modèle d'exécution de PHP ou des (fast)CGI par exemple. Quand tu fais spawn un process par requête (ou que tu fais un pool de thread) ça va coincer. Si tu n'a pas ou si tu ne veux pas manipuler des threads toi-même comme avec node ça peut être intéressant.

A moins que l'on considère que l'appel d'une fonction est "comparable" à l'appel d'un service réseau.

Ce n'est pas l'appel d'une fonction, c'est un IPC que tu dois utiliser donc tu a ton coût de sérialisation quoi qu'il arrive (sauf éventuellement si tu utilise des threads et pas de process, mais tu as toute la protection à fin d'être thread-safe à gérer. Plus un autre pour nettoyer tes données. Les caches sous forme de bibliothèques ça existe, mais c'est des contextes différents.

Bref, ce que fais Redis en réseau peut très bien être fait par une l'utilisation d'une librairie pour les besoins que tu précises (optimisation pour les gros volumes, fragmentation, …) sans requérir un service.

Ça dépend du contexte. Mon po objectif c'est de te montrer qu'il y a pleins de contexte différents qui amènent à des solutions différentes et donc des solutions différentes. L'exemple de redis n'est là que parce que c'est un exemple réel qui coche toutes tes cases tout en ayant sa place et ses utilisateurs.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et donc, le REPL. Y'a des langages évolués qui émergent, mais aucun n'a un si bon REPL, voir aucun REPL du tout. Le temps écriture -> test -> validation -> je recommence est bien plus rapide et fun avec un REPL.

C'est joueur de dire ça quand il y a ipython en face :)

J'ai dans ma todo list à aller voir du coté de clojure. « Bouh c'est pas bien c'est sur la jvm ! » Moi je m'en sert au quotidien et j'en suis bien content de cette jvm. Clojure a d'intéressant pour moi qu'il a une alternative que je trouve très cool aux fluent API : les transducers. On garde la composabilité, mais on inverse l'application. Le traitement composite est une élément de première classe qui peut être nommé et même composé pour enfin s'appliquer sur de la donnée. Ça évite les compositions fluent qui deviennent lourdingue à cause de leur taille

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Désolé de la digression, mais t'es tombé pile sur un truc qui m'énerve.

Pourquoi poster un commentaire énervé à 1h du mat' ? (si tu es dans la tz de Paris)

Alors pour le partage réseau, déjà, est-ce que c'est un partage abstrait par le VFS ou alors une API spécifique à Nautilus (ou une lib qu'il utilise spécifiquement) qui lui permet de savoir que c'est un partage réseau ? Dans le premier cas, ça obligerait à complexifier le cas pour tous les accès même locaux, et ça causerait sûrement plein de problèmes de consommation et complexification supplémentaire pour uniquement ce problème particulier. Dans le second, il y a effectivement peut-être des choses à faire, mais il faut essayer de comprendre le besoin : le réseau ajoute intrinsèquement des latences, alors combien de temps il faut attendre avant de dire qu'il est « en carafe » ? Est-ce une erreur transitoire ou permanante (et on démonde le partage) ?

Dans le premier cas ça permet aussi de gérer les disques qui ont des erreurs (physique, mal branchés, autre). C'est une I/O ça peut planter tenter de ne gérer que les cas que tu imagine c'est généralement en oublier un énorme paquet. Et en terme de complexité ça n'est pas forcément si incroyable que ça. Du moins ça peut l'être si ton design a était prévu pour.

Certes, pouvoir fermer la fenêtre devrait être une option accessible, mais si je peux me permettre le tirage de cheveu, la question de l'informatique a toujours été de cacher les modalités, et là donc la modalité du « je suis dans un dossier du partage réseau », que tu la recrées en fermant la fenêtre et en allant en rouvrir une autre pour aller au même endroit et te reprendre la même erreur… quel intérêt ? « Attendre que ça revienne » peut être une solution également valable ! Ça me fait penser à ceux qui rechargent leurs pages pour régler leur problèmes : TCP a été inventé (dans les années 70 !) pour réessayer à votre place, sans que vous ayez besoin de le faire vous-même ! (vous n'êtes pas des machines ! Bien que les devs prennent souvent leurs utilisateurs pour des automates débiles)

Si tu freeze ton application, flinguer ton application est la seule option qui reste à ton utilisateur. Si non tu pourrais lui expliquer ce que tu es entrain de faire, ce qui plante, lui donner des billes pour savoir si c'est transitoire ou non…

Corrigeons d'abord ces conneries afin d'avoir un réseau plus fiable, après on aura moins de problème avec les GUI.

Donc au lieu de faire en sorte que les UI restent réactives donnent des info à leur utilisateurs, il faut qu'ils investiguent eux-même d'où vient ton freeze, qu'ils regardent toutes les I/O de leur machine et potentiellement de leur réseau et corrigent le problème. Tant pis si tu es sur un wifi publique ou si ta connexion est mauvaise (réseau mobile hors jolies 4 ou 5G ou alors ligne physique mais en défaut sur le moment) ?

Les développeurs d'intellij sont entrain de bosser là dessus comme ils l'ont dis au début de l'année (IntelliJ Platform Roadmap for 2020).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

De ce que je comprend maintenant ton système n'a d'utilité que si il est au centre d'une architecture multi-serveurs (sinon pourquoi ne pas avoir une hashmap/un graphe directement dans l'appli, plus simple et plus rapide). Donc réservé aux gros déploiements.

Redis est massivement utilisé pour un seul serveur (au pif il est préconisé pour l'installation de nextcloud) et il utilise un protocole texte (la doc. Vouloir donner beaucoup de contraintes à ce logiciel pour mettre en défaut ses choix ce n'est pas très aimable je trouve.

sinon pourquoi ne pas avoir une hashmap/un graphe directement dans l'appli, plus simple et plus rapide

Les map de ton langage ne sont pas forcément très fortes pour gérer de gros volumes dans le temps (avec des stratégies pour limiter la fragmentation par exemple), elle ne fournie pas d'expiration, tu peut vouloir accéder à ses données dans ton serveur et dans un p'tit utilitaire installé sur ton serveur par exemple,…

Quand on a ce genre d'architecture, on cherche l'optimum, car perdre 5% de performances c'est payé quelques serveurs de plus pour "rien".

Ce n'est probablement pas le usecase de robert comme ce n'est que difficilement le usecase de redis (le mode cluster - pas master/slave - n'est arrivé que récemment et sans ça ta montée en charge est fortement contrainte).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Donc généralement tu va utiliser un type prédéfini qui possède potentiellement des trucs dont tu n'a pas besoin.

Je vois pas trop à quoi tu fais référence ici.

Si tu prends mon exemple et que historiquement tu fais les choses ainsi :

1. Tu crée LinuxFr
2. Tu crée hello()
3. Tu crée AppleFr

Le paramètre que tu aura défini pour hello() sera probablement plutôt LinuxFr que l'interface minimal dont tu as besoin car c'est fastidieux de n'exprimer son typage que par les préconditions minimales aux quelles tu dépend. C'est la force des langages dynamiques, c'est totalement gratuit. Et c'est l'une des forces des langages dynamiques.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Merci d'avoir fais la recherche :) Je vais tout de même essayer de varier un peu plus mon vocabulaire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est un argument qui se défend, plutôt du côté ressenti humain subjectif (frustration) que technique.

J'ai parlé de frustration, mais aussi d'homogénéité par exemple. Ce qui est moins subjectif.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il n'y a pas de cast explicite, mais dans l'abstrait (peu importe l'implémentation) on peut voir ça comme un cast d'un type implicite qui contiendrait tous les objets (d'un point de vue statique on ne sait en général rien sur le type de l'objet contenu dans une variable, donc interface{}), vers le sous-type des objets qui ont une méthode foo (implicitement défini en Ruby) afin d'appliquer la méthode, avec exception runtime si ce cast échoue (le contenu de la variable, c'est-à-dire l'objet caché derrière interface{}, n'est pas d'un type compatible).

Tu m'a faits douter, mais non le code équivalent en go de ce que j'ai posté plus haut :

package main

import (
    "fmt"
)

type LinuxFr struct {
}

func (c *LinuxFr) foo() string {
  return "linux"
}

func (c *LinuxFr) bar() string {
  return "bar"
}

type AppleFr struct {
}

func (c *AppleFr) foo() string {
  return "ios"
}

func hello(a interface{}) string {
  return a.foo()
}

func main() {
    fmt.Println(hello(LinuxFr{}))
    fmt.Println(hello(AppleFr{}))
}

Ça ne compile pas.

./prog.go:26:11: a.foo undefined (type interface {} is interface with no methods)

Go demande à ce que tu indique le type. Tu dois donc définir une interface avec tout ce dont tu as besoin de dans. C'est tout à fait possible et facile dans mon exemple, mais bien plus complexe dans des cas réels. Donc généralement tu va utiliser un type prédéfini qui possède potentiellement des trucs dont tu n'a pas besoin.

C'est loin d'être identique dans la logique comme dans le comportement.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Information que tu n'as pas statiquement à la base dans un langage à typage dynamique, donc impossible à perdre.

C'est mon point : il est bien plus frustrant de perdre quelque chose que l'on a que de ne pas l'avoir.

Dans les langages dynamiques il y a des casts aussi, ils sont juste implicites et partout, ce qui apporte plus d'ergonomie et de flexibilité (moins de contraintes comme tu dis), mais aussi justement moins d'info quand on se plante, voire des erreurs silencieuses (cast inattendu mais valide).

Et bien non. Si je prends ce code là :

class LinuxFr
    def foo()
        return "linux"
    end
    def bar()
        return "bar"
    end
end
class AppleFr
    def foo()
        return "MacOS"
    end
end

def MyFnc(site)
    puts site.foo()
end

MyFnc(LinuxFr.new)
MyFnc(AppleFr.new)

MyFnc() ne cast pas, elle n'a pas besoin de typage nominal. Il faut juste que l'objet qu'on lui passe en paramètre se comporte comme elle l'attends. En go il va falloir que tu explicite cet attendu dans une interface. Quand c'est simple et limité pas de problème quand ça devient plus complexe ça devient plus pratique de réutiliser l'interface initial mais tu a perdu l'intérêt de ton typage dynamique.

J'achète pas trop non plus l'argument manichéen qu'il faudrait être 100% statique ou 100% dynamique

Ce n'est pas mon point. Mon point c'est que le champs où dans les langages statiquement typés (globalement), on se place dans un contexte où l'on pète les informations de types (interface{} en go, Object en java, void* en C et C++,…) on se trouve dans un cadre où le langage que tu as choisi perds une partie de ses fonctionnalités et tu entre pas forcément clairement dans un paradigme différent. C'est un cas où on fait bien plus d'erreur car on ne manipule plus le langage de la même façon où on a l'habitude.

Il n'y a pas de manichéisme là dedans. Une approche différente, que je suis entrain de faire d'ailleurs c'est les intégrations de langage. Si tu met du groovy dans du java, du lua dans du C++ ou du C++ dans du python, tu aussi un changement de paradigme, mais il est bien plus évident à appréhender.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Une vision plus positive de la même chose serait : si on veut vraiment filter ou any en Go, on peut du moment qu'on accepte que cette partie du code ait les mêmes garanties qu'en Ruby :-)

Oui mais :

1. c'est très frustrant pour le développeur de perdre l'information de type juste à cause du système de type. Une fonction foo(interface{}) interface{} qui renvoie systématiquement le même type que ce qu'elle a reçu, tu es obligé de gérer des cas que tu sais inutiles juste parce que le typage n'est pas propagé
2. Go n'est pas Ruby. Un langage globalement typé dynamiquement te pousse à tout le temps vivre avec ce genre de choses. C'est prévu par le langage¹ et tu as une homogénéité sur l'ensemble de ton code. Là tu crée une section de ton code qui n'a plus le même typage. C'est un piège plus vicieux.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu as parfaitement compris mon point :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll