GuieA_7 a écrit 675 commentaires

Certes mais vouloir qu'il y ait un gagnant alors que les langages sont sur des segments différents, en utilisant un critère tout à fait arbitraire, tient juste du biais de confirmation. Avec le même sophisme on pourrait dire que c'est PHP qui a gagné…

Il est clair qu'avec son approche plus """élitiste""" Rust sera probablement toujours utilisé dans moins de projets ; mais peut-être qu'il sera dans pas mal de bibliothèque bas niveau (ré-écrire Blender ou Gimp en Rust c'est une perte de temps ; mais des bibliothèques alternatives pour TLS ou jpeg c'est déjà plus réaliste). Voir un gagnant entre Go et Rust là-dedans n'aurait aucun sens.

PS: toi qui aime le jeu vidéo libre, https://veloren.net/ est un projet très intéressant par exemple.

Il n'y a pas une seule stratégie gagnante (il s'agit de gagner quoi d'ailleurs ?). Google (créateur de Golang) utilise Golang ET Rust par exemple.

Faudrait expliquer pourquoi ces deux langages n'ont rien en commun.

Dans l'article il est notamment question de ré-écrire certaines bibliothèques critiques. Or Go a besoin d'un runtime (pour son GC, la gestion des routines notamment) ce qui en fait un mauvais candidat pour cet usage  ; ça pourrait être pire si on utilisait un langage à VM en terme de gros runtime qui vient avec, mais il y a clairement mieux que Go pour ça.

Rust en revanche est un langage qui permet d'aller plus bas niveau (il est totalement utilisable pour écrire un kernel par exemple) ; il ne nécessite pas de runtime et permet d'écrire des bibliothèques qui seront vues de l'extérieur comme si elles étaient codé en C.

À côté de ça, les garanties fortes sur le contrôle des données que donne le système de typage plus puissant (et donc complexe) de Rust est un atout en matière de sécurité (là où en Go il est très possible que 2 routines tapent dans les mêmes données sans que ça soit désirable).

Ce qui aurait été vraiment intéressant c'est un "safe C". Un C compatible à 90% avec l'existant, mais sans les pièges. Mais c'est sans doute plus fun de créer un langage vraiment nouveau.

Vu la popularité de C, si c'était vraiment possible de faire un langage à la fois très compatible et très sécurisé, il est très probable que ça aurait déjà fait. Et des gens très pragmatiques (genre Microsoft, Amazon, Google, des gens guidés par le fun de toute évidence) ne s'embêteraient pas à partir sur un nouveau langage s'ils pouvaient économiser énormément de temps et d'argent avec un tel langage.

Ceci dit, cela ne s'applique pas aux objets qui eux, sont toujours passés par référence.

Du coup c'est un gros "sauf". Et dans la mesure où Rust est utilisable pour écrire des bibliothèques comme si elle était écrite en C, on comprend la présence du concept de pointeur (je comprends qu'on veuille les proscrire dans certains cas spécifiques, mais je préfère dans le cas général l'approche où on garde sous surveillance les quelques blocs unsafe qui traînent).

Si le but est de forcer l'inlining, en Ada, il y a un aspect pour ça et on se passe très bien des macros pour le coup.

Je te rassure Rust sait très bien inliner. Les macros peuvent faire des choses qui ne sont pas possible avec des fonctions (en Rust) :

• Déclarer/définir des types.
• Avoir un nombre de paramètres variable.

Plus de détails ici: https://doc.rust-lang.org/book/ch19-06-macros.html

En fait en Rust on manipule des références la plupart du temps, pas des pointeurs. Si on veut faire des choses acrobatiques comme de l'algèbre de pointeurs, ça sera dans un bloc unsafe pour des raisons assez évidentes (et c'est donc tout à fait évitable en général).

Quand aux macros dont tu parles plus haut (flemme de faire un autre commentaire), il s'agit de macros façons LISP (hygiéniques, gérées par le langage) et pas façon C/C++ (gérées par le préprocesseur, simple remplacement de chaînes sans vérification de syntaxe). Ça permet notamment d'éviter le code boiler-plate de façon plutôt élégante ; mais je veux bien lire tes griefs.

