barmic 🦦 a écrit 5916 commentaires

Kotlin est le langage qui monte le plus dans les langages alternatifs qui tournent sur la JVM. Le fait qu’il soit poussé comme langage principal sur Android aide beaucoup.

Alors oui, mais j'ai pas l'impression que ça se maintienne tant que ça. Android c'est très particulier, puisque ça n'est pas OpenJDK et je crois que ART ne cherche même plus à coller avec les nouveautés de Java (l'usage des "nouveautés" de java8 semble se faire par des extensions). Sur le JDK kotlin avait marqué par gradle qui propose maintenant kotlin comme DSL (mais gradle est écris en java) et par spring qui le supporte (on parle ici d'avoir des apis pensaient pour un usage idiomatique de spring avec kotlin), mais en soit je ne le vois pas tant décoller que ça hors Android. Je peux tout à fait me tromper, hein ? Et j'apprécie kotlin, mais je ne le vois pas arriver. Je viens de regarder, évidement ça vaut ce que ça vaut, mais dans le dernier classement tiobe groovy est 17ème, scala 31ème et kotlin 34ème. Pour te donner une idée rust est 18ème et swift est 12ème pour d'autres langages récents.

C’est aussi celui qui ressemble le plus à Java (il a été pensé en gros comme « Java en mieux, avec des idées tirées de Scala, mais en plus pragmatique et plus efficace »).

C'est aussi un peu comme ça qu'a était pense groovy avec beaucoup plus d'ambition en terme de nouveauté et un énorme intérêt pour être vraiment interfaçable avec java (contrairement à scala, tu peux utiliser une bibliothèque groovy sans te rendre compte que ce n'est pas du java - à cause de collections qui n'existe pas dans java collection, de l'utilisation d'idiomes qui n'existent pas en java et qui font bizarre à l'usage, etc).

Groovy s’est rapidement fait dépasser en popularité par Kotlin (même si Gradle l’utilise (même si on peut scipter Gradle avec Kotlin))

Tu vois ça à partir de quoi ?

alors que c’est assez fréquent avec Kotlin, notamment parce que Scala est plus difficile à prendre en main (et a longtemps été lentissime à compiler).

Ça a était "fréquent" (gradle, android et spring), mais hors de ces 3 exemples qui commencent à dater un peu je n'ai pas vu d'autres annonces de ce type passer (mais je suis intéressé si tu as des exemples).

Et ça n’est pas une question d’implémentation mais clairement de fonctionnalités : en terme de fonctionnalités, Java rattrape Kotlin.

Ça a des implications. Les sealed classes sont écrites dans différents fichiers. Si tes classes sont grosses, tu peux trouver ça intéressant. La contrepartie, c'est que ta classe doit aussi être déclarée dans la classe mère ce qui est un peu plus moche (c'est moins DRY). Le pettern matching de java oblige à créer de nouvelles références tu ne pourra jamais écrire :

var a = foo();
if (a instanceof Integer) b+=a;

Ces choix ne sont pas vraiment anodins.

Tout mon propos est là : en tant que développeur et d’utilisateur au quotidien du langage, ça fait plaisir de voir que Java ne stagne plus comme il a pu le faire à plusieurs époques, et se décide à intégrer les bonnes idées qui viennent d’ailleurs dans la « communauté ».

Tout à fait d'accord. Je pense qu'à terme ça aurait posé de graves souci à Java. Comme C++, ils se sont donné un rythme et ça accélère les évolutions et c'est vraiment bien.

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

Un cadena est une cadena. Il a été conçu la sécurité.

Je pense que tu te méprend sur la sécurité en question. La majorité des cadenas de vélos s'ouvrent avec un ciseau mapped rapidement et discrètement sans compétence particulière (il suffit de connaître l'astuce).

La question c'est est-ce que la sécurité que je met en place, par rapport à ce que je cherche à protéger et par rapport à comment ça intéresse les gens.

Récupérer l'adresse d'une machine, via n'importe quelle forme de rickroll puis tenter de se connecter en UPnP sur l'IP récupérée ça ne coûte rien et ça marche sur pas mal de machines. Ça ne demande aucun travaille.

