anaseto a écrit 2229 commentaires

Ce que tu dis revient juste à étendre la sémantique de la division pour donner un comportement différent à la division par zéro. Au lieu d'un crash, on aurait une valeur particulière, c'est-à-dire grosso-modo la solution numéro 2, sauf qu'en version explicite (écriture explicite de la condition) et potentiellement plus flexible (genre retourner autre chose que zéro si le dénominateur est nul, mais je vois pas trop à quoi ça servirait).

Le compilateur ne pourra essentiellement optimiser que les cas trivaux par propagation de constantes et élimination/réécriture de sous-expressions communes : le plus souvent, la division sera impossible à optimiser. Enlever ces vérifications est un problème indécidable en général et je ne pense pas qu'il y ait d'heuristique efficace pour cela dans un compilateur actuel. Au mieux on peut espérer que le prédicteur de branchement du CPU fera pas trop mal les choses.

La première solution est impossible dans un langage généraliste, car dans ces langages, c'est un problème indécidable.

La deuxième solution permet juste de cacher un bug (donc conduisant à un comportement imprévu, potentiellement une faille) tout en ayant un coût en performances (à mon avis pas négligeable, mais à vérifier). Choix favorisant la disponibilité (faire quelque chose à tout prix) contre la correction et les performances. Peut-être raisonnable pour le web.

La troisième, c'est la même qu'un panic avec recover en Go : a priori utilisé uniquement en cas d'erreur vraiment exceptionnelle (le plus souvent provenant d'une erreur de programmation) pour un système où la disponibilité est plus importante que la correction. C'est a priori rattrapé assez près du main, dans le but de relancer le programme ou un sous-système de celui-ci, et pas à chaque division par zéro (autrement le code deviendrait imbitable). Du coup, ça rentre bien dans le cadre des utilisations potentielles de panic/recover. La différence pratique, c'est qu'en Go il y a une distinction au niveau langage entre une situation d'exception (issue d'une erreur de programmation) et une simple erreur à laquelle il est possible de réagir plus spécifiquement.

Je ne comprends pas ton besoin. Comment tu veux éviter au niveau du langage que quelqu'un qui comme Henry n'a pas compris comment l'utiliser ni même programmer en général fasse faire n'importe quoi à un programme ? On ne parle pas ici d'erreur subtile à la C difficile à voir au premier coup d'œil, mais d'erreur de débutant en programmation.

Je ne vois par ailleurs pas en quoi Java le résoudrais : c'est pas parce que les exceptions contrôlées existent qu'il n'est pas possible pour Henry d'écrire du code qui lance des exceptions non contrôlées, à commencer par une division par zéro. Et puis Henry peut te faire des trucs pire, comme une boucle infinie, une faille de sécurité ou t'effacer ton $HOME.

Ton besoin « simple » ne me semble pas être résoluble dans un langage généraliste au niveau du langage lui-même. La solution classique pour éviter ce genre de soucis, c'est de reviewer le code d'Henry avant de le merger. Je ne vois pas comment faire autrement.

Des exceptions contrôlées comme en Java?

Ça ce serait en tant que moyen de gestion d'erreurs. En Go le panic n'est pas utilisé pour cela.

Je ne dis pas que l'approche Go avec retours multiples pour la gestion des erreurs est meilleure ou non (c'est assez subjectif, vu le manque de consensus sur le sujet), mais c'est là une autre question. Étant donné le choix fait dans Go pour la gestion d'erreurs, les exceptions contrôlées, une solution complètement différente, conduiraient à une situation plutôt difficile où il faut considérer deux méthodes de gestion d'erreurs lorsqu'on lit du code.

Cherche panic dans la doc de https://golang.google.cn/pkg/bufio/ : bonjour pour savoir comment faire un code fiable avec des comportements comme Scan panics if the split function returns too many empty tokens without advancing the input.