Ça c'est l'ami de mikey !

Ah non c'est le chien de Mickey ; l'ami de Mickey c'est Dingo !

Plutôt que :

for contactId in range(len(contacts)):
    contact = contacts[contactId]

on écrit plutôt :

for contactId, contact in enumerate(contacts):

Mes 2 cents (et bonne année!)

Quand j'ai des calculs un peu bourrins à implémenter, une fuite mémoire c'est un crash assuré donc le résultat est à peu près le même qu'un dangling pointer.

Je ne sais pas ce que le terme technique "bourrins" signifie dans ton monde, mais un dangling pointer peut mener à des résultats faux, mais valides, et sans crash. Donc a un bug que tu ne verras peut-être jamais ; en général on considère que quand un dangling pointer provoque une segmentation fault on a de la chance !

pour moi c'est juste non.

Tu veux dire que comme aucun langage ne garantit l'absence de fuite mémoire, tu ne programmes pas du tout ?

C'est toujours un plaisir de lire tes rétrospectives. Je suis sûr que dans quelques temps tu auras fait de nouvelles choses que tu voudras partager, et que ce n'est pas le dernier bilan (mais si c'était le cas, ce n'est pas grave hein).

Des bisous !

Quel rapport ? Ici, le sujet c'est Rust pour faire un OS

Le rapport c'est que tu n'a pas compris les garanties qu'apporte Rust, alors j'utilise un paradigme plus connu, le GC, en espérant que tu le connaisses mieux, pour te l'expliquer… Mais visiblement tu préfères juste te plaindre que tu as été honteusement trompé.

la memory-safety on nous la sert dès la page d'accueil de Rust alors que pour les fuites mémoires

Pour la bonne raison que les fuites mémoires ne posent pas de problème de memory safety . Ce sont des problèmes, de mémoire, mais qui ne posent pas de souci de sûreté ; les fuites mémoires sont évidemment prises au sérieux, et Rust rend leur présence beaucoup plus difficile.

Donc c'est normal que la sûreté soit mise en avant vu qu'elle est garantie (au revoir les buffer overflows, les dangling pointers, les accès non protégés inter-threads …—et surprise, c'est bien dans le cadre de l'écriture d'un OS), et qu'il faille un peu lire la documentation pour avoir les cas tordus de fuites mémoire.

Merci mais je ne vois pas ce que les GC viennent faire ici. Le but d'un GC, c'est principalement d'apporter de la simplicité, pas forcément de la memory-safety.

Vu qu'on se sert principalement de langages à GC pour faire des services Web par exemple (Java/Python/PHP/Go…) et que la sécurité y est un élément important je dirai qu'on embrasse les différentes qualités qu'apporte un GC en général (même si les développeurs ne s'en rendent pas compte car ce sont des problèmes bas niveau). En fait la simplicité vient justement en partie du fait que des problèmes de memory safety n'existent pas. Donc la simplicité ce n'est pas seulement qu'on n'a pas besoin d'appeler free().

ça ne vaccine pas des refontes pour corriger des problèmes mémoires

En ce qui me concerne j'ai déjà corrigé ici-même des gens qui disaient que Rust empêchaient toutes sortes de fuite mémoire. Ici par exemple, dans une dépêche Rust: https://linuxfr.org/news/rust-a-5-ans-retrospective#comment-1823413

Reste que ce n'est pas parce que ce n'est pas une solution miracle qui garantit qu'il n'y aura jamais besoin de "refontes pour corriger des problèmes mémoires" que ça ne veut pas dire que ça ne fait pas mieux que les autres langages (par exemple en faisant que ce genre de refonte est rare—rappelons que l'on parle d'un noyau qui est plus complexe qu'un programme lambda—nul miracle certes, mais un progrès quand même).

Comme je l'ai dit précédemment tu as des avantages des langages à GC (sécurité mémoire + on ne se préoccupe que rarement de libérer la mémoire à la main) mais sans le coup à l'exécution d'un GC (comme dans les langages à gestion manuelle de la mémoire). Oui c'est moins sympa que l'image "ça corrige tous les problèmes mémoire" (ce qu'aucun langage même lent et haut niveau ne peut faire), mais c'est déjà pas mal.

