barmic 🦦 a écrit 5783 commentaires

Il me semble que certaines passes de llvm étaient loin d'être optimales pour rust. Plus exactement que la transcription de rust vers le format/langage pivot de llvm était difficile à faire.

Dis autrement rust utilise llvm, mais si le backend est aussi mature que le projet llvm lui-même le frontend est une nouveauté construite pour rust (pas from scratch, mais on est pas à la maturité de backend).

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

C'est ce que j'ai tendance à faire particulièrement à l'étranger où il n'est pas forcément évident de connaître la vitesse limite.

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

Je vais tenter d'exprimer ce que je pense qu'a voulu dire pulkomandy de manière encore plus neutre.

Si le projet choisi des systèmes qu'ils supportent et d'autres qu'ils ne supportent pas pour des raisons politiques : qu'est-ce qui décrit de manière clair et pas sujet à interprétation les systèmes acceptables ou non par le projet ?

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

Là encore, fais des suppositions, puis tu tires des conclusions à partir des suppositions que tu as tirées – qui sont donc fausses.

J'ai décris comment moi j'ai fais et fini en disant que ça ne suffit peut être pas pour tout le monde. On arrivait à le faire aussi avec jenkins via les secrets.

Je ne dis pas que tu ne rencontre pas de problème, mais que dire que dès que tu es multi-dépôts ça ne marche pas c'est faux. Ils ne gèrent probablement pas tous les cas (j'imagine par exemple que selon le runtime que tu utilise ça va coincer), ça pourrait être plus simple, ça pourrait être mieux géré (jenkins en soit est relou à ustiliser).

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

Tu déformes mon propos et tu réponds à la déformation, on ne va pas aller loin comme ça.

Le problème des « cases » n'est pas « les vieilles technologies ».

Ce n'était pas ma volonté, mais quand j'entends « projet sur le quel on a pas la main » c'est généralement pour expliquer que la dette technique elle est chère etc.

D'ailleurs le pire pom.xml que j'ai croisé (près de 10 000 – dix mille – lignes était un projet qui avait quatre ans, en Java 11, et qui respectait la structure habituelle des projets Maven.

Je ne vois pas comment c'est expliquable (autrement que par de l'incompétence¹). Donne leur le build tool que tu veux ils feront n'importe quoi avec. D'ailleurs être en mesure de sortir ça avec maven, ça me fait peur d'imaginer ce que ça pourrait donner avec gradle.

Non, quand je parle de « cases » qui sont trop petites et qui nécessitent des contournements, il ne faut pas aller chercher loin. Par exemple, avoir trois dépôts Docker séparés pour les builds snapshot / release / nightly.

On gère ça avec une properties dockerRepository qu'on set comme on le souhaite. On a pas de nightly, mais dev par défaut, qlf on surcharge via la CLI et release c'est reset dans un completion goal du release prepare. Ça convient peut être pas chez vous.

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

Ça, et la gymnastique imposée par le langage autour des types signés uniquement, dans un contexte embarqué où il faut discuter avec des chips par messages fignolés au bit près, c'est gavant.

On pourrait dire l'inverse sur l'utilisation d'entiers plus ou moins longs (signés ou non) et de caractères (?) (toujours signé ou non (???)) pour représenter une suite de bit. Tout le monde est naît avec ça du coup on le voit plus mais ça n'est pratique que parce qu'on a des années d’expérience. Utiliser quelque chose qui représente un champ de bit est beaucoup plus pratique.

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

[…] ils sont conçus pour ce cas de build simple où tu rentres très exactement dans les cases prévues, mais pas pour la vie réelle où tu as des cas plus complexes sur lesquels tu n’as pas la main.

Ça demande une certaine mauvaise fois ou à minima un haut niveau d’exagération d'affirmer ça quand on voit un maven qui a était conçu pour normaliser à fond les builds et qui a rencontré un gros succès. Cette même normalisation d'ailleurs sur la quelle s'appuient gradle/sbt/ant+ivy pour ne pas avoir à réinventer la roue.

Je ne dis pas que l'inverse n'existe pas, mais affirmer que « dans la vie réelle » les conventions ça marche pas et tu dois tweaker c'est y aller fort.