Tel que je comprends la chose, un panic là signifie que la fonction de splitage qu'on a donné est incorrecte. Ça me semble être juste une façon ad hoc d'ajouter une détection de boucle infinie dans Scan (l'heuristique étant 100 itérations sans avancement : ça devrait écarter tous les cas licites en pratique, je ne vois pas trop pourquoi on pourrait avoir un avancement de zéro plus de une ou deux fois). Ce genre de cas d'utilisation de panic est extrêmement rare dans Go.

Je préférais moins subtil et plus fiable du type std::vector.

C'est moins subtil, oui. Fiable, les deux le sont, je dirais.

L'utilisation de slices permet souvent de gérer une fenêtre et donc d'avoir un code avec des indices plus simples (sans gérer d'offsets) et appliquer des fonctions facilement à une partie de tableau seulement. Perso je trouve que la courbe d'apprentissage vaut le coup, mais c'est subjectif. D'habitude on reproche à Go de trop sacrifier en expressivité en vue d'être simple : là on a une exception où un choix a été fait qui complique peut-être un peu la courbe d'apprentissage pour plus d'expressivité :-)

Il y a tellement de trucs mal foutus dans Go (l'absence de généricité, les paniques, les variables ombragés, les rondelles de tableaux…)

Que verrais-tu à la place des panics ? C'est une forme minimale d'exceptions pour les cas vraiment exceptionnels (correspondant à des erreurs de programmation en général : recover n'est utilisé que dans de rares occasions) qu'il est difficile d'éviter : Rust fait un panic aussi par exemple lors d'un accès tableau mal indexé.

Les variables ombragées peuvent en effet parfois conduire à une surprise, c'est indéniable, mais je pense que le choix a été fait en connaissance de cause. Elles sont parfois utiles sur le moment lors de refactoring (ça évite de renommer inutilement des variables) ou juste parce qu'utiliser une variable avec le même nom dans un bloc est intuitif (genre err) et qu'utiliser de la mutation plutôt que du shadowing aurait été encore plus problématique. Cela dit, il y a des outils d'analyse statique qui détectent les variables ombragées, et certains cas typiques sont même détectés de base (par exemple si variable non utilisée, ou variable de retour ombragée avant return).

Pour ce qui est des rondelles de tableau, je ne suis pas sûr de savoir à quoi tu fais référence ;-) Si tu fais référence aux slices, je trouve au contraire que c'est une partie très réussie du langage, donc je serais curieux de savoir ce que tu leur reproches ? Ils ont un côté un peu subtil par rapport à de simples tableaux, mais le concept est puissant et s'inspire à la fois des classiques tableaux dynamiques à la Python ou Perl ainsi de ce que l'on retrouve (sous une forme n-dimensionnelle plus complexe) dans les bibliothèques numériques pour d'autres langages qui permettent de sélectionner des fenêtres/slices.

C'est plutôt qu'ils n'ont pas réussi à le faire dès le début?

Oui, c'est juste que la difficulté n'était pas tant d'ajouter la généricité en soi que le fait de l'ajouter tout en conservant le reste du design qu'ils considéraient prioritaire. Ajouter de la généricité de façon peu orthogonale ou en modifiant certaines parties du langage aurait sans doute été plus facile et faisable avant, mais pas forcément une bonne idée.

Ça a été la même chose en Java avec le même pattern de mauvaise foi mon langage est tellement génial que tu n'en as pas besoin qui se transforme bon ok on va le faire pour vous faire plaisir avant de devenir notre langage est maintenant le meilleur grâce à la généricité !.

Les créateurs de Go ne me donnent pas l'impression de changer de discours comme ça, suivant comme ça les arrange. Mais, oui, il y a aura toujours du monde pour tenir ce genre de discours (un langage populaire attire l'argent, et là où il y a de l'argent se faufilent toujours des charlatans).

Je ne l'avais pas posté puisque cet article consensuel n'a suscité aucune réaction dans la communauté Go

La communauté Go abrite moins de curieux et passionnés des langages que la communauté Rust, donc ce genre d'articles reçoit moins d'intérêt, surtout vu leur caractère répétitif.

L'article est peut-être consensuel, mais globalement résume l'essentiel. En d'autres termes, bien que parfois les deux peuvent s'appliquer, il n'y a pas de compétition significative entre Rust et Go en pratique. Les articles non consensuels sur le sujet ont souvent tendance à se démener à propos de détails sortis de contexte sans en évaluer l'impact réel en pratique.

Pour ce qui est de la généricité, pas mal de monde est d'accord qu'il existe un certain pourcentage d'applications (peut-être autour de 10% ou 20% ?) qui en bénéficieraient suffisamment pour que ça vaille la peine. Ça concerne suffisamment de monde pour que les développeurs aient décidé d'ajouter ça d'ici une ou deux versions, mais pas assez de monde pour qu'ils l'aient fait dès le départ ni pour qu'ils ajoutent une généricité aussi puissante et complexe que dans d'autres langages.

Dans la plupart des applications, les mécanismes déjà présents de réutilisation (interfaces), suffisent. Pas étonnant qu'un certain nombre de programmeurs Go ne soit pas très excité et n'y voit pas de quoi en faire un fromage. Pour ce type de programmeur Go, qu'on lui dise que son langage est pas bien, car il est pas assez générique (ou autre), ça va le surprendre, il va pas savoir quoi dire. Ça doit se ressentir un peu comme si on te reproche de ne pas automatiser complètement l'installation de ta distrib sur tes machines chez toi; tu répondras que ça va, tu fais pas ça souvent, donc t'as pas envie de te casser la tête et tu le fais deux fois (je parie que même des sysadmins ne prennent pas toujours la peine d'automatiser chez eux ce genre de choses).

Comme pour toute fonctionnalité, chacun a tendance à en évaluer l'intérêt du point de vue des choses qu'il fait, puis attacher des émotions par dessus ça, puis se sentir obligé de les justifier dans l'abstrait. Ça a beau être très consensuel et banal comme explication, je trouve honnêtement que c'est surtout ça qui génère tous ces articles Go vs Rust.

Il est Intéressant de lire l'accueil qui lui est fait sur Reddit:

Pas forcément, le sous-reddit en question est celui de Rust, donc les commentaires risquent de refléter une vision du langage Go non fondée sur une expérience typique. Bien qu'il y ait du monde qui utilise vraiment les deux langages, les plus vocaux sont souvent ceux qui utilisent surtout l'un des deux et ont construit une préférence forte pour l'un en fonction de leurs besoins.

En particulier, contrairement à Rust, l'usage d'unsafe en Go est extrêmement rare (en dehors des gens qui écrivent des bindings), donc le commentaire auquel tu fais référence n'a aucun impact statistique. Son côté sarcastique est gratuit : ça illustre juste que son auteur a compris que Go n'est pas Rust et n'a pas pu supporter le choc de cette révélation. Le problème (d'ergonomie) soulevé affecte une partie du langage rarement utilisée et est donc sans aucun impact du point de vue de la courbe d'apprentissage du langage. On peut faire du Go pendant des années sans être confronté à cela, c'est même de loin le cas le plus fréquent.

J'ai déjà vu ce site mentionné une ou deux fois. C'est trop sarcastique et sorti de contexte pour ce qui est du contenu non technique (dont les citations), et bien que l'analyse de la partie technique soit plus sérieuse (pour ce que j'en ai vu vite fait), elle ne met pas toujours les choses dans leur contexte non plus.