Alors ce n'est pas tout à fait ce que tu demandes, mais j'avais lu cet article intéressant où l'auteur, fan de Kotlin, explique comment il a fini par trouver Rust aussi productif pour les projets complexes: https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/

C'est une question complexe, et il faut commencer par se demander ce qu'on mesure. Exemple (avec des chiffres pipo): si un programme est développé en C en un 1 mois (avec des bugs critiques et complexes à corriger: mémoire, threads…), qu'un programme équivalent est fait en 2 mois en Rust (mais avec seulement 1% des bugs de la version C), et qu'il faudra au final 2 mois supplémentaires à la version C pour corriger les bugs les plus gros (sans atteindre la qualité du programme en Rust) ; alors que peut-on en conclure sur la productivité ? La réponse peut dépendre des cas, si on parle de time-to-market par exemple (et oui même si dans mon exemple là j'aimerais répondre simplement "Rust" pour des raisons de long termes, on sait bien qu'en pratique c'est plus compliqué).

Comme dit plus haut, même les langages à Garbage Collector ne garantissent pas l'absence de fuites mémoire. Ce qui est garanti, c'est l'absence de data race, de double free, de dangling pointers … ; et en pratique il y a beaucoup moins de travail pour le programmeur afin d'éviter les fuites mémoire (99% du travail est fait automatiquement par le GC).

Rust apporte la même chose, à la compilation, sans GC.

Ça permet de faire des petits jeux GameBoy (qui pourront donc tourner dans un émulateur ou une vrai console) dans le style de Pokemon (il semble que la prochaine version pourra permettre de faire des jeux plus variés—shoot'em up etc…):

https://chrismaltby.itch.io/gb-studio

La programmation se fait avec un langage graphique assez simple (et donc limité), les décors peuvent se faire avec Tiled par exemple (GB-Studio prend directement des PNG et retrouve les tuiles lui-même).
C'est plus limité que ce que tu demandes mais peut-être que pour un tout premier jeu ça pourra le faire.

As-tu pensé à mettre ta magnifique prose sous une licence CC (une libre évidemment), ou est-ce que tu penses que ça va te fermer le monde de l'édition professionnelle ?

l'envie de laisser tomber a été renforcée par le peu de contributeurs, peut-être parce que peu de gens ont envie de s'investir dans des maths, et ceux qui ont envie n'ont pas envie de les implémenter et de débugger.

Si ça peut te rassurer (bon, pas sûr) c'est le cas d'une grande partie des logiciels libres d'être portés par une équipe (parfois d'une seule personne) sans grosse contribution externe (même s'ils ont des utilisateurs). Les logiciels comme Linux, pour qui gérer les contributions externes est complexe tellement elles sont nombreuses, sont l'exception et pas la règle.

Bon courage !!

Je vois ce que tu veux dire, mais je ne vois pas trop l'intérêt de faire ta propre définition, d'autant qu'il y a globalement consensus.

Si tu discutes avec des gens qui connaissent les concepts de typage fort/faible et statique/dynamique, il y a toutes les chances qu'ils connaissent les inconvénients du typage dynamique (on ne va pas faire du code hyper critique avec). Ça permet des combinaisons pour rapidement catégoriser les langages, genre le C qui a un typage statique mais plutôt faible (surtout si on ne demande pas au compilateur d'être un peu agressif) ou le Python qui a un typage fort mais dynamique.

Python est un langage faiblement typé et qui a tendance justement à caster implicitement quand il peut […]

Faux. Alors, certes quand la limite entre typage dynamique et statique est assez claire, on ne peut pas juste classer les langages dans les 2 catégories "typage fort" & "typage faible". On a des typages plus ou moins fort. Mais en général le typage de Python est considéré comme fort ; essaie de faire [1, 2] + (3, 4) ou bien 1 + '1' pour t'en convaincre.

En revanche le typage de PHP (à moins que ça ait changé depuis 15 ans) ou de JavaScript est considéré comme faible.

Définir clairement ce qu'est une personne libre est quelque chose de compliqué, qui occupe les philosophes depuis des milliers d'années ; mais on voit quand même à peu près de quoi on parle.

En revanche pour un logiciel ou bien un film, ça ne veut rien dire à la base ; c'est pour ça qu'une définition claire a du être faite dans les années 80.

Du coup partir de la définition du Larousse pour faire une définition à votre sauce c'est très discutable comme pratique. Pour le coup je peux dire que je suis libre d'aller acheter le dernier Pixar en DVD, libre de le regarder autant de fois que je veux, et même libre de le prêter à mes amis. Et donc je peux dire que le dernier Pixar est libre selon moi.

bref si quelqu'un a une explication ?

À mon avis c'est notamment parce que globalement les 2 langages sont très proches (libres & communautaires, portables/multi-plateformes, interprétés, langages impératifs orientés objet, typage fort et dynamique, gestion automatique de la mémoire, polyvalents, expressifs/concis, assez lents…), mais Python est plus vieux et a donc l'avantage d'une communauté plus grosse à la base (et du coup plus de bibliothèques, de tutoriels…). Et donc au moment de choisir un de ces 2 cousins, on part naturellement vers le plus populaire (et qui du coup reste le plus populaire).

C'est un motif qu'on retrouve un peu tout le temps ; 2 solutions techniquement très proches dont une prend l'avantage "réseau" à un moment pour une raison ou une autre, et qui finit par éclipser l'autre (ex: FreeBSD qui propose dans l'ensemble quelque chose de proche d'une distribution Linux, mais à l'époque des déboires juridiques des *BSD, Linux est passé devant).

Ça fait quelques années que sur Twitch le lag n'est que d'une poignée de secondes ; auparavant oui c'était quelque chose comme 20 secondes, et ça rendait les échanges avec le streamer plus pénibles (ex: le streamer va poser une question, mais le temps que la réponse arrive des questions sont posées dans l'autre sens etc… ce qui demande une certaine gymnastique mentale, surtout que le streamer fait souvent autre chose en même temps). Et si j'ai bien compris d'autres plateformes (HitBox?) avaient des latences faibles bien avant Twitch.

Ceci-dit je suis plutôt enthousiasmé que PeerTube s'attaque à ça, j'ai hâte de voir ce que ça va donner.

nouveau concept de « synchronisation d’arguments » dans la classe GimpProcedure afin que les arguments de procédures se synchronisent avec un parasite d’image du même nom ;

paramètre ? (ou sinon je n'ai pas compris de quoi il s'agit).

Si ça fait des années que tu utilises Linux et que tu en es satisfaite, bravo tu as déjà fait ta transition ! Si aucune application propriétaire ne te retient sous Windows alors le dual-boot sera probablement inutile (il finira oublié dans un coin, tu ne te souviendra même plus du mot de passe).

Tu n'as jamais installé toute seule, alors normal que ça te semble mystérieux et complexe, mais aujourd'hui installer une distribution grand public comme Ubuntu ce n'est vraiment pas compliqué la plupart du temps. Le plus difficile c'est de lancer une commande pour faire une clé USB d'installation (et encore je crois que des outils font ça en graphique) et d'aller dans la configuration de ton PC pour lui dire de démarrer sur l'USB. Après tu réponds à 4 questions triviales (langue, nom, mot de passe, pays) et tout se fait tout seul.

Cependant je te conseillerai d'avoir un 2ème PC fonctionnel en parallèle (si tu dois refaire une autre clé avec un autre système parce que la 1ère ne passe pas par exemple etc…). Et comme conseillé au dessus, au moins pour ta 1ère fois le faire dans un LUG (ou avec un(e) ami(e) linuxien(ne)) ; du coup tu n'as pas à fournir l'autre PC fonctionnel évidemment. Ça sera moins de stress, la technique c'est toujours énervant quand ça ne marche pas.

Bon courage pour la suite !

Bref, ce sujet est dans ma liste des sujets dont j’espère pouvoir faire un article

J'ai hâte <3