Après c'est toujours pareil, les softs qui continuent de tourner en Java5, de compiler qu'avec gcc 2.92, d'utiliser une interface XUL,… personne n'a envi de payer leur dette à leur place. Ça peut être vu comme une forme de jeunisme, mais c'est aussi une question de ne pas ossifier les technologies.

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

1. Toute la complexité est masquée derrière une syntaxe et des « outils » qui se veulent simples.
2. La partie masquée de la complexité est rendue artificiellement inaccessible, parce que les API mises à disposition sont trop partielles et n’ont pas de points d’extension :
3. Même configurés à fond de leurs capacités, les meilleurs IDE n’ont pas les moyens de donner des conseils pertinents.
4. On doit donc se reposer entièrement sur la documentation, qui est souvent mauvaise.
5. La notion même de DSL rends complexe le lien entre une déclaration et le code exécuté – ce qui empêche l’exploration pour savoir ce qui va être fait exactement.
6. On peut mettre du code arbitraire ou presque, mais le debug est impossible (notamment les points d’arrêt).
7. Rien n’est typé et la syntaxe est trop libérale, on découvre toutes les typo au runtime.
8. Comme le DSL masque la complexité, plus personne ne comprends ce qui se passe réellement2. Conséquence : les plugins sont d’une qualité catastrophique et conçus pour ne gérer que le cas précis de la personne qui les a développés – or ces plugins sont indispensables.
9. Pire : les documentations pour développer (ou aider à la maintenance) des plugins sont elles-mêmes mauvaises, ce qui empire le phénomène.

Tout ce que tu décrit au choix :

• marche aussi bien pour l'utilisation de langages déclaratifs (1, 2, 4, 5, 8)
• n'ont rien d'intrinsèque à l'utilisation d'un langage impératif (7, 9)
• le typage est très dépendant du langage que tu choisi (7)
• je ne vois pas beaucoup d'outil véritablement aider pour le 3, par exemple netbeans est le seul outil à faire une intégration poussée de maven, les gens se contente très bien d'intelij qui a une intégration à peu près équivalente pour maven et gradle

Le seul point qui reste c'est d'avoir du code que tu ne peux pas facilement debugger. La solution est toute trouvée c'est de ne pas fournir un outil qui se configure via un DSL, mais une bibliothèque que tu utilise dans le build que tu implémente. C'est comme ça que fonctionne le gestionnaire de fenêtre xmonad par exemple.

Personnellement je trouve qu'il y a infiniment plus de valeur à avoir un build simple qui ne cherche pas à triturer pleins de choses parce que "tu comprends mon projet il est différent de tous les autres donc je vais pas me contenter de faire comme tout le monde" et je pense que si un outil de build passe à se paradigme ça va donner des builds infernaux à maintenir dans le temps et à comprendre.

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

Depuis 2008, l'article 18 de la Constitution autorise le président de la République à tenir un discours devant le Parlement réuni en congrès. Avant c'était autorisé mais sous forme de message (pas de présence personnelle du président). Le Parlement peut débattre mais aucun vote ne peut avoir lieu dans un tel cadre, justement dans le but d'éviter un coup d'Etat orchestré par le président qui pourrait faire pression directe sur les parlementaires.

Ce qui n'a rien à voir avec la venu d'un président à l'Hôtel de Lassay. Strictement rien.
Ce n'est pas illégal pour autant ce n'est pas l'hémicycle. Mais pour ce qui est de l'esprit de la règle ça avait fait débat.

Et oui je suis d'accord que les coutumes ont un certains poids, j'ai juste dis qu'en France on est habitué à inscrire dans les textes beaucoup plus de choses.

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

Meme si la tradition veut qu'il n'utilise aucun de ces pouvoirs, constitutionnellement, il a quand meme pas mal de pouvoirs.

Ça paraît choquant vu qu'en France j'ai l'impression que les hommes politiques jouent au maximum avec le degrés de liberté que les textes leur donnent.