L'intérêt de l'approche de la sécurité dans OpenBSD n'est pas dans une validation de la pertinence théorique de toutes ses mitigations (certaines sont très utiles, d'autres moins mais ajoutées pour expérimenter car elles ne coûtent pas cher), ni que chacune soit la version la plus avancée connue de la mitigation (pour certaines oui, pour d'autres non). Ce qui importe, c'est qu'elles sont appliquées par défaut, s'ajoutent entre elles (défense en profondeur) et restent pragmatiques et sans gêne pour l'utilisateur (pas de grosse perte de performances et ne cassent pas trop de programmes).

Certaines critiques ont tendance à supposer que l'attaquant peut se permettre un nombre très grand d'attaques, alors qu'en réalité l'attaquant n'a souvent qu'un nombre d'essais limités lorsqu'il attaque une machine à distance : s'il crashe le programme, son attaque est le plus souvent ratée. OpenBSD ne relance pas par défaut un démon qui aurait crashé, un admin est censé passer par là pour voir ce qui s'est passé. Le site en question a tendance à passer en revue les mitigations dans le contexte d'attaque locale : toutes les mitigations ne visent pas forcément à être utiles dans ce contexte.

La documentation est claire (si jamais vous trouvez ce que vous cherchez. Ça manque d'un wiki tout ça).

En plus de la FAQ (qui fait un peu office de wiki, mais plus à jour), personnellement j'adore apropos, qui sur OpenBSD a plus de fonctionnalités et permet de faire des requêtes vraiment variées.

Ah, cette icône là. Je pourrais ajouter ça, oui, je vois qu'effectivement il y a une fonction pour ajouter une icône dans SDL. Je suis un peu déconnecté des environnements de bureaux traditionnels, je crois que je n'y aurais jamais pensé, merci de me l'avoir signalé :-)

Pour le fichier desktop, ça a l'air en effet plus le genre de trucs à ajouter par une distribution dans une installation par gestionnaire de paquets.

J'essaierai de faire un truc après réfléchir à une bonne façon de le rendre visuellement intuitif.

Ah, pas faux, j'avais oublié ce détail, j'y ai pensé en écrivant la bibliothèque, mais n'y ai plus pensé par la suite : c'est l'inconvénient d'utiliser un gestionnaire de fenêtres qui n'affiche pas le nom des fenêtres. Corrigé !

Pour l'icône, j'imagine que ça doit être une de ces entrées .desktop, j'avoue ne rien y connaître.

On peut vouloir faire d'autres actions que bouger dans la même direction après un saut : par exemple utiliser un magara, tourner vers une autre direction, faire un saut contre un autre mur latéral, etc. C'est plus compliqué que ça en a l'air. Et puis c'est difficile de rendre un saut conditionnel intuitif, car lorsqu'on fait un saut, on veut voir normalement le résultat avant d'effectuer l'action suivante (la vue change, on peut changer de plan après le saut).

Ah, je me rends compte que j'avais pas bien compris ta suggestion. Oui, foncer deux fois dans le mur serait peut-être mieux qu'une confirmation complète avec y. Il faudrait quand même que j'affiche un truc dans les logs à chaque fois pour demander confirmation pour savoir ce qu'il faut faire, et ça serait plus difficile à expliquer.

Peut-être que le mieux serait de demander une confirmation en "ralentissant" l'action, mais que ça valide uniquement si on continue dans la même direction (avec les flèches de direction), et sinon si on appuie sur une autre direction ça ne fasse pas de saut. Ça permettrait peut-être d'éviter les sauts intempestif, tout en ne bloquant pas le joueur dans son flux de jeu (lui demander de taper "y" serait lourd). Concrètement ça ne ferait un saut que si on fonce 2 fois dans un mur.

On peut vouloir faire d'autres actions que bouger dans la même direction après un saut : par exemple utiliser un magara, tourner vers une autre direction, faire un saut contre un autre mur latéral, etc. C'est plus compliqué que ça en a l'air. Et puis c'est difficile de rendre un saut conditionnel intuitif, car lorsqu'on fait un saut, on veut voir normalement le résultat avant d'effectuer l'action suivante (la vue change, on peut changer de plan après le saut).

Je peux sauter sur le mur à droite, mais pas si je vais vers le haut. Ce n'est pas super logique, si je suis bloqué c'est qu'il y a forcément un mur au nord.

Mais s'il y a un mur au nord, il devrait être possible de creuser aussi (avec une magara de digging par exemple, ou certains types d'explosions), ce qui n'est pas possible. On pourrait imager des raisons qui empêchent de creuser mais pas de sauter, par exemple qu'il s'agit d'un mur de roche éternelle. Mais du coup on peut aussi imaginer qu'il s'agit d'une barrière énergétique naturelle de celles qu'on trouve à certains endroits des Souterrains, ce qui permettrait de justifier qu'il il n'est pas possible de prendre appuis convenablement pour sauter. Ça pourrait aussi être de la roche vampirique, par exemple. Il manque pas de trucs dans Haréka pour justifier une idée ou l'autre et, d'un point de vue gameplay, les deux ont un intérêt : empêcher de sauter contre les bords encourage à trouver d'autres solutions. Après, au final, ça reste un jeu : il sera jamais vraiment réaliste d'avoir une carte rectangulaire :-)

