Bon, allez, après ce titre totalement faux mais qui permet d'attirer le chalant, reprenons l'historique et voyons ce qu'il en est vraiment.
Google utilise C++ en interne pour obtenir le maximum de performance de ses algorithmes et donc pour maximiser ses profits. Donc, toute amélioration de performance dans C++ est un gain en argent pour Google.
Or, Google a été mis en échec dans sa tentative pour mettre en priorité de C++ la performance, au profit de la stabilité de l'ABI. Quoi qu'est-ce ? En effet, l'ABI de C++ ne fait pas partie du standard mais il y a un consensus mou pour essayer de ne pas casser l'ABI de la bibliothèque standard. Microsoft cassait l'ABI de son implémentation à chaque version dans les années 2000 et ça passait relativement bien (modulo les 5 ou 6 versions compilées qu'il fallait fournir). On peut aussi citer le changement d'ABI de std::string dans la libstdc++ après C++11 qui a eu des remous pendant assez longtemps dans les distributions Linux.
Seulement, la stabilité de l'ABI a un coût : les mauvaises décisions d'implémentation restent. Raison pour laquelle std::regex par exemple est trèèèèès lent parce que ceux qui l'ont implémenté au départ ne savaient pas bien s'y prendre et ont gravé dans le marbre ces erreurs. On pourrait aussi citer std::vector<bool> qui est très ancien et qui, contrairement à ce que son nom pourrait laisser croire, n'est pas un std::vector et ne contient pas de bool ! En effet, le standard force à une implémentation à base de bits pour représenter true/false et donc crée une exception dans std::vector qui provoque plein de désagréments.
Bref, Google pas content, et donc Google s'est retiré du comité de normalisation C++ et même de l'implémentation de clang, l'alternative à g++. Ça s'est vu, le développement de clang a pris un bon coup dans les dents.
Et donc Google a décidé de sortir son propre langage : Carbon. Carbon est à C++ ce que TypeScript est à JavaScript et Kotlin à Java : c'est largement compatible, ça peut utiliser l'autre, mais ça vit à côté. Il est difficile pour l'heure de savoir les conséquences que cette nouvelle va avoir. Google n'en est pas à son premier langage maison (Go, Dart, etc). Mais c'est en tout cas un sacré coup de froid au milieu de cette chaleur estival dans le petit monde C++.
Pour aller plus loin, le thread Reddit sur le sujet.
# https://killedbygoogle.com/
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Pourquoi ils n'utilisent pas Go pour ça ? Parce que le Go est lent ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: https://killedbygoogle.com/
Posté par jtremesay (site web personnel) . Évalué à 7.
1- ils avaient peut-être déjà certains projets en C++ qu’ils ne veulent pas convertir parce que c’est relou
2- une lib c++ peut-être utilisé avec quasiment tous les langages. Ce n’est peut-être cas avec Go. J’en sais rien, je ne connais pas. Ce post reddit laisse entendre que c’est possible mais lent
3- d’après ces benchs (qui valent ce qui valent), oui, C++ est plus rapide que Go.
[^] # Re: https://killedbygoogle.com/
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
A condition de ne pas péter l'ABI :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: https://killedbygoogle.com/
Posté par vitanix . Évalué à 6.
Après avoir lu ça, il me semble que le principal problème c'est que les équipes de Google ne peuvent pas convertir tout leur code C++ dans un nouveau langage. Il faut que le nouveau langage puisse s'interfacer avec le C++. Il y a plein de langages qui s'interfacent assez bien avec le C et les struct, mais pour le C++, c'est plus compliqué.
Par exemple, si carbon appel une méthode du C++ qui prends en paramètre un vecteur d'une classe en C++. il va falloir créer les objets du C++ dans Carbon, puis créer un vector de la librairie C++ dans carbon, et après faire l'appel à la méthode. Et je ne parle même pas des problèmes de méthode template, du Name mangling, et autres joyeuseté du C++.
D’ailleurs, on dirait qu'ils vont migrer tout leur code C++ sur Carbon, et apres au revoir C++. Ils seront plus ou moins compatible jusqu’à C++17, et pour C++20, ils vont faire au cas par cas :
Interoperability will target C++17. Any interoperability support for future versions of C++, including features such as C++20 modules, will be based on a cost-benefit analysis. Exhaustive support should not be assumed.
[^] # Re: https://killedbygoogle.com/
Posté par reno . Évalué à 9.
Le problème principal de Google sur le C++ "normal" était lié a des problèmes de performance donc évidemment utiliser du Go qui est plus lent que le C++ n'aurait pas de sens.
Même si Go avait des perf similaire au C++, ils ont une base installée énorme de C++, donc ça fait plus de sens pour eux de "faire évoluer le C++" que de wrapper ça par du Go.
[^] # Re: https://killedbygoogle.com/
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
La question de la base de code existante à elle-seule peut justifier le désir de travailler sur l'amélioration de C++
Par ailleurs, Alphabet a une volonté de ne pas mettre tous ses œufs dans le même panier et de favoriser la biodiversité du coding.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: https://killedbygoogle.com/
Posté par Lutin . Évalué à 10.
C'est une vraie question ou un jeu de mots laid ?
[^] # Re: https://killedbygoogle.com/
Posté par gUI (Mastodon) . Évalué à 7.
Il paraît que c'est à ça qu'on reconnaît les gens bêtes
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: https://killedbygoogle.com/
Posté par jtremesay (site web personnel) . Évalué à 3.
hum. Vous pouvez me comptez dans les bêtes qui mangent du foin.
[^] # Re: https://killedbygoogle.com/
Posté par Colin Pitrat (site web personnel) . Évalué à 7.
Moi qui pensais qu'il faisait partie des gens bons.
[^] # Re: https://killedbygoogle.com/
Posté par nico4nicolas . Évalué à 9.
Si c'est un jeu de mot, il ne vole pas haut.
[^] # Re: https://killedbygoogle.com/
Posté par esdeem . Évalué à 3.
C'est ce qu l'on appelle un jeu de mots de cycliste.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: https://killedbygoogle.com/
Posté par woffer 🐧 . Évalué à 8.
Je ne pense pas que le Go et le C++ jouent dans la même cours.
Go ne sera jamais rapide comme le C/C++/Rust/(ajouter ici le langage de votre choix).
Pour moi, le Go brille dans les domaines où les applications passent la majorité de leurs temps à attendre les entrées/sorties (I/O bound) et dans des environnements d’exécution contraints (i.e. tournant sur des pods avec 50 millicpu & 50 mo de ram parce que ça coûte moins cher chez AWS/GCP/Azur/on-premise/(ajouter ici le cloud provider de votre choix). Dans ce domaines, Go permet très facilement de gérer ce genre de problèmes sans que les développeurs s'en soucient de trop (merci aux goroutines, à la sobriété de son runtime et à la simplicité de configuration son garbage collector).
Là, j'ai l'impression, peut-être à tort, qu'on parle plus de d’algorithme dont la limite sera plus la puissance de calcule (CPU bound) avec des gros volumes de données qui n'est pas pour moi le cœur de la cible de Go.
[^] # Re: https://killedbygoogle.com/
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Snif c'est dommage qu'on oublie ce bon vieux Pascal qui est plus vieux que le C et pourtant mieux fichu.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: https://killedbygoogle.com/
Posté par porki . Évalué à 0.
Je ne partage pas les multiples remarques que je vois ici sur la vitesse d'exécution de Go. Autant je partage le fait que Go soit plus lent que C et Rust, autant je trouve que la différence de vitesse entre Go et C++ est minime (cela dépend des algos, mais rien de systématique).
[^] # Re: https://killedbygoogle.com/
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Différence minime, mais là on parle de gens qui ont des algos répartis sur des data-center de taille déraisonnablement grandes, donc des améliorations minimes ont un vrai impact sur la facture d'électricité et celle d'achat de machines.
La FAQ de Carbon est assez parlante sur ce point : Why not a garbage collected language, like Java, Kotlin, or Go? (notez l'emphase sur le mot « contrôle », pas sur « performance »).
[^] # Re: https://killedbygoogle.com/
Posté par porki . Évalué à 9. Dernière modification le 22 juillet 2022 à 12:17.
La réponse est sur le site web de Carbon.
Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should. Unfortunately, the designs of these languages present significant barriers to adoption and migration from C++.
Traduction : Les langages modernes déjà existants fournissent déjà une excellente expérience au développeur : Go, Swift, Kotlin, Rust et d'autres encore. Les développeurs qui peuvent utiliser ces langages de programmation devraient le faire. Malheureusement, la manière dont ces langages furent conçus, présente des obstacles significatifs à l'adoption et à la migration depuis C++.
[^] # Re: https://killedbygoogle.com/
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 9.
N'en as-t-on pas fait une maxime prophétique dans les années 70 : « John attend, le Go est lent ! »
Du coup — excepté pour les fans de S. Beckett — ça ne donne pas envie.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# mouais
Posté par nazcafan . Évalué à 9.
Le projet sera tué en avril prochain, pour le sprint cleaning, et ils crééront un nouveau truc par dessus python pour que Dédé puisse avoir sa promotion et acheter le Porsche Cayenne biturbo.
[^] # Re: mouais
Posté par batisteo . Évalué à 1.
J’aimerais bien qu’ils tuent Golang et Dart aussi. C’est pas parce que c’est bon pour Google que c’est bon pour toi.
[^] # Re: mouais
Posté par YBoy360 (site web personnel) . Évalué à 7.
À voir, si Dart avait pu tuer le JavaScript, je m'en porterai pas plus mal… Heureusement pour certains, on est pas obligé de tuer pour survivre. Chacun sa place.
# zut, ma souris a fourché
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à -9.
Trop tard, le chalant a cliqué sur inutile et non pertinent avant de voir le disclaimer.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# C'est moi ou c'est idiot ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
C'est moi ou c'est idiot, comme démarche ? D'après ce que j'en ai compris, ça se résume tout de même à:
Le passage du point 2 au point 3 me semble complètement foireux. Si l'API ou l'ABI de la bibliothèque standard ne plaît pas à Google, ils peuvent bien ne pas l'utiliser, en faire un fork, recoder la leur pas compatible en l'appelant autrement, bref ce ne sont pas les possibilités qui manquent. Si l'ABI des programmes compilés ne leur plaît pas, ils sont encore plus libres d'en changer.
Bref, un nouveau langage, pourquoi pas, mais justifier ça en parlant des pénalités imposées par l'ABI de la bibliothèque standard, non normalisée, qu'on a pour tradition récente de ne pas changer, mais qui a été changée dans le passé, c'est plus que fallacieux, non ?
[^] # Re: C'est moi ou c'est idiot ?
Posté par jseb . Évalué à 7.
Je me suis posé la même question. Comme chez Google ils sont über intelligents, j'ai pensé que je n'avais pas compris quelque chose…
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: C'est moi ou c'est idiot ?
Posté par Gof (site web personnel) . Évalué à 9.
Le journal parle beaucoup d'ABI, mais c'est pas du tout la raison derrière Carbon. Si tu lis la description de la motivation sur leur GitHub, l'ABI n'est même pas mentionnée.
[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . Évalué à 8.
Si si, ils en parlent. Au delà de l'ABI, c'est bien la performance qui est en jeu. La préservation de l'ABI n'est que le symptôme.
[^] # Re: C'est moi ou c'est idiot ?
Posté par Gof (site web personnel) . Évalué à 7.
Ils en parlent in peu dans une sous-page comme un des multiples exemples qui font que faire évoluer le C++ est difficile.
Le problème c'est que ton journal laisse penser que le maintien de l'ABI est la principale raison qui a poussé Google pour créé ce langage. Et c'est loin d'être le cas.
Ils veulent juste un langage plus sûr, plus facile a apprendre et utiliser, tout en gardant les même performances que C++ et interopérabilité avec le code c++ existant.
Bref, c'est même pas la performance qui est la motivation, puisqu'il disent qu'ils veulent les mêmes performances que C++, pas de meilleures.
[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . Évalué à 8.
Je me suis contenté de relater les drama au sein du comité de normalisation. Et là, c'est bien la question de l'ABI qui a été la goutte d'eau qui a fait déborder le vase de Google. Et quand je dis la question de l'ABI, c'est bien la question de la priorité qui est donné respectivement à la performance et au maintien de l'ABI au sein du comité de normalisation.
Après, c'est juste l'aboutissement d'un long processus où Google n'a clairement pas la main sur sa destinée et c'est bien là le cœur du problème. Créer un nouveau langage est une solution pour eux. Et évidemment, ils ne vont pas faire un langage pourri, ils ont des contraintes industrielles qu'ils sont sans doute les seuls à avoir donc il faut que le langage soit top moumoute sur de nombreux points. Mais ce n'est que la conséquence de tout ce qu'il s'est passé avant. Ce que je veux dire, c'est qu'ils ne se sont pas levé un matin en se disant «tiens si on faisait un nouveau langage !», tout ce qu'il s'est passé ses dernières années dans le comité de normalisation C++ en est à l'origine.
[^] # Re: C'est moi ou c'est idiot ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7.
Ah moi j'avais compris qu'ils ont refait l'ABI à leur sauce mais ont donné un nouveau nom et mis un branding
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . Évalué à 10.
Cette histoire d'ABI, ça gonfle tout le monde. Par exemple, en C++20, il y a
std::jthreadqui apporte la possibilité d'arrêter le thread. Normalement, ça aurait dû être intégré dansstd::threadmais comme on ne pète pas l'ABI, on a maintenant 2 types pour les threads.Et puis il y a aussi des problèmes plus profond. Par exemple, passer un
std::unique_ptren paramètre ne permet pas de le passer dans un registre alors que par défaut, unstd::unique_ptr, c'est juste un pointeur dans une structure et que ça pourrait être passé via un registre.À la fin, ça fait plein de petits trucs qui font que Google en a eu marre. En particulier, ils ont proposé de mettre la performance en tête des priorité du comité de normalisation C++, ils ont été mis en minorité. Et puis il y a eu les propositions sur les modules, ils avaient fait une proposition très pragmatique, mais Microsoft a fait un peu du forcing et il y a eu conciliation qui a abouti à une horreur (d'ailleurs pas encore implémenté ni dans GCC, ni dans clang).
Je pense qu'au delà des questions de performances, il y a surtout des questions d'orientation de C++ qui échappent totalement à Google, parce que l'ISO, c'est compliqué et que le comité C++ de l'ISO, c'est encore plus compliqué. Google a essayé d'influer autant que possible mais ça n'a pas bien marché. Et vu les enjeux financiers, ils ont intérêt à faire un truc de leur côté, ils en ont les moyens et sur le long terme, c'est gagnant pour eux.
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 10. Dernière modification le 21 juillet 2022 à 18:21.
Ça peut aussi être une façon d'influencer le commité. La création par facebook de hiphop puis de hhmv a donné un coup de fouet à php qui s'est vachement repris ensuite pour php8.
S'ils obtiennent une perf intéressante par rapport à C++. Détrôner C++ de sa place de langage généraliste le plus performant peut faire changer beaucoup de choses.
Même sans parler de bras de fer, peut être que les gens du commité verront d'un autre œil le fait de garder l'ABI selon ce que ça apporte dans les faits. Bref ça peut devenir une preuve de concept.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 9.
+1, et on peut multiplier les exemples.
Comme Java, dont la seconde version de l'API de gestion temporelle est une quasi repompe de Joda Time, ou qui reprends à sa sauce des concepts déjà essayés dans Kotlin. Si Joda Time a disparu en pratique par réintroduction dans le standard, Kotlin lui continue à vivre sa vie en parallèle, donc là aussi différents futurs pour les modèles sont possibles.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . Évalué à 10.
Vu l'inertie du comité de normalisation, et vu qu'il y a déjà plein de gens en interne qui essaient tant bien que mal de faire pencher la balance du bon côté sans y arriver, je pense que ça ne va pas se passer. Il faudrait une révolution totale du processus de normalisation, en particulier sans doute sortir de l'ISO (avec les risques que ça peut occasionner). Personne n'y est prêt.
La stratégie de Carbon est sans doute la bonne contrairement à tous les C++ killers passés : garder une compatibilité très forte avec C++ en permettant d'utiliser C++ directement dans Carbon. Ça permet une migration incrémentale sans aucun problème.
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 6.
Je crois me souvenir que c'est pas la première fois que tu es très critique sur ce sujet. Je suis bien trop loin du c++ pour pouvoir juger, mais un comité de décision ISO aurait pu semblé être l'organisation parfaite pour éviter ce genre d'écueils. Privilégiant la qualité et la pérennité.
Si le comité prend des décisions qui sont aussi discutables tout en refusant de les remettre en question ensuite, ça ne va pas poser de gros problèmes pour la pérennité du langage d'après toi ? Indépendamment des choix de google.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par Julien Jorge (site web personnel) . Évalué à 7.
Le comité subit une sorte de pression pour mettre tout un tas de trucs dans la lib standard parce que tel autre langage a telle possibilité ou parce que tel truc est tendance. Du coup ils ont des propositions pour mettre du networking, une api de dessin 2D (abandonnée), des bases de données (abandonnée aussi il me semble), des ranges (i.e. de la composition d'algos) et 2000 autres trucs parce que Java/Python/Autre langage le fait. Ça devient très, très, très complexe.
À côté de cela on leur demande de livrer un nouveau standard tous les 3 ans parce qu'on a attendu c++0x trop longtemps et qu'on ne veut par subir ça à nouveau. Et puis on aimerait bien être moderne, comme tel autre langage jeune, beau, et tellement cool.
Du coup ils se retrouvent coincés entre livrer un truc bien pensé ou livrer pour qu'on leur lâche la jambe. Le résultat n'est pas toujours heureux.
À cela s'ajoute le fait qu'il s'agit de logiciel et donc fatalement toute décision est une mauvaise décision après un laps de temps suffisamment long.
Personnellement je pense que la lib standard doit être good enough comme on dit, justement parce qu'il n'y aura jamais une implémentation qui satisfait tout le monde. Si on veut aller dans le détail on a toujours la possibilité de prendre une lib à part.
Après pour ce qui est de l'ABI, est-ce vraiment une mauvaise chose que de vouloir éviter de casser l'existant ? Je n'ai pas trop d'avis là dessus.
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 7.
Personnellement je ne me prononce pas du tout là dessus. C'est probablement pas une bonne ou une mauvaise chose, mais un choix, une direction qu'ils veulent donner et c'est leur rôle.
Mais disons que si livrer un standard rapidement en s'interdisant de revoir leur copie semble vouer à produire des problèmes de plus en plus aberrants. Python nous a montré ce que donne les ruptures de compatibilité et c'est un traumatisme aujourd'hui pour beaucoup de développeurs de langage.
Il n'y a pas de tout noir ou tout blanc, mais je vois comme une contradiction l'idée de vouloir évoluer vite sans rompre la compatibilité. C'est amha un point qui fait la différence entre python et perl aujourd'hui.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par groumly . Évalué à 9. Dernière modification le 22 juillet 2022 à 21:20.
De mon expérience avec Swift (0 compat abi jusqu’à la version 4 ou 5), c’est très très très chiant. Ça veut dire que toutes tes dépendances doivent être rebuilt au grand minimum à chaque update du compilo. Et même avec ça, ça veut dire que toute l’équipe doit updated son compilo en même temps. Ce qui est compliqué sur un projet distribué. Ou alors tu passes ton temps à tout recompiler à chaque build, ce qui devient très vite chiant au quotidien, à plus forte raison en c++ vu les temps de builds. Ça a aussi vite fait de complexifier les builds CI et bouffer du temps pour pas grand chose. Surtout vu le merdier que sont les build tools en c++.
Dans le cas de Swift, l’effet c’est que très peu de projets sérieux se lançaient dans un framework en Swift. Une fois qu’Apple a déclaré l’abi stable, ça a ouvert les vannes.
On a beau aimer l’open source, le fait est que distribuer des binaires prebuilt est quand même plutôt pratique, au minimum, et obligatoire pour du code closed source, au pire. De ce que j’en voit, sortis de languages récents et relativement peu répandu, une abi stable est un peu la base de la base. Peter l’abi d’un coup me parait être un gros problème.
Les raisons de Google me paraissent plutôt justifiées. C++ était déjà un monstre de complexité y’a 20 ans. Ça n’a fait qu’empirer depuis. Vu leurs objectifs, ça me paraît raisonnable de faire ce qu’Apple à fait avec swift et objc: créer un language next gen de remplacement, en incorporant des ponts du nouveau vers l’ancien pour permettre une longue transition en douceur.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 2.
Go s'en affranchi et la plus part des langages de scripts je présume, je ne sais pas ce qu'il en est des langages à machines virtuelle comme java. Je sais que le format de la représentation binaire est versionné, mais je ne suis pas assez familiarisé avec ce qu'est l'abi pour savoir. Si je peux changer ma représentation interne d'une classe, ne pas recompiler ceux qui utilisent cette classe et tout de même linker avec c'est qu'il n'y a pas de problème d'abi ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . Évalué à 7.
Go n'a pas de problème d'ABI vu que Go compile tout en statique. Les problèmes d'ABI, c'est quand on fait des bibliothèques et que deux morceaux ont besoin de communiquer via un appel de fonction et doivent donc avoir la même représentation binaire des données qu'ils manipulent.
Quant au langage de script, par définition, ils ne produisent pas de binaire (je schématise), donc pas de problèmes d'ABI non plus.
[^] # Re: C'est moi ou c'est idiot ?
Posté par groumly . Évalué à 5.
Oui, tant que ça pete pas en vol non plus. Java est abi compatible aussi, un .class de 1993 tournera sans problème dans une appli écrite en 2022 en java 17 sans rien toucher.
Java (et actes associés donc kotlin aussi), swift/objc, c, .net aot ou jit, et un petit peu en c++ si tu plisses les yeux sont abi stable. Pas rust et go. Go essaye d’esquiver le problème en linkant tout en statique, mais je sais pas ce que ça donne en pratique pour la distribution de librairies?
Les languages de script ne sont pas distribués sous forme binaire, ce qui aide pas pour le b d’abi, donc le problème ne se pose pas pour eux.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: C'est moi ou c'est idiot ?
Posté par Julien Jorge (site web personnel) . Évalué à 6.
Ça ne suffit même pas :) Regardez par exemple cette belle lib que l'on va générer en deux versions :
On compile cela et on envoie le .so au client :
De son côté le client écrit ce programme :
Il compile ça et teste :
Tout va pour le mieux.
Le vendeur de
libfournit maintenant une nouvelle version de sa lib, la version 2, avec deux fois plus de champs danssomething.Compilé de la même façon, il envoie le .so au client qui remplace directement l'ancien fichier et relance son programme :
Et voilà, le programme se lance bien, il affiche n'importe quoi (la lib voit dans
something::bla valeur 32 qui est dans la pile côté client) et on voit que le client et la lib ne sont pas d'accord sur la taille desomething.La mise à jour de la lib n'est pas ABI compatible avec la version précédente et pourtant ça link bien. Sur cet exemple c'est bénin mais en pratique ça cause de sacrés problèmes. Et il ne suffit pas d'ajouter ou supprimer des champs pour causer des soucis, rien que changer l'ordre pose problème.
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 3.
Présenté comme ça je dirais que tout langage qui permet l'introspection a ce problème. Si je compte le nombre de méthodes d'un objet python, j'ai strictement le même problème.
Mais ça me gratte un peu parce que c'est pour moi un bug de l'utilisateur pas du langage ou de la bibliothèque.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par groumly . Évalué à 2.
Non, python va compter le même nombre de méthodes que tu soit dans l’objet ou à l’extérieur.
C++ voit ici une taille d’objet différent en fonction de si tu es dans la lib ou au call site.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: C'est moi ou c'est idiot ?
Posté par groumly . Évalué à 3.
Oui, c’est ce que j’impliquais par “tant que ça pete pas en vol non plus”. C’est juste que c’est long et chiant a expliquer, mais comme tu l’as fait, j’ai pas à le faire :)
Et sinon, rien à voir avec la choucroute, mais vendor, ca veut dire fournisseur, pas vendeur.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
De ce que je comprends de la spécification, Java est aussi beaucoup plus tolérant que C++ sur ce qu'on peut changer dans les binaires sans casser l'ABI.
Et malgré ça, la Sainte Rétrocompatibilité de Java (ou même de la seule JVM) – que l'on parle de l'ABI ou de l'API standard ici – n'est pas sans poser de problèmes.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 3.
Elle n'est pas si sainte que ça. Tu as eu plusieurs changements de compatibilité ces dernières années.
Rien de très méchant et tu as des discussions pour être encore plus disruptif.
Java n'est pas si rigoriste que ça
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
Même question que ci-dessus : est-ce que tu as des exemples ?
Je vois bien des problèmes de rétrocompatibilité (dans le sens : une vieille classe ne tourne plus sur une JVM récente) avec le passage de Java EE à Jakarta et le retrait de Nashorn.
Pour les modules et les sealed, je vois bien les problèmes de compatibilité mais je n'ai pas entendu parler de problèmes de _rétro_compatiblité au sens ci-dessus. Il y a bien des cas où tu es obligé d'ajouter des dépendances de modules d'API standard pour utiliser de vieilles classes dans un code récent qui utilise les modules, mais pour moi c'est un problème de compatibilité et pas de rétrocompatibilité, dans le sens où la vieille classe elle-même fonctionnera sans modification. Je n'ai pas non plus trouvé d'exemples après une recherche rapide ni n'en ait subi, donc si tu en as je prends.
Enfin et surtout, « sainte » ≠ « absolue » hein. Il y a des ruptures de compatibilité – il suffit d'aller sur les releases notes pour les voir, changez le numéro de version dans l'URL pour voir les autres, à partir de Java 10. Mais ça n'est que des changements dans les outils et options externes. Les rares changements d'API sont soit sur des API internes – je ne vais pas plaindre les gens dont le code a pété parce qu'ils utilisaient
sun.misc.BASE64Decodersoit des trucs fondamentalement pétés depuis longtemps, soit des problèmes de sécurité, comme les récentes protections sur la réflexion, qui a bien mis le bazar dans les codes qui fonctionnaient précisément à cause de ce manque de protection, comme au hasard certains mods Minecraft.Et surtout, je n'ai vu aucun changement d'ABI, ce qui est quand même le sujet d'origine.
Un truc qui me gonfle avec la gestion de la compatibilité de Java, c'est qu'il semble y avoir une horreur à déprécier officiellement des trucs malgré la présence de remplacements depuis des décennies. Aujourd'hui, mi-2022, tu peux écrire du code complet à base de
Vector,HashMap,Dateet autres objets qui ont des remplacements bien plus pratiques sans que le langage ne te sorte le moindre avertissement. Que ces antiquités soient conservées pour la compatibilité, OK, mais elles n'ont plus rien à faire dans un code actuel.C'est peut-être ça qui manque à un langage qui veut garder autant de rétrocompatibilité que possible : un moyen de marquer une sorte de soft deprecated, qui indique que la fonctionnalité va être conservée pour compatibilité mais ne devrait plus être utilisée dans du code moderne – avec un indicateur la nouvelle méthode. Je pense que ça aiderait pas mal à améliorer la qualité de code, en particulier de tous les projets faits dans des usines à code où les développeurs n'en ont pas grand-chose à faire de suivre les nouveautés du langage.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 3.
Ah non je n'ai pas dis que c'était en particulier des problèmes d'ABI.
Pour les modules, à partir de java11, tu dois déclarer tes modules à ouvrir à ouvrir tout puis à partir de java17 tu ne peux plus tout ouvrir il faut lister tous les modules au quel tu souhaite accéder. Pour moi si tu faisais :
avec java8 et qu'en mettant à jour java la commande tel quelle ne fonctionne plus c'est un problème de rétrocompatibilité. Que tu ajoute cette liste de modules dans le module info dans le jar ou via la ligne de commande ne change rien.
Pour les sealed, tous les enum sont sealed. J'ai découvert pour l'occasion que tu pouvais mock un enum avant (et qu'on avait un test qui s'en servait), c'est une (très) mauvaise idée amha, mais tu ne peux plus à partir de java17. Moi j'en ai aucun usage, mais je serais pas vraiment surpris qu'un outil s'en serve pour une raison ou une autre (même un spoke par exemple).
Je retrouve plus la référence mais en ajoutant une méthode sur une interface des collections ils ont cassé la compatibilité d'eclipse-collections. Je présume que ça n'est pas le seul cas où c'est arrivé (pour eclipse ou autre).
Mais du coup tu entends quoi par « sainte » ? Parce que non seulement ils cassent la compatibilité, mais en plus ils déprécient des parties (le plus connu c'est quand ils ont souhaité déprécier
sun.misc.Unsafe). Probablement pas autant que tu le souhaiterais, mais du coup je ne vois pas ce que tu entends par « sainte compatibilité ».Quel est le remplacement de HashMap ? Je viens de vérifier je ne vois pas dans le standard ce qui ces dernières versions auraient donné de quoi le déprécier.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
Dans ce cas pour moi on ne parle pas de la même chose. Je parle de la rétrocompatibilité des ABI et API uniquement, pas de la plateforme en entier.
On a jamais pu étendre un enum. Si un outil de test se servait d'une bidouille pour forcer quelque chose de normalement impossible (ici : créer une classe de mock qui étends l'enum) et que ça finit par péter, c'est pas de chance, mais pour moi c'est pas un problème de rétrocompatibilité : le comportement n'avait jamais été prévu ni officialisé.
Pour moi déprécier
sun.**n'est pas « casser la rétrocompatibilité », puisque Sun puis Oracle ont toujours dit que ces packages étaient à usage interne, ne faisaient pas partie de l'API et ne devaient pas être utilisés. D'ailleurs des programmes qui utilisaient ces classes ne fonctionnaient pas sur des JVM non-Sun/Oracle, à commencer par la JVM d'IBM.Le fait que Java n'hésite pas à faire des doublons d'API, mais surtout des montages compliqués, des tonnes de sucre syntaxique qui masquent des pièges et finissent par aboutir à des demi-solutions bancales et peu pratiques. Par exemple et sans réfléchir : tout le système de boxing/unboxing, le type erasure dans les generics, la (non) gestion des checked exceptions dans les lambda – qui en plus n'a pas de solution élégante dans l'API standard.
En fait il fallait lire
HashTable(qui a été remplacée parHashMapjustement).La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 3.
C'est un déplacement du problème pas une correction.
Sun comme Oracle ont très largement profité du fait que les gens avaient ces possibilités. Le succès de la plateforme n'aurait pas du tout était la même sans ça. Je trouve que prendre tous ces gens qui ont largement contribué à la plateforme de haut en leur disant que leurs usages "bof OSEF lol" est un manque de respect total.
Oui la plateforme a besoin pour évoluer de trancher certains usages, mais ça n'empêche pas de prendre en compte l'état réel de la plateforme et pas ce que ce serait dans un état imaginaire qui ne prendrait en compte que ce qui est spécifié/contractualisé.
Très basiquement retire toutes les bases de données de java (cassandra, elasticsearch, neo4j,…) ça va nettement impacter la plateforme. Même les membres d'OpenJDK l'ont entendu.
swing/awt était une fierté fut un temps (pas si lointain).
Les exceptions checkeds sont gérées d'une manière cohérente dans les lambdas et heureusement. Il y a déjà largement suffisamment de cas particulier lié aux lambdas pour ne pas ajouter ça. Une partie du reste est entrain d'être traités par différents sous projets d'OpenJDK.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par groumly . Évalué à 3.
Il dit pas osef, lol. Il dit que des classes clairement annoncées comme ne faisant pas partie du standard avec 0 garanties de maintenance ne peuvent pas être utilisée comme exemple de cassage d’api/abi. Tout comme je peux pas dire “le c++ casse les apis parce que qt a pété pleins de trucs avec le passage à qt5”.
Idem pour les enums.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 0.
Oui mais c'est ce que je dis tu ne peut pas les ignorer pour autant parce que ce sont des fonctionnalités qui constituent dans les faits une partie de la plateforme. Quelqu'un qui bosse là dedans qui construit un projet qu'il fourni gratuitement et dont l'écosystème bénéficie très clairement lui. Venir avec de gros sabot en disant « c'est pas dans notre contrat d'interface, donc va falloir vivre sans à partir de maintenant ». C'est non seulement arrêter net une dizaine de projets parmi les plus populaires de la plateforme, mais aussi donner un grand signal à toute la communauté que quelque soit ce que tu aura apporté, tu peux te faire dégager ton projet si tu ne rentre pas tout à fait dans ce qui a était contractualisé.
Encore une fois, les contributeurs d'OpenJDK ont tout à fait acté ce fait et ont abandonné leur objectif de retirer Unsafe tant qu'ils n'auront pas d'alternatives.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par groumly . Évalué à 2.
Honnêtement, tu craques complètement la dessus.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: C'est moi ou c'est idiot ?
Posté par groumly . Évalué à 4.
t’as des exemples concrets? Dans l’ensemble pour peter une abi en java, faut vraiment se lever tôt et faire des trucs très très bizarres. Le bytecode a un peu été conçu pour ça, et sun/oracle ont toujours refusé d’y toucher (ce qui donne des conneries genre un Integer boxé en int qui te pete une npe, parce que c’est juste du sucre syntaxique).
Oracle s’est même retrouvé bloqué après avoir spécifié leur algo de hash pour les hashmap, ce qui leur a causé des soucis avec des DoS à cause de collisions dans les requêtes http. ckyl avait expliqué en long en large et en travers le problème ici même. Ils tiennent la route avec leur api publique.
Les changement d’api/deprecation arrivent, mais dans l’ensemble, à moins d’aller taper dans les classes “privées”, ça continue à tourner. Après, oui, c’est facile de se tirer une balle dans la jambe et se peter une runtime exception avec des jars qui ne sont pas les bons, mais ça c’est plutôt un problème de gestion de dépendances touffu qu’un problème de compat abi/api.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: C'est moi ou c'est idiot ?
Posté par gouttegd . Évalué à 5.
Ben, euh, sur quatre programmes Java que j’utilise régulièrement :
Alors peut-être que ce ne sont que des exceptions et que je n’ai vraiment pas de bol à ne devoir utiliser que des programmes exceptionnels, mais en attendant, quand j’entends parler de la rétro-compatibilité de Java, je rigole jaune en pensant aux trois JRE différents (8, 11, et 17) que je suis obligé d’avoir sur ma machine…
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Je suis curieux, alors j'ai creusé un peu.
Dans les deux premiers cas, on est un peu sur des cas aux limites : l'ABI est compatible, l'API est compatible, mais quelque chose dans les outils et/ou la configuration externe fait que ça ne fonctionne plus. C'est clairement une rupture de compatibilité, mais à quel point c'est imputable à une non rétrocompatibilité de l'ABI ou de l'API de Java ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 3.
Virer une partie de la bibliothèque standard c'est clairement une rupture de rétrocompatibilité de l'API.
Le retrait de nashorn est une bonne nouvelle. Il était pas très à jour sur l'implémentation emscscript et on a aujourd'hui des solutions bien plus performantes comme graalvm polyglot
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
La question derrière ma remarque, c'est que je ne sais pas si Nashorn (ou Rhino) faisaient partie de l'API standard, ni si le tooling fait partie de l'API standard.
C'est une question ouverte, pas une affirmation, et je vois des arguments dans les deux sens.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est moi ou c'est idiot ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
J'utilisais Nashorn pour ma tribune/coinoin jb3 en Java. Je l'ai vu venir de loin le pétage de compatibilité, si j'avais souhaité continuer ce projet, j'aurais largement eu le temps de mettre à jour.
C'est vrai pour la plupart des changements en Java: ils préviennent longtemps à l'avance et les vieux jdks sont maintenus des années.
Le problème vient des projets qui sont incapables de prévoir une migration technologique ou une réduction de la dette technique.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: C'est moi ou c'est idiot ?
Posté par gouttegd . Évalué à 3.
De mémoire c’était à cause d’un plugin C++, le reasoner FaCT++, qui pour je ne sais quelle raison avait besoin d’une pile plus grande. Protégé lui-même et les reasoners écrit en pure Java (comme ELK ou HermiT) se satisfont très bien de la taille de la pile par défaut.
Voir quelque chose d’inhabituel et en émettre d’emblée des doutes sur la qualité du code sans rien savoir de l’historique et des raisons derrière… Mouais bof.
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 3.
Les ruptures de compatibilités n'ont rien d'incroyables non plus. Pour le coup java souffre plus d'une image que de faits. Même si tes projets l'affirme. Annoncer la bouche en fleur rester compatible uniquement avec java8 8 ans après c'est comme un projet qui te dit qu'il n'est compatible qu'avec python2.7 sauf qu'avec java tu n'a pas d'opérateur qui claque silencieusement, tu n'a pas tes chaines de caractères/tableaux d'octets qui changent de comportement silencieusement.
Pour être du sujet, je considère ça comme de la pure dette technique qu'y est procrastinées à outrance. Le monde n'est pas binaire entre soit c'est parfaitement compatible soit c'est infernal et les ruptures ne sont pas très douloureuses. Et oui mettre à jour sa version de java fait parti du langage comme quand tu choisi python ou lua et les choses ne vont pas s'améliorer avec le temps. release early, release often
s/release/update/ghttps://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par gouttegd . Évalué à 4.
Alors pour le coup, quand je lance un programme et qu’il crashe au démarrage, pour moi c’est un fait et pas une image. :p
Bienvenue dans le monde des projets académiques. Votre première mission, si vous l’acceptez, sera d’obtenir des financemements pour tenir ce programme à jour, en justifiant auprès des organismes de tutelles que vous n’allez ajouter aucune fonctionnalité, juste permettre au programme de continuer à fonctionner comme avant.
Je suis complètement d’accord avec ça. Mais du coup, quand j’entends quelqu’un vanter la rétro-compatibilité de Java en disant qu’un programme écrit il y a vingt ans peut toujours tourner sur un JRE moderne, on est d’accord que j’ai le droit de rire jaune ?
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 4.
Ça ne veut pas dire que c'est compliqué à corriger.
C'est un mauvais choix de plateforme. Tu as des tas de plateformes largement plus stable. Si tu écris ton projet en C89 tu pourra ne rien toucher tant que gcc/clang supporteront ce standard et il n'y a aucune planification à ma connaissance pour le retirer. C'est quelque chose à prendre en compte.
Oui (d'autant que du coup j'ai pas compris ce qu'il voulait dire par "saint"), je dis tout de même que ce n'est pas soit tout noir soit tout blanc.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par gouttegd . Évalué à 4.
Je ne crois pas, non.
Si tu ne veux un programme qui ne fonctionne qu’en mode console, peut-être.
Si tu veux un programme en mode graphique… Tu connais beaucoup de bibliothèques graphiques C ① multi-plateformes et ② qui n’ont pas cassé leur API au moins une fois au cours des vingt dernières années ?
Le choix de Java a permis d’avoir un programme dont le développement a commencé à la fin des années 1990 de tourner en mode graphique sous Windows, Mac OS, GNU/Linux (et à l’époque aussi Solaris, HP-UX, AIX, et quelques autres), et de continuer à tourner plus de vingt ans plus tard.
Si le prix à payer pour ça est de devoir continuer à utiliser Java8 (par ailleurs toujours officiellement maintenu, contrairement à Python2 par exemple) le temps de trouver les ressources pour porter ce qui doit l’être vers une version plus moderne, ben ça me semble un prix bien modique.
Certes, mais c’est loin d’être la seule chose à prendre en compte, et à mon sens pas la plus importante.
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . Évalué à 1.
C n'était qu'un exemple, mais des bibliothèques qui n'ont pas cassées ça se trouve oui, la première qui me vient à l'esprit c'est évidement Tcl/Tk. Mais c'est vraiment des gens qui ont choisi java pour swing ?
Pas moi adoptium fourni le JDK8 jusqu'en 2026, le JDK11 jusqu'en 2024, le JDK17 jusqu'en 2027, le prochain JDK en LTS sera le JDK21 qui sortira en 2023 et dont le support ira jusqu'à 2028.
L'absence de mise à jour de la plateforme c'est à minima plus de mise à jour de LTS comme du reste de la partie crypto. Et je ne te parle pas du support de plateforme comme les nouvelles d'Apple.
Donc ils vont faire quoi ? Attendre 2026 pour tenter tant bien que mal de faire une migration 13 versions ? Et c'est à ce moment là qu'ils vont rugir que vraiment la compatibilité de java c'est pas top ? À partir de là ils n'auront plus que des version dont le support restera 4 ans.
Si comme tu le dis c'est compliqué structurellement de faire des mises à jours de java ces 8 dernières années, ils vont vivre un enfer tout en sortant des versions potentiellement buguées et relativement loin de l'état de l'art de la plateforme qu'ils utilisent (parce que ça prends du temps d'utiliser correction les records, de profiter des threads légers, etc).
Ils font bien ce qu'ils veulent (d'autant que les perspectives en 2000 n'étaient pas celles d'aujourd'hui), je n'utilise pas leur logiciel, je ne connaît pas toute leur problématique et je serait très content pour eux si tout marche comme sur des roulettes, mais à mon humble avis la vie d'apparente insouciance risque fort dans une certaine douleur.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est moi ou c'est idiot ?
Posté par gouttegd . Évalué à 5.
Ils sont au courant de la nécessité de migrer, merci pour eux Monsieur Yakafocon.
La migration a déjà commencé sur des branches dédiées, mais ce n’est pas (encore) prêt à être intégré à la branche principale, notamment parce que ça n’a pas encore été suffisamment testé.
Tu ne les as pas entendu se plaindre de la compatibilité de Java, que je sache ?
Je ne m’en suis pas plaint non plus d’ailleurs : quelqu’un a demandé des examples concrets de programmes cassés par l’évolution de Java au cours du temps, j’en ai donné, c’est tout. Non pas parce pour me plaindre que Java c’est de la merde pas rétrocompatible, mais pour souligner que sa rétrocompatibilité n’a rien d’exceptionnel, en réponse à ceux qui le prétendaient (ce qui est ridicule : Java a des avantages bien réels, nul besoin d’inventer des avantages fantaisistes).
C’est ça, oui, là pour l’instant ils se tournent les pouces en se disant « bouarf, on s’en occupera plus tard, tranquille ».
[^] # Re: C'est moi ou c'est idiot ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Le problème de la Sainte Rétrocompatibilité en Java, c'est que les gens la voudraient Divine.
Hors le douzième commandement des développeurs est Tu honoreras ton runtime et tes frameworks, tu suivras leurs releases et leurs patchs afin d'avoir une longue vie cyber.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: C'est moi ou c'est idiot ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
En Go, on distribue des sources, pas des binaires.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: C'est moi ou c'est idiot ?
Posté par groumly . Évalué à 2.
C’est ce que je me disais. Tout recompiler à chaque fois, ça resoud des problèmes, mais ça en introduit d’autres aussi. Et surtout, ça devient très compliqué pour ceux qui ne font pas l’open source.
Je veux bien croire que ça marche très bien pour le marché de go, mais ça n’en fait pas une solution universelle.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: C'est moi ou c'est idiot ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Les gens qui ne font pas de l'opensource, je déteste ces types.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: C'est moi ou c'est idiot ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Plus sérieusement, il y a 3 approches en Go pour partager du code, l'une d'elle est bien des bibliothèques partagées:
https://eli.thegreenplace.net/2021/plugins-in-go/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . Évalué à 10.
Oui, ça pose des problèmes et ça en pose de plus en plus. Je vais citer la FAQ de Carbon : «C++'s process is oriented around standardization rather than design». Et je pense qu'ils ont entièrement raison. Pendant longtemps, l'usage, c'était de standardiser les expériences qui marchaient bien. Mais récemment deux exemples ont montré que ce n'est plus le cas.
Premièrement il y a les modules. La proposition au départ était assez simple : se sortir du modèle d'inclusion de texte basique pour aller vers un vrai système de dépendances. L'idée était d'étendre les entêtes précompilés (qui existent depuis des années), les booster un peu et partir sur des bases saines. Avec comme effet de bord que ça pouvait accélérer la compilation. C'était aussi l'occasion de se défaire d'une partie du préprocesseur (but de long terme dans C++ depuis quasiment sa naissance). Il y a eu plusieurs propositions concurrentes (celle de Google et celle de MS), chacune à peu près implémentée (respectivement dans clang et MSVC) mais assez incompatible dans l'idée. Notamment la question du préprocesseur dans tout ça : fallait-il permettre d'exporter des macros ou pas ? ou d'autres questions tout aussi farfelues. Il y a eu d'âpres discussions pour arriver à un consensus et une proposition commune qui reprenaient les pires idées des deux autres propositions. Et au final, on aboutit à une infamie. Parce que personne n'arrive à l'implémenter (MSVC est le plus avancé sur le sujet mais d'après ceux qui l'utilisent, même des exemples simple provoque des crash du compilateur), GCC y travaille mais c'est compliqué, et clang est au point mort. Là, on a eu aucun retour d'expérience avant de standardiser un truc tout bancal. Mais comme le dit Julien Jorge, le comité était sous pression, il avait mis cet objectif dans C++20 donc il fallait que ça sorte dans C++20. Et du coup, ben voilà où on en est, on va sortir C++23 et on ne sait toujours pas utiliser les modules. Parce qu'au delà du compilateur, il faut du support au niveau des outils de build pour que ça fonctionne correctement, et donc (heureusement), ils sont en train de s'entendre pour avoir un format commun d'échange d'information mais c'est pas encore au point. Et puis à la fin, ça n'accélérera pas la compilation puisqu'avec la dépendances entre modules, il faut maintenant compiler les trucs les uns après les autres (ça revient à dérouler un DAG), alors qu'avec des fichiers source des des entêtes, on peut tout compiler en parallèle sans problème (
make -j10). Bref, un crash industriel qui finira sans doute dans l'oubli.Deuxième exemple, le réseau. Moi, contrairement à Julien Jorge, je suis pour qu'il y ait plein de choses dans la bibliothèque standard. Mais en particulier, j'aimerais qu'il y ait plus de choses pour l'abstraction du système. Depuis C++11, on a eu la gestion du système de fichier (
std::filesystem), la gestion des threads, la gestion des horloges. On va bientôt avoir la gestion des dates. Bref, tout ça pour moi, ça va dans le bon sens, c'est-à-dire qu'il n'y a rien de bien nouveau là dedans, c'est juste avoir une jolie interface commune à tous les systèmes. Mais il manque des morceaux et notamment le réseau. Or, en matière de réseau en C++, il y a une bibliothèque qui écrase le marché, c'est ASIO (qui est aussi présente dans Boost). Des milliers d'utilisateurs dans tout un tas de contexte, des années de maturation. Le candidat idéal pour une standardisation ! Et bien non, ça n'aura pas lieu. Pourquoi ? Parce que certains huluberlus trouvaient que le modèle de concurrence d'ASIO n'était pas top moumoute. Certains ont proposé de standardiser uniquement les trucs de bases genre socket pour TCP et UDP, résolution de nom, et basta. Mais non, le comité ne voulait pas parce que vous comprenez ma bonne dame, de nos jours toutes les applications réseaux ont besoin d'être parallèle pour gérer des millions de connexions à la secondes et qu'en plus, on veut du SSL par défaut. Donc, on a mis ASIO en attente pour gérer ce qui s'appelle «Executor» et qui est en fait l'introduction d'un modèle de concurrence. Sauf que là, pour le coup, je pense que ça n'a rien à foutre dans la bibliothèque standard un modèle de concurrence. Mais en prime, ils ont trouvé le moyen d'inventer un nouveau modèle (plutôt que de standardiser des trucs déjà existant), à peine testé, et surtout largement incompatible avec la manière dont ASIO fonctionne. Encore un crash industriel en perspective.On pourrait aussi parler d'une tentative d'introduire une partie audio. Le gars qui a fait la proposition disait en substance : «bon, toutes les API de base se ressemblent, ça consiste à envoyer des données régulièrement à un périphérique audio, il n'y a aucune innovation de ce côté donc on pourrait standardiser ça» (l'équivalent de l'API audio dans la SDL de base typiquement). Sauf que derrière, des spécialistes sont arrivés, ont flingué le truc en disant que ça ne gérait pas le temps réel, et bla bla. Fin de la discussion.
Donc, on va continuer à réinventer des couches d'abstractions pour l'audio et le réseau parce que le comité ne se soucie pas de design d'API simple et efficace qui pourrait servir à 95% des gens mais se soucie de normaliser des trucs, peu importe ce que c'est.
std::threadc'est pas fait pour ceux qui font du parallélisme de pointe (genre HPC) qui auront leurs propres solutions, mais on s'en fout parce que les 95% d'usages restant sont couverts. De même,std::vector, c'est un tableau dynamique de base qui sert 95% des usages, mais dans le jeu vidéo AAA où ils ont besoin d'avoir une maîtrise très fine (et aussi un peu de NIH), ils réimplémentent les tableaux dynamiques. De nos jours, le comité souhaitent que les trucs standardisés puissent être utilisé par les spécialistes et donc on monte des usines à gaz et au final, on se retrouve avec de la merde que personne ne peut utiliser parce que c'est trop compliqué (coucou les coroutines).Donc pour revenir à la question, oui ça pose problème à force. Parce que le problème orthogonal, c'est qu'on n'a pas de bon gestionnaire de paquets pour C++ (à l'instar d'un cargo pour Rust par exemple, et on pourrait d'ailleurs citer tous les autres langages en exemple), et donc on est encore condamné à bricoler suivant les systèmes (gestionnaire de paquets de la distrib dans Linux, avec les limites que ça peut avoir / vcpkg sous Windows) si on veut pouvoir tirer des fonctionnalités de base de bibliothèques externes à la bibliothèque standard.
Personnellement, je suis resté à C++17, parce que c'était la fin du cycle commencé en C++11 et que c'est suffisamment mature. Pour la suite, j'attends de voir ce qu'il va se passer, que ce soit du côté de C++ ou du côté de Carbon. Rendez-vous dans quelques années.
[^] # Re: C'est moi ou c'est idiot ?
Posté par Anthony Jaguenaud . Évalué à 3.
Alors pour moi, ça c’est un problème API, pas ABI. Ai-je raté un truc ?
[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . Évalué à 6.
Non, ce n'est pas que de l'API. Si tu changes la représentation interne de ta classe, tu changes l'ABI. Et dans ce cas, tu es obligé, pour gérer la nouvelle fonctionnalité, de changer l'intérieur de ta classe.
Si tu compiles une bibliothèque A avec l'ancien API et une bibliothèque B avec la nouvelle, elles ne pourront pas communiquer avec ce type (au mieux) ou ça va crasher sévèrement (au pire) parce que la représentation aura changé.
[^] # Re: C'est moi ou c'est idiot ?
Posté par Gof (site web personnel) . Évalué à 2.
Mais dans ce cas, il n'y a pas besoin de changer la représentation interne de std::thread. Si j'ai bien compris la différence c'est juste l'appel a join() dans le destructeur. Donc c'est un changement d'API, pas d'ABI.
(Les changements d'ABI dont on parle sont ceux qui cassent les applications qui mélangent des objets compilé avec des versions différentes du compilateur, mais qui ne cassent pas les ancien programmes tant qu'on recompile le tout)
[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . Évalué à 3.
Tu as besoin de changer la représentation pour pouvoir arrêter le thread de manière anticipée. D'ailleurs, je viens d'aller voir dans la libstdc++ et
std::jthreadest implémenté avec unstd::threadet un objetstd::stop_sourcesupplémentaire. Si on avait pu changer l'ABI, on aurait mis cet objet directement dansstd::thread.[^] # Re: C'est moi ou c'est idiot ?
Posté par M . Évalué à 4.
Si le c++ expose les structures interne, c'est un peu moisi.
En C fopen retourne un pointeur sur l'objet interne. On peut changer autant que l'on veut la partie interne sans casser l'ABI. Et même en théorie changer de libc (ou overider) sans recompiler.
[^] # Re: C'est moi ou c'est idiot ?
Posté par Julien Jorge (site web personnel) . Évalué à 2.
Quid de
struct tm, résultat degmtime()? Il n'y a pas moyen de changer les champs là dedans sans casser l'ABI. Il faut que le code client et la lib soient d'accord sur la composition de la donnée.[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . Évalué à 5.
It's not a bug, it's a feature! Le fait de n'exposer que des pointeurs force (quasiment) à faire des allocations dans le tas (via
malloctypiquement). Exposer les structures internes, ça permet de ne pas faire d'allocation s'il n'y a pas besoin d'en faire. Par exemple, si je fais une classeVec2avec deuxdouble:xety, je n'ai pas envie d'allouer 128 bits à chaque fois que je crée unVec2, j'ai envie de pouvoir les manipuler directement, sans allocation, de pouvoir faire des additions sans allocation (ce que C++ permet), etc. Et ça, tu ne peux le faire que si tu exposes les structures internes.[^] # Re: C'est moi ou c'est idiot ?
Posté par Colin Pitrat (site web personnel) . Évalué à 3. Dernière modification le 21 juillet 2022 à 22:05.
D'après ce que j'ai compris, le journal raccourci pas mal au point de fausser les choses. Carbon est un langage different, ayant pour objectif d'être plus safe et plus facile que le C++ mais aussi performant. Une alternative à Rust du coup, un peu moins safe mais aussi moins compliqué à utiliser.
La compatibilité avec le C++ est aussi un point important mais là j'aimerais bien voir comment ils y arrivent.
Bon après, c'est difficile de savoir ce qui est avéré et ce qui est spéculation dans tout ça.
[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . Évalué à 8.
«fausser les choses», tu y vas fort. Pour l'instant, on ne sait pas ce qu'est Carbon vu qu'il n'y a que des documents de design où il est écrit partout «TODO». Donc, je me suis bien gardé d'en dire davantage.
Ils ne promettent pas d'être forcément beaucoup plus safe (notamment pas au niveau de Rust), seulement un petit peu. Ils ne promettent pas d'être plus performant, mais de faire au moins aussi bien que C++. Bref, pour l'instant, il n'y a que des promesses et pas vraiment de concret. Donc attendons de voir. D'après la roadmap, la version 1.0 est prévu pour 2024-2025.
# C--
Posté par harlock974 . Évalué à 10.
Si ils ont besoin d'un C++ performant, il n'ont qu'a utiliser C, comme tout le monde…
# Respect de l'ABI
Posté par David Demelier (site web personnel) . Évalué à 5.
Je comprends pas ce drama autour du respect de l'ABI. Linux est un système où on recompile les logiciels à chaque nouvelle version de la distribution. Linux n'a pas non plus un respect de sa propre API ni ABI (pas pour rien qu'on a mis en place dkms) du coup les modules doivent être recompilés tout le temps aussi.
D'une manière générale avec la gestion des SONAME on s'en sort bien depuis plusieurs décénnies.
Si l'argument est « oui mais si je compile mon application propriétaire d'entreprise sur ma Red Hat 6 je veux qu'elle puisse toujours fonctionner sur ma Red Hat 9 » ce à quoi je répondrais déjà non. Si tu prends le temps de migrer ton système vers 3 version majeures de ton OS, alors tu peux prendre le temps de recompiler ton application. Je tourne notre propre dépôt de paquets Alpine Linux et je m'occupe de recompiler nos applications à chaque mise à jour majeure du système. Avec quelques scripts shell maison ma tâche est plutôt simple.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Respect de l'ABI
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Côté application, le concept même de DLL/SO est destiné à mourir: on n'a jamais trouvé et on ne trouvera sans doute jamais de bonne solution au dll hell, faire une ABI stable est atrocement difficile…
Ce n'est pas pour rien que les langages récents (Go, Rust) permettent facilement de générer un exécutable avec tout lié en statique.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Respect de l'ABI
Posté par Zenitram (site web personnel) . Évalué à 1.
On a des solutions (numéroter les noms de fichier, numéroter les noms de fonctions…), c'est surtout un manque de volonté de travailler ensemble qui pèche, bref le problème n'est pas la technique mais l'humain (comme avoir deb et rpm sous Linux).
[^] # Re: Respect de l'ABI
Posté par David Demelier (site web personnel) . Évalué à 10.
Exactement, comme je l'avais expliqué avec le SONAME des bibliothèques dynamiques. Globalement ça marche déjà bien mais les gens voulaient pouvoir mixer davantage les versions de bibliothèques (exemple avoir x fois Qt, Gtk, SDL, etc) pour faire tourner des versions différentes des applications.
En gros, répondre à la plainte de « je suis sous cette distro (exemple debian), j'ai la version 1.2 de la bibliothèque mais il me faudrait la version 1.9 pour compiler ton projet. ».
Du coup, on a copié microsoft windows : on embarque dorénavant toutes les bibliothèques directement dans les flatpak/snaps.
Le linkage statique n'est pas la solution. Cette fois ci son cauchemar n'est pas le DLL hell mais le security update hell :) (et je parle pas des soucis de licence via le linkage statique).
Bref, si tout le monde avait correctement versionné les bibliothèques (comme gtk, qt) on aurait aucun problème à avoir une version (ou plus) sur le même système et rendre tout le monde content.
C'est pourtant assez simple :
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Respect de l'ABI
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
La solution humaine, c'est d'abandonner le concept au profit du vendoring et du static link.
C'est comme le social, l'écologie et l'humanisme: on pourrait vivre égaux, dans le respect de la nature et de chacun, mais les solutions choisies par la majorité sont plutôt de voter à droite, de cramer toutes les ressources et de se détester les uns les autres.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Respect de l'ABI
Posté par rewind (Mastodon) . Évalué à 8.
Je ne dirais pas que c'est difficile. Il y a deux solutions actuellement : la première est celle que tu indiques à savoir tout compiler en statique. La seconde qui est encore beaucoup utilisée est de faire une API C en utilisant au maximum des structures dont l'implémentation est cachée. Avec ça, tu n'as aucun souci vu que l'ABI C est très stable, bien connue, assez simple à comprendre et qu'en prime, ça s'interface avec tous les langages de la Terre.
[^] # Re: Respect de l'ABI
Posté par rewind (Mastodon) . Évalué à 8.
Même si tu recompiles le monde entier, à un moment tu as quand même besoin de stabilité. D'ailleurs dans le noyau Linux, il y a aussi une garantie d'ABI stable sur certaines interfaces, ce n'est pas pour rien.
Au moment du passage à C++11, GCC a été obligé de changer son implémentation de
std::stringpour pouvoir être conforme au standard. Ça a été long et douloureux ce petit changement. Notamment dans les distributions, on se retrouvait parfois à ne pas pouvoir compiler un logiciel parce que la bibliothèque qu'on utilisait avait été compilé avec l'ancien version destd::string. Il fallait jongler avec des options du compilateur, c'était pénible. Ça s'est résorbé avec le temps mais je pense que sur certains vieux systèmes où on met à jour la chaîne de compilation, on doit encore trouver ce genre de mésaventure. Et pourtant, ça fait 7 ans. Voir la page du manuel de GCC.[^] # Re: Respect de l'ABI
Posté par Clément V . Évalué à 6.
L'API/ABI interne du noyau est instable, mais entre le noyau et l'utilisateur c'est au contraire très très stable. Tu recompiles seulement les modules quand tu changes de noyau, jamais les applications.
[^] # Re: Respect de l'ABI
Posté par Gof (site web personnel) . Évalué à 6.
Alors déjà non, certaines distributions ne recompile pas le monde a chaque mise a jour du compilateur.
Ensuite le C++ est vachement utilisé dans l'industrie du propriétaire, là où il n'est pas rare d'avoir des binaires précompilés propriétaires dont on a pas les sources.
Et puis les SONAME ne marche pas avec des dépenses transitives. (libQt depends the libstdcpp.so.42, mais ton application veux être compilé avec un nouveau compilo qui utilise libstdcpp.so.43, et tu ne peux pas mélanger les deux)
[^] # Re: Respect de l'ABI
Posté par FantastIX . Évalué à 3. Dernière modification le 09 août 2022 à 16:22.
Comme on peut s'y attendre, c'est pas si simple. Sans répondre totalement à la question, il y a cette analyse 📽 de Jason Turner, un conférencier récurrent de CPPCON. Je l'ai visionnée l'an dernier, c'est très instructif.
# Fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 5. Dernière modification le 22 juillet 2022 à 14:01.
Si on veut de la perf, on fait du Fortran. En Fortran, l'ABI est cassé à chaque version !
# Langage Carbon
Posté par vitanix . Évalué à 10.
J'ai lu un peu la doc du langage ici. Voici un exemple de code :
Au niveau des différence que j'ai trouvé :
- les littéraux numériques ne sont pas en octal, et ils peuvent être de taille 128 bit et 256 bit.
- il y a un type String et un type StringView avec un StringView en lecture seule
- il existe le type tuple, un type slice
- il y a un opérateur move pour déplacer une valeur. Dans l'instruction :
apres cette instruction, y est dans un état indéfini.
- il y a une instruction return var. L'idée c'est de déclarer une variable comme type de retour, et quand on appel return var, ça va retourner cette valeur.
Le langage n'est pas fini, et il y a des parties qui sont en cours de conception.
[^] # Re: Langage Carbon
Posté par rewind (Mastodon) . Évalué à 7.
Il n'y a pas de pointeur nul !
[^] # Re: Langage Carbon
Posté par groumly . Évalué à 8.
Tous les pointeurs sont super doués! 💪
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Le nom ne m'arrange pas trop...
Posté par windu.2b . Évalué à 3.
Je sais bien que le carbone est dans l'air (AH AH) du temps, mais ils auraient pu trouver un autre nom : Carbon est le nom d'une excellente librairie en PHP de gestion des dates et du temps.
[^] # Re: Le nom ne m'arrange pas trop...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 8.
Ils vont se différencier par leur numéro d'isotope…?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Le nom ne m'arrange pas trop...
Posté par Lutin . Évalué à 3.
Comme Go, Rust ou Perl, une fois sur deux une recherche va nous renvoyer des résultats qui n'ont rien à voir.
[^] # Re: Le nom ne m'arrange pas trop...
Posté par claudex . Évalué à 4.
Ça marche souvent avec "golang" et "rustlang".
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le nom ne m'arrange pas trop...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
Alors pardon mais Carbon c'est surtout le framework qui a permis de migrer en douceur de Mac OS 8 vers Mac OS X en pouvant cibler ces 2 systèmes (complètement différents malgré les apparences) avec le même code source.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.