Posté par groumly .
En réponse au journal Google forke C++.
Évalué à 9.
Dernière modification le 22 juillet 2022 à 21:20.
Après pour ce qui est de l'ABI, est-ce vraiment une mauvaise chose que de vouloir éviter de casser l'existant ?
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.
[^] # Re: C'est moi ou c'est idiot ?
Posté par groumly . En réponse au journal Google forke C++. É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.