D'autre part, il n'est pas possible d'aller dans toutes les directions du pavé numérique, je présume que c'est assumé.

Oui, c'est voulu : le fait de limiter le mouvement à quatre directions permet de réaliser des manœuvres de contournement d'un monstre dans un espace ouvert sans se faire attaquer, et parfois même de se retrouver dans l'angle mort de vision d'un monstre et faire fausse piste. Ça a accessoirement aussi l'avantage d'être plus accessible aux joueurs sans pavé numérique.

Ce qui veut dire que dans un cas comme celui-ci, je vais forcément mourir (sauf si j'ai un objet qui va bien), car je ne pourrais pas me sauver en appuyant sur 7 ou 9 :

Tu peux sauter contre le mur derrière, ou, si c'est contre le bord, tu peux prendre appui sur le monstre en bougeant vers lui pour sauter de l'autre côté. Prendre appui sur le monstre est moins efficace que contre un mur, donc tu sautes une case en moins. Ça veut dire que le monstre a le temps de t'attaquer une fois, mais si tu as plus d'un point de vie, il est possible de s'en sortir !

J'avoue ne pas savoir pourquoi la commande d'installation ne marche plus avec la nouvelle version en mettant le lien vers tuxfamily : je vais regarder ça, merci.

Hm, j'ai testé une fois. Ça n'a pas marché non plus. J'ai retesté, puis ça a marché : peut-être un soucis temporaire sur le serveur, aucune idée.

Sinon, je viens de traiter les trucs simples :

Tu peux le faire en lançant go install --tags sdl dans le dossier (ça téléchargera quand même les dépendances). Je mentionnerai ça dans le README, merci.

C'est fait. En fait, je ne mentionne plus go get, car ça n'a pas trop de sens dans un README, et ça fait quelques trucs pas intuitifs (par exemple, il nomme l'exécutable harmonist.git lorsqu'on utilise l'url de tuxfamily, ce qui est plutôt bête).

J'avoue que je devrais séparer ça en deux messages : un pour le joueur, du style « Warning : could not load old save game… starting new game. » et logger les détails à part, vu que c'est pas vraiment une erreur.

Corrigé aussi !

La version sdl permet de zoomer avec + et -, mais comme c'est spécifique à la version sdl, j'ai zappé de documenter ça.

C'est ajouté dans l'aide maintenant.

Pour tester les changements, tu peux simplement lancer :

git pull
go install --tags sdl

Encore merci pour les retours, c'est bien utile !

De plus j'aurai aimé avoir le jeu en plein écran, là la fenêtre est deux fois plus large que haute et pas moyen (visible) de changer cela. (bon ce n'est pas bien grave non plus)

Ah, par contre, c'est vrai, le plein écran d'harmonist préserve les dimensions. Je pourrais changer cela, mais les images apparaitraient alors étirées, ce qui serait un peu bizarre, non ?

Super merci pour le retour !!

J'avoue ne pas savoir pourquoi la commande d'installation ne marche plus avec la nouvelle version en mettant le lien vers tuxfamily : je vais regarder ça, merci.

la doc n'indique toujours pas comment compiler le projet depuis le code source télécharger.

Tu peux le faire en lançant go install --tags sdl dans le dossier (ça téléchargera quand même les dépendances). Je mentionnerai ça dans le README, merci. D'ailleurs, à la place du -u tu peux aussi ajouter la version précise avec @v0.4.0 en fin d'url.

par contre quand je démarre harmonist-0.4 ça indique au démarrage, en haut, en rouge : "Error : gob: type mismatch in decoder: want struct type gruid. Point; got non-struct Could not load saved game… starting new game. "

Hm, oui, le message apparaît parce que tu as déja joué à une version précédente et que le vieux fichier de sauvegarde n'était pas compatible. J'avoue que je devrais séparer ça en deux messages : un pour le joueur, du style « Warning : could not load old save game… starting new game. » et logger les détails à part, vu que c'est pas vraiment une erreur.

Ensuite, au niveau de l'interface, c'est un peu dommage que la fenêtre ne soit pas redimensionnable.

La version sdl permet de zoomer avec + et -, mais comme c'est spécifique à la version sdl, j'ai zappé de documenter ça.

D'ailleurs parfois il n'y a pas de murs mais on ne peut pas non plus sortir de l'espace (qui est sans doute l'espace max de jeu).