En France à cause du coup d'État de Napoléon, le président n'a plus le droit d'aller à l'assemblée nationale. Au Royaume-Uni je suis persuadé qu'ils ne ce seraient pas embêté à l'écrire sur un texte chez nous c'est constitutionnel. Malgré ça n'a pas empêché Hollande de jouer avec la règle en allant à l'Hôtel de Lassay, mitoyen du Palais Bourbon.

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

Oui je suis allé un peu vite.

Après pour faire la même chose il faut ajouter pas mal annotation dans ton code (pour utiliser le sharing de splint). Ça revient un peu à dire que les langages objets n'apportent rien face au C puisque le C++ ou l'ObjectiveC existent.

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

C'est loin d'être au niveau de ce qui est pointé plus haut. En particulier aucune de ces options ne s'approche de ce que fait le borrow checker alors que splint si. Il faut ajouter pleins d'annotations à ton code, mais il fait des vérifications approchantes. Bon il n'a pas reçu de mises à jour ces 12 dernières années donc il maîtrise probablement bien moins de cas que le borrow checker de rust qui est régulièrement amélioré sur ce point.

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

D'autant plus pour un éditeur d'au moins 3 plateformes (windows, azure, xbox). C'est pas anormal de donner son avis. Surtout qu'on peut pas les taxer de mettre en avant un de leur produit (comme ça pourrait être le cas avec C# ou F# par exemple).

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

• https://github.com/NASA-SW-VnV/ikos/
• http://splint.org/
• … (voir https://github.com/analysis-tools-dev/static-analysis )

L'analyse statique ne fais que ce qu'elle peut quand le langage ne te donne pas la sémantique de ce que tu veux analyser. D'après-toi, pourquoi est-ce que ces solutions ne sont pas incluses dans gcc ou clang ? Pourquoi est-ce que c'est à ajouter à ton processus de build et pas directement inclut dans ton installation et activé avec un -pdantic ?

vous savez que les applications qui monitorent/contrôlent les réacteurs nucléaires, ou machines médicales à rayons X, ou autre trucs qui peuvent tuer des gens sont minoritaires ?

Les plus hautes sécurités ne sont pas liées au langage. C'est le processus de développement qui assure la qualité et non une silver bullet derrière la quelle on se sentirait protégé. Ça peut incorporer comment faire des tests, quand, sur quelle partie, comment suivre les défauts, la traçabilité des choix, ça peut inclure de la preuve de programme aussi, dans certains cas ça peut aller jusqu'à faire une enquête de de moralité des intervenants.

Aucune solution technique ne te protègera d'un bug fonctionnel hors dans les cas les plus critiques tu ne veux pas avoir de problème fonctionnel.

Vous savez que Rust n'a rien inventé ?

Comme tout langage rust est un équilibre choisi entre tout un tas de paramètres (sécurité mémoire, taille du runtime, sémantique du langage, système de type, etc) en prenant en compte l'état de l'art au moment de sa conception. L'équilibre choisi entre sécurité mémoire par défaut et légèreté du système de type le rend populaire.

C'est aussi bête de croire que rust résout toutes les difficultés sans surcoût que de se cacher les yeux en affirmant qu'il n'apporte rien.

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

pédagogie : jamais été mis comme exception

C'est des fois décrit comme exception. Dans un cadre pédagogique c'est autorisé grâce au ministère qui fait ce qu'il faut pour : Exception pédagogique

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

et dans les 99 autres % (le bon dev n'est pas forcément un bon statisticien) il choisi ocaml

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

La réalité est que les "libristes par conviction" sont tellement occupés avec leur petite personne qu'ils oublient de fournir quelque chose de concret, en effet.

C'est intéressant parce que tu es aussi l'un de ceux qui pointent du doigt ceux qui "n'aiment pas le libre". Il faut adhérer au libre sans conviction ?

Le plus amusant est qu'il n'y a rien de nouveau depuis pfff longtemps, toujours à se plaindre, jamais à se bouger.

Ça c'est des bêtises beaucoup beaucoup de gens font vivre leur idée du libre, construisent des communautés, du logiciel et/ou du service. Ils font ça avec leurs valeurs, tu peux essayer de leur dire que c'est pas du libre, que c'est à côté ou hors du libre c'est pas grave, c'est ce qu'ils font sans avoir besoin d'un tampon zenitram ou gnu approuval. Ils créent justement plutôt que d'étiqueter (ce qui est la raison d'être principal de tout libriste il faut pas ce le cacher).

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

Il faut garder une certaine sérénité rust ne fait pas tout. Ils continuent de bosser sur le borrow checker encore de version en version parce que tu as des cas où tu es très très loin de "l'aisance d'un gc sans runtime".

Il est très bien, je suis pas entrain de dire que c'est mauvais ou une fausse bonne idée, mais c'est pas (encore ?) le meilleur des 2 mondes sans aucun accroc.

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

Dans ton premier lien je ne suis pas sûr de comprendre :

pour le niveau de garantie élevé, il ne suffit pas qu’une carte à puce protège une clé cryptographique contre les manipulations non autorisées ; en outre, le protocole cryptographique doit protéger le mécanisme de vérification de la possession de la clé contre les manipulations non autorisées et les attaques par rejeu ;

Le second lien n'a pas l'air de dire que l'authentification forte nécessite un facteur de possession avec composants de sécurité et qu'il faut privilégier ceux audité par l'ANSI. Ça ne me semble pas proscrire les clefs (dont ils font d'ailleurs mentions en parlant de token fido).

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

Personne n'a inventé le capitalisme, c'est le système naturel lié à la liberté d'entreprendre qui a su faire ses preuves pour améliorer les conditions de vie de tous.

Ah ? Il a détruit la majorité des économies moins productivistes mais aussi moins destructrice. Il a amené de nouvelles classes de domination sociales lorsque la noblesse et le clergé ont perdu du pouvoir. Il a permis de faire des guerres et des massacres à des niveaux qui n'ont aucun sens.

Aucun autre système n'a d'ailleurs eu les mêmes impacts.

Tu parles de l'écocide ?

---

Tout n'était pas mieux avant loin de là, mais :

1. Ça n'est pas une raison pour ignorer ce qu'il produit de plus néfaste
2. Je ne suis pas certains que l'amélioration du niveau de vie ce soit fait grâce au capitalisme ou malgré lui. Dans le même interval, on a eu des progrès techniques majeurs mais aussi des avancées démocratiques
3. Quelque soit ce qu'il apporte ça ne le met pas hors de porter des critiques pour l'améliorer ou le remplacer

Simplement avancer qu'il serait "naturel" n'est pas un argument en soit.

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

Je ne trouve pas que ça mérite le mépris de ton premier commentaire, mais c'est vrai qu'il manque des trucs dans l'article. Comme la structure given/when qui est un switch plus puissant que dans la plupart des langages, le defer qui marche un peu comme go, différentes avancées dans les expressions régulières,… et je n'ai pas particulièrement suivi le langage ses 10 dernières années.

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

Le problème c'est que j'ai l'impression que les gens pensent "sous linux, la ligne de commande est normal, c'est la routine".

C'est exactement mon cas, mon terminal est mon gestionnaire de fenêtres. Je ne me dit pas "bon c'est de la cli, donc je dois faire particulièrement attention".

Est-ce que je suis un power user ? Probablement, mais pas en tout. Le fait que je sache me servir de git et de certaines fonctionnalités avancées de se dernier ne fait pas de moi quelqu'un qui maîtrise les subtilités d'apt (j'ai appris il y a 2 mois qu'il pouvait installer des .deb, on est plus obligé de passer par dpkg puis faire un apt-get -f install. Ça fait une petite dizaine d'années que j'ai raté l'info 😭).

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

Bon je remet une petite pièce.

Tu t'es contenté d'essayer d'adapter le cas de départ pour qu'il puisse fonctionner avec les différentes solutions à base de GC que tu avais en mains,

Tu a précisé le contexte dans le quel tu voulais te placer et je n'ai remis en cause que ton dernier point que je n'ai jamais vu appliqué.

ce qu'on ferait si on était contraint d'en utiliser un

C'était exactement l'objectif tu pense que c'était quoi ma thèse ? Montrer comment on fait avec un gc, en particulier sur la jvm que je connais mieux que les autres.

[…] ou de dire que tu ne vois pas où ça serait utile.

Oui en absence de cas pratique où c'est utilisé, je veux bien qu'on me montre.

Bref, toujours pas de solution à base de GC pour garantir une frame, donc de la stabilité…

Ta façon de répéter continuellement comme s'il s'agissait d'une joute que tu souhaiterais gagner plutôt que comme un échange de comment parvenir à un objectif est extrêmement irritant. Bravo, tu as gagné. Tu m'a écrasé. Je n'ai plus d'argument et tu peux te conforter dans ton idée initial. L'échange a dû te rassurer au détriment de t'enrichir. Tant pis.

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

Donc, tu ne peux pas dire "il me reste 14ms pour cette frame-ci, gc pendant ce temps" et à la frame suivante lui demander de le faire pendant 5ms parce que tu as du faire du calcul un peu plus intensif.

Je vois pas de cas où ça serait utile, cette gestion a un coût et peu être facilement source de bug.

Mais rien de tout ça n'est dynamique vu ce que tu as écrit plus haut.

Quand tu parle en frame tu n'es pas dynamique. Une frame est une période de temps. Quand tu construit ta logique avec ça, tu considère ton travail max à faire dans ta frame et c'est comme ça que tu dimensionne. Dans le cas des jeux puisque c'est l'exemple dont tu parlais, c'est pour cette raison là que tu as des limites de nombres de sprites par exemple.

mais le gc peut t'expliquer quand il a fait quoi et pourquoi ça couplé aux autres possibilités d'observabilité de la jvm t'es pas laissé tout seul pour te dépatouiller et comprendre ce qu'il se passe.

C'est bien beau, mais quand ça dépend de l'utilisateur on est loin d'un truc qui scale automagiquement

C'est une question de dimensionnement. Tu as une frame tu organise ce que tu peux faire ou non dans cette période. Tu met toujours une limite à ce qu'il est possible de faire sinon tu ne peux plus donner aucune garantie.

Mais si tu te retrouves dans le cas ci-dessus avec les garbage collector actuels, t'as rien d'autre à faire que tortiller tes données et virer des features pour pouvoir éviter d'avoir à nettoyer quand une gestion manuelle aurait pu t'éviter ce soucis.

"Tortiller tes données" oui et non. Il s'agit d'organiser ton logiciel autour des contraintes que tu lui donne. Si tu donne des contraintes forte de performance ça se verra sur ton code quelque soit le langage que tu choisi. Venir poser des contraintes très fortes pour ensuite reprocher que ça a un impact sur le code c'est assez vouloir le beurre et l'argent du beurre. Si tu fais des parallels arrays par exemple ou toute autre technique de data oriented design, tu va faire des choix qui vont s'approcher d'un "tortillage de donnée". C'est l'objectif même de rust de te contraindre à des formes de torillage de données pour ton bien et ceux que la mémoire soit un sujet ou non dans ton programme et il va te demander de débrailler des fonctionnalités (en particulier le borrow checker) pour arriver à ce que tu souhaite (un exemple de comment tu peux en arriver à tortiller tes données ou désactiver des fonctionnalités pour faire des références circulaires en rust).

Je vais arrêter là par contre, j'ai exposé, il me semble, des points précis sur comment faire et je n'ai pas l'impression que tes arguments aillent plus loin que « c'est pas assez parce que dans un contexte théorique on pourrait faire mieux », sans rentrer dans un cas pratique qui demanderait beaucoup de travail je ne vois pas comment aller plus loin dans la discussion et j'avoue que ça me fatigue un peu.

Bonne journée

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

Tu parle de ça ? https://towardsdatascience.com/memory-management-and-garbage-collection-in-python-c1cb51d1612c

Je vois pas ce qui indique en quoi c'est plus ou moins efficace que ce fais java.

Je connais pas très bien python, mais il me semble qu'il doit bénéficier du fait que les bibliothèques qui manipulent de gros volumes de données font ça en C et sont donc hors de la pile. En java tu peux le faire sans passer par du C, mais ça me semble moins généralisé.

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