L'implémentation des NAT était aussi légère que ça.

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

Pourquoi kotlin plutôt que groovy, scala ou ceylon par exemple ? Clairement aucun de ses concepts n'ont était inventé par kotlin, ils ont même déjà d'autres implémentation sur la jvm. Et java a choisi des implémentations qui sont clairement distinct (sauf pour les blocs de textes, mais ça n'a pas toujours était le cas ça montre que ce n'est pas ce qui le conduit).

Avec l'organisation actuelle de l'écosystème, il me paraît normal de voir des langages arriver et faire des choses cool et d'avoir un java qui prends son temps et qui par contre a un développement couplé avec celui de la jvm, du jdk et des gc.

Quand JetBrain prends une décision et quand Amber prends une décision, ça ne prends pas le même temps et ça n'a pas le même impact.

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

J'avais adoré la présentation de Rémi Forax là dessus à devoxx France, il pensait qu'on aurait les inline pour java 10 (j'adore son optimisme ^^).

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

Pour rappel, Amber a pour but de rendre le Java plus agréable à écrire en le rendant plus expressif et plus concis.

J'ai l'impression que c'est le projet qui fait le plus parler de lui. Ça me donne l'impression que le projet Coin a montré que c'est cool de faire évoluer le langage :)

Merci pour les liens

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

Donc ce que tu as perdu, c'était surtout un faux sentiment de sécurité.

Je ne suis pas un spécialiste, mais je doute fortement de ça.

L'existence de méthodes qui, sous certaines conditions, permettent de by-passer une sécurité n'en fait pas un faux sentiment de sécurité. Tu n'utilise pas un cadenas inviolable pour ton vélo.

D'autant que firewall n'est pas inviolable non plus.

Et même avec tout ça, ça ne remet pas en cause le fait d'en profiter pour améliorer sa sécurité.

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

C'est gênant que ce soit la seule quand même…

Bof quand tu parle des avantages pour Chrome c'est encore plus petit (une peut-être sensation que ça va un peu plus vite).

(et surtout, depuis Quantum, ça passe par un hack, on se tape les onglets quand même en haut car impossible à enlever par l'extension, il faut un hack CSS qui ne peut s'enlever automatiquement si on n'a plus le panneau visible, donc expérience utilisateur bof, pas la priorité de Mozilla d'être différent)

Alors ne me considérant pas utilisateur lambda je vais me garder de parler pour eux. Mais en ce qui me concerne ça me permet à la fois de supprimer cette barre, mais aussi d'autres parties et d'en redimensionner certaines. Je m'en servais bien avant Quantum. Donc je suis plutôt satisfait que ça existe. Je doute que l'utilisateur lambda s'intéresse au fait de mettre les onglets en vertical.

Plus (mini subjectivement, voir autres commentaires) rapide à un moment, moins de pb de compatibilité (et de la faute de Mozilla hein, exemple), faire comme les potes et comme on a pas grand chose de nos jours pour dire que Firefox est mieux et qu'on n'est pas anti-Google que Mozilla met quand même en avant, toutes les erreurs de com' de Mozilla qui ont fait qu'on veut "punir" en quittant et que Google est certes pas mieux mais eux n'ont pas un manifeste disant qu'ils sont plus mieux bien, et j'en passe.

Un argument objectif clair et net d'un coté et de l'autre le seul argument intrinsèque à Firefox c'est "à une époque c'était subjectivement plus rapide" ? Ça n'est pas léger ?

Pour rappel même à la grande époque de firefox n'avais qu'un seul argument (et demi si on veut être gentil) : les onglets (le blocage de popup était possible sur IE, mais c'était pas une fonctionnalité de base. La barre de google par exemple le permettait).

On est surtout devant des logiciels qui sont arrivé à un point où il devient difficile d'innover. Que les développeurs aient une fibre libristes (comme Mozilla), qu'ils soient des armées à temps pleins (comme Google) ou qu'ils aient toujours fais de l'innovation leur marque de fabrique (comme Opera), il semble clair qu'on est arrivé à un plateau d'innovation. Ça n'est pas la faute de Mozilla. Tu peux leur reprocher de ne pas être irréprochable en terme de vie privée (à raison), mais ça ne changerais rien à l'affaire.

Regarde un exemple très simple. Zoom est un pur carnage en terme de vie privée, c'est probablement la pire solution possible, ils ont eux-même reconnu leurs problèmes. Ça ne les empêche pas d'avoir beaucoup mieux tirer leur épingle du jeu cette années que n'importe quelle autre solution de visoconf. Les gens pour qui l'UX est important comme tu le rappel ne choisissent pas du tout leurs logiciels en fonction de l'étique des développeurs. Être irréprochable n'est pas un argument pour eux.

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

C'est pour ça que je parlais de réduire.

donc leur principal intérêt c'est côté mémoire & perf et boilerplate.

C'est pas ce qu'ils indiquent pour la mémoire et la perf :

Goals

• Devise an object-oriented construct that expresses a simple aggregation of values.
• Help programmers to focus on modeling immutable data rather than extensible behavior.
• Automatically implement data-driven methods such as equals and accessors.
• Preserve long-standing Java principles such as nominal typing and migration compatibility.

Non-Goals

• It is not a goal to declare a "war on boilerplate". In particular, it is not a goal to address the problems of mutable classes which use the JavaBeans naming conventions.
• It is not a goal to add features such as properties or annotation-driven code generation, which are often proposed to streamline the declaration of classes for "Plain Old Java Objects".

Je ne vois rien qui parle de performance ou de mémoire, par contre je trouve drôle qu'ils cherchent à simplifier la création de structures simples sans faire la guerre au boilerplate. Je comprends plus ou moins l'idée, mais la façon dont c'est présenté dans la JEP me semble surtout chercher à montrer qu'ils ne veulent pas intégrer cette syntaxe dans les objets classiques.

De mon humble avis l'un des gros objectif finaux des records même si ce n'est pas encore implémenté c'est de pouvoir les déconstruires.

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

Le problème est que ça devient de plus en plus le seul argument pour Firefox : être contre Chrome.

Je trouve que c'est aller un peu vite. Personnellement mes onglets sont verticaux (grâce à tabcenter-redux que je préfère à Tree Style Tab) c'est impossible avec chrome par exemple. Je ne sais pas par contre ce qui fait utiliser Chrome pour un utilisateur éclairé (c'est à dire qui a connaissance des 2, qui sait les installer,…). Je crois avoir entendu dire que les outils de dev étaient un peu mieux, mais je suis pas sûr que ce ne soit pas un problème d'habitude par exemple.

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

Si tu indiquait un élément concret, ça pourrait peut être amener une discussion.

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

Compter sur un hypothétique pare-feu qui peut aussi être désactivé par inadvertance ou mal configuré est AMHA une erreur.

Compter sur le fait que tous les services de toutes les machines qui passent sur ton réseau soient bien configurer me semble aussi une erreur, d'autant que tu n'administre pas forcément toutes les machines de ton réseau. Entre le pc du pote qui vient passer la soirée, les smartphones d'amis venu prendre l'apéritif et voulant montrer leur photo de vacances, la console de jeu dont tu n'est pas administrateur, cette ampoule connectée qu'on t'a offert et qui bien que non hackable fait quand même le taff, l'imprimante réseau dont il n'est pas sûr que son implémentation soit solide, etc

Bref ça que l'on cherche à bien configurer ses machines c'est une bonne chose, mais ça ne me semble pas pour autant remettre en cause une solution simple.

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

Oui, mais il faut aussi le voir à l'envers. Aller voir un médecin pour avoir un arrêt de travail parce que tu as 3 symptômes bénins qui ne t'empêchent pas vraiment de travailler (même moins productif). C'était pas non plus forcément très bien vu.

C'est moins une question de responsabilité personnelle que de prise en compte et d'organisation collective (simplification des démarches, accepter qu'une maladie ou un symptôme n'est pas inventé, mise en place du télétravail, de rendez-vous médicaux à distance, arrêter de regarder bizarrement quelqu'un qui porte un masque, etc).

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

• de plus, bien que Chrome était initialement plus lent que Firefox sur presque tous les benchmarks, il s’appuyait sur de nombreuses astuces de conception qui donnaient l'impression que le produit était plus rapide — et les utilisateurs ont adoré cela.

Je trouve ça très intéressant. C'est un super exemple pour montrer comment se concentrer sur des benchmarks sans les remettre en cause et sans prendre le temps de remettre l'utilisateur au centre peut mener à des problèmes.

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

Dans un pays qui ne s'est pas remis de ses difficultés économiques depuis la crise débutée en 2007, je trouve improbable qu'aucun décideur n'ait vu là une occasion exceptionnelle de faire accepter quelques régressions d'un coup ; tester des changements dans une économie souffrante ; tester la société et sa réaction face à des pertes de liberté supplémentaires ; ou, encore, détourner à court terme les inquiétudes d'une partie de la population de la situation économique et sociale.

Tu décris des méchants de totally spies et tu dis que ce n'est pas manichéen ?

Les gens ne se disent pas qu'ils vont tester des lois comme dans les mission impossible on test des virus avant de les répandre sur le monde avec un rire de méchant. Non ils ont juste une idée différente de l'économie et suivent dur comme fer des économistes de renom bien plus caler que nous ne le seront jamais. Ce qu'il y a c'est qu'ils ne remettent pas en question ce qu'ils savent ou croient savoir alors que :

• ces éléments sont moins de la science dure que de la doctrine
• a énormément évolué récemment grâce à l'arrivée de recherches expérimentales dans le domaine

Donc je réfute le machiavélisme que tu semble leur donner.

Pour ce qui est de la communication, encore une fois l'expérience montre qu'ils font peur même quand il n'y a aucun enjeu. Affirmer sans autre argument que "ça doit bien exister" qu'il y a un dessein derrière cela est plus proche de la théorie du complot que de l'argumentation éclairée.

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

c'est une simple croyance

Non c'est juste la rasoir d'ockham et tes deux arguments ne tiennent pas pour moi.

On ne peut pas être terrorisé en continue donc oui comme tous ils font des erreurs dans la pratique. Ils sont aussi bien plus surveillé. C'est tellement agréable de pouvoir montrer qu'ils fautent.

La mesure de la peur est relativement compliquée et nous avons des exemples précédents le virus qui montrent que l'état français applique une doctrine qui engendre la peur sans la remettre en cause. C'est particulièrement difficile de prendre le risque de remettre en cause ce genre de doctrine pendant la crise. Je pense par exemple à l'incendie de Nantes.

Loin de moi l'idée de tout pardonner juste une explication moins manichéenne et diabolisante.

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

Je ne connais pas.

Pour les pool d'objets dont tu parlais plus haut, c'est tout de même assez relou à faire. Tu reconstruit un fonctionnement à la malloc/free avec tous les problèmes qui vont avec (use after release, fuite mémoire,…) et ton pool ne doit pas être un point de contention vu que tu va l'utiliser sur une partie du code plutôt stressée.

Je crois que ça peut être plus propre en C++ en utilisant un allocateur personnalisé (c'est transparent à l'usage tant que tu utilise du RAII).

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

Avec le code des jeux qui l'utilisent, ça fait une majorité du code final sous GC.

Ça n'est pas la partie critique.

Bref les GC modernes ne sont pas un problème dans les jeux.

On ne les utilise pas dans les parties critiques donc ce n'est pas un problème ? Soit.

Dis autrement ce n'est pas une question de performance des gc qui permet ça. Juste qu'on a construit des frameworks pour dissocier la partie critique de l'application. C'est une très bonne chose, hein pas une critique du tout.

Ni dans les applis web

Là c'est encore très différent. Pour un deamon qui aura par nature une durée de vie plus longue, c'est bien plus simple d'utiliser un gc pour limiter la fragmentation mémoire. Mais même comme ça les appli qui ont une certaine criticité vont faire du off the heap.

ni dans 99% des applis

De mon avis perso, « 99 % des appli » devraient plus s'intéresser à la correction qu'à la performance et donc éviter à tout prix de manipuler à la main la mémoire.

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

libgdx, pygame,… sont en C ou C++ plus qu'en python ou java quand ce n'est pas simplement sdl qui fait toutes la partie critique en terme de perf par exemple

Pourquoi ces jeux sont fluides et n'ont pas de gros ralentissements dû à un ramasse miette Arrête Le Monde?

Parce que la mémoire n'est pas géré par le garbage collector. Quand ut garde une taille de heap petite ça fonctionne bien.

les GC modernes ramassent les mettes de façon incrémentales et concurrentes, d'autre part les développeurs de jeux font la chasse aux allocations/désallocations en pré-allouant un maximum de choses, en utilisant des pools, en préférant des tableaux fixes aux hashmaps dynamiques…

Qu'il y ai des optimisations possibles on est d'accord, mais elles ne peuvent pas tout. Tu ne peux pas allouer directement un objet en old generation par exemple ce qui permettrait de ne pas voir ton gc passer des objets que tu sais qu'ils ne sont pas à détruire.

Cette chasse est faite aussi dans les jeux en C/C++, car comme je l'ai déjà dit aussi, les malloc/free, c'est coûteux pour tout le monde, pas seulement quand c'est un GC qui les fait.

Je crois que l'allocation mémoire est plus coûteuses en natif que dans la JVM qui gère déjà sa mémoire vis à vis de l'OS.

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

Tu veux dire le nombre de jeux qui utilisent un gc en frontend ? Oui il y en a pas mal, mais il n'y a aucune contrainte pour ce genre de code. Ce n'est pas la prouesse de leur gestion mémoire qui permet ça, mais leur capacité à s'interfacer avec du code natif. C'est pour ça qu'on trouve lua par exemple.

Pour parler de java, je doute que l'on trouve une application dont la mémoire est crucial qui ne fasse pas du off the heap.

C'est comme dire que la gestion mémoire de python est sacrément bonne parce que si on utilise numpy ça déchire. C'est moins sa gestion mémoire que la qualité de son interface avec du natif que l'on estime.

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

Mais ça n'est pas stable non plus.

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

il faut l'exécuter plusieurs fois (> 1000 ? > 10 000 ?)

Jusqu'à ce que la moyenne se stabilise.

Mais très clairement, un écart-type élevé est bienvenu pour la génération de l'entropie.

Du code qui fait des io est pratique pour ça.

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

Aujourd'hui les vraies pauses sont si petites qu'on ne les remarque plus (CTB !).

Dépend des usages, ça. ZGC qui est monstrueux annonce 2ms, ce qui est bien trop important pour un jeu vidéo temps réel.

Il y a même un GC pauseless pour Java, mais il n'est pas libre :(

Je n'ai jamais essayé azul zing.

Note aussi que le temps d'exécution des autres modes de libération de la mémoire n'est pas NULL non plus.

Ils ne bloquent jamais toute l'application, ils sont totalement prédictibles, ils ne prennent pas de temps CPU hors de la libération de la mémoire,…

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

L'autre "problème" des langages managés en termes de perfs c'est le JIT (compilation à la volée).

C'est discutable. Le JIT a beaucoup plus d'info que la compilation AOT pour faire ces choix et ce n'est pas quelque chose de continue aucun langage managé que je connais ne compile du code continuellement (sinon c'est plus proche d'un code interprété en fait), une fois que le JIT est passé, c'est juste du code natif qui s'exécute. Si ton jeu s'exécute peu de temps ça pose un problème, mais sinon ça ne fait pose pas tant de problème que ça.

Je pense que c'est plus la gestion de la mémoire qui pose problème (les gc créent un overhead en consommation mémoire, ça demande un certains tunning d'avoir un gc qui s'exécute correctement sur du temps réel comme ça,…).

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

Les premiers GC stoppaient le monde.

Les derniers aussi. Ils sont plus efficaces, mais oui le stop the world existe toujours.

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

Euh, les fuites mémoires à cause d'évènements ou d'objets non-disposés (utilisant des connexions à des bases de données, des ressources réseau, des Span, …), ça arrive et ça fait mal.

Tu as bien plus drôle à faire : utiliser des lambda comme callback sans te rendre compte que ce que tu capture dans ta fermeture. Ça touche tous langages objet qui a des lambdas et personne ne peux rien pour toi. C++ est peut être un peu mieux loti car il rends explicite la capture, mais pas au point de voir quel objet est dans la capture.

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