Oui, le jeu utilise les dimensions 80x24, qui sont les dimensions traditionnelles du terminal et des roguelikes comme nethack. C'est un peu pour ça que la fenêtre n'est pas redimensionnable, pour éviter les confusions, tout en utilisant l'espace au maximum, sans bordures (comme nethack, du moins vanilla).

Peut-être qu'une option pour changer le comportement sera pas mal (soit "sauter tout le temps face à un mur", soit "confirmer avant de sauter", comme pour entrer dans les abysses ou je ne sais plus quoi.)

J'y ai pensé, mais vu que c'est une fonctionnalité très utilisée pendant le jeu, je m'étais dis qu'une demande de confirmation serait un peu lourde. Contrairement aux abysses, c'est moins dangereux comme faux-pas, mais le risque est quand même là, effectivement ;-) Mais ça serait possible d'ajouter une option, oui.

De plus j'aurai aimé avoir le jeu en plein écran, là la fenêtre est deux fois plus large que haute et pas moyen (visible) de changer cela. (bon ce n'est pas bien grave non plus)

Pour le coup, c'est possible avec la nouvelle option -F : harmonist -F lance le jeu en plein écran ! :-)

En parlant de Shaedra, l'auteur m'a soufflé qu'a priori elle va libérer également les autres séries du même univers d'ici quelques mois.

Le problème des nil pointer exceptions n'est pas comparable à celui des sections unsafe ni aux void* de C. C'est plus comparable à une exception quelconque, comme un index out of bounds (possible en Rust aussi), sauf que souvent plus facile à tester, donc moins problématique.

Tu es tombé les deux pieds dedans ! ;-)

Je pensais aussi à toute la médiatisation qui a été faite sur le covid (puisque c'est le sujet). Beaucoup de culpabilisation des jeunes (sans statistiques), culpabilisation des bars et restaurants (sans statistiques), culpabilisation des non porteurs du masque (qu'ils soient à l'extérieur ou soient déjà immunisés), titres sensationnalistes, imprécis et anxiogènes. Ça a eu beaucoup plus d'impact en France que le cirque délirant sur twitter d'un président de l'autre côté de l'Atlantique, ou que les écrits par des gens lambda en colère sur des forums.

Perso, je ne trouve pas ça ce genre d'arguments, fait à la va-vite,très surprenants.
C'est du même niveau de sérieux que ce que font les médias, et ça a à priori moins d'impact, donc plus excusable.

Oui, enfin, à part la première incise qui se défend, tu remplaces « : » par « . ». Tu enlèves simplement le lien de conséquence. Puis tu ajoutes une virgule avant un « et », alors que normalement on ne met pas de virgule avant le « et » si le sujet est le même (sauf exceptions qui ne s'appliquent pas ici). Bref, t'avais bien compris, tu chipotais ;-)

Ce que je disait, c'est pas de convertir le convaincu mais de au mieux l'ignorer, et ne pas l'attaqué personnellement pour le rendre encore plus virulent et rageux.

Tu disais qu'il fallait démonter les arguments. J'ai pas compris que tu entendais par ça de les ignorer. En fait, on était peut-être d'accord.

Note tout d'abord que je suis d'accord avec toi : s'attaquer à la personne est d'un inutile profond. Quand je disais « ce genre d'arguments » je ne faisais pas référence aux tiens. Je dis ça juste au cas où tu aies interprété ça autrement, vu l'ambigüité possible.

contexte et ponctuation stp parce que je comprends pas.

Contexte : le bon journalisme est rare (opinion assez partagée). Conclusion : pas surprenant de trouver du mauvais journalisme dans un billet d'humeur. Si les élites font déjà du mauvais journalisme, est-on en droit d'attendre plus d'un linuxfrien ?

Par ailleurs, je ne comprends pas tes remontrances sur la ponctuation.

Il dit qu'il voit pas le rapport…

Le rapport est que ça ne vaut pas le coup de faire des efforts pour démonter des arguments écrits sur le coup de l'humeur. Ça va au mieux conduire à un dialogue de sourds : les arguments sont une excuse pour une conclusion qui ne va pas changer. La seule information qu'on a, c'est la conclusion : un mécontentement et une méfiance envers le système de la part de l'auteur du journal ; sentiment qui semble se répandre.

Perso, je ne trouve pas ça ce genre d'arguments fait à la va-vite très surprenants : c'est du même niveau de sérieux que ce que font les médias et ça a a priori moins d'impact, donc plus excusable.

Indépendamment de la qualité des arguments issus de l'humeur, la prolifération du mécontentement est une information en soi et montre quand même une chose : le système dans lequel nous vivons semble être en phase difficile. On n'en est pas encore au niveau de mécontentement lors de la révolution industrielle ceci-dit, donc possiblement rien de bien impressionnant ne va se passer, les conservateurs peuvent se rassurer pour l'instant.

Les avantages et inconvénients d'un langage reflètent en général le but initial pour lequel il a été créé et n'ont de sens qu'étant donné un contexte.

Concernant Rust, il me semble quand même assez marqué par le fait d'avoir été prévu pour écrire des navigateurs et remplacer du C++ fragile dans certaines parties sensibles de firefox. Partant de là, la complexité du système de types, du système de macros, ou la lenteur de la compilation ne sont pas des éléments nouveaux. Même le système d'ownership apporte une complexité qui n'est pas tout à fait étrangère au C++ avec le RAII etc.

Quand la comparaison se fait avec des langages aux caractéristiques très différentes (comme Go ou Java), c'est difficile de dire que tel ou tel truc devrait être comme dans Rust ou l'inverse, tellement un changement impacterait souvent le reste de façon non triviale. Je peux par exemple aimer le pattern matching en OCaml ou Rust tout en préférant que Go n'en ait pas. De même, je peux apprécier les types somme dans certains langages tout en les considérant une mauvaise idée pour Go (ça s'harmonise pas bien avec le concept de valeur par défaut pour les types, et il y a redondance avec l'utilisation des type-switch et des constantes).

Il n'y a pas de consensus scientifique (ni communautaire) qui dit qu'un langage généraliste, indépendamment de son domaine de prédilection, devrait avoir un système de types évolué, ou un système de macros, ou alors le contraire un système de types simple avec réflection. Il y a des approchent qui ne se complémentent pas simplement et orthogonalement, certains objectifs sont incompatibles avec certaines recherches.

Les rares trucs sur lesquels il y a plus ou moins consensus, c'est sur des implications immédiates pour lesquelles il manque un contexte et des stats d'impact pratique : macros + système de types complexe + abstractions zéro-coût = compilation lente ; existence d'assertions de types ou typage dynamique = possibilité d'erreur de typage au runtime ; exceptions = une parties des inconvénients du goto ; pas de types génériques = pas de bibliothèques génériques ; typage statique = manque d'expressivité ou système de typage complexe, etc…