Ils parlent de memory-safe language, avec l'exemple de Rustls. Pas de tout réécrire en Rust
Peut être qu'ils ne financent pas au sens monétaire du terme : le verbe utilisé est "to support"
Donc je suppose que dédier du temps de leurs développeurs pour corriger les problèmes existants (trouvés avec fuzzing ou analyse statique) compte aussi pour cette annonce ?
Seule la famille C/C++/Objective C/… ainsi que quelques langages peu vivants (snif mon Object Pascal) permettent des fantaisies à base de pointeurs mal pointés.
Ça devient un peu LOURD la rust propaganda :(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Ce qui m'énerve le plus en ce moment sur reddit et HN, ce sont les gens qui peuvent pas s'empêcher de “why didn't you write it in Rust” à chaque fois que quelqu'un présente un nouveau projet.
git is great because linus did it, mercurial is better because he didn't
Posté par _kaos_ .
Évalué à 3.
Dernière modification le 20 février 2021 à 10:30.
Salut,
Java suffit
(je met le pied dedans, mais avec une bonne intention : je développe surtout en java ;) et j'espère avoir bien compris que tu ne parle pas de cet exemple)
Je ne sais pas pour rust, mais en java, dès que tu fais du jni, adieu GC et compagnie ;)
Cela veut dire que tu n est pas informaticien pour dire ça. Rust est le premier langage mémoire safe efficace, aussi rapide que C. Les autres consomment Ram et CPu.
Et puis Java fais des null pointer exceptions, python des gros plantages… Rust sais ce qu'il va se passer.
Posté par abriotde .
Évalué à -1.
Dernière modification le 23 février 2021 à 22:07.
Sauf que si jamais plus de 10 personnes ne se sont intéressés à ces langages il y peut-être une raison. Alors que Rust a convaincu en 10 ans Microsoft, Apple et Google des entreprises qui n avaient jamais pris un langage extérieur depuis 20 ans au moins excepté les leurs.
Alors Rust est pas magique mais il apporte quelque chose de nouveau et de puissant que l on a pas vu dans les langages informatiques depuis les Machines virtuelles avec Java (a rapproché de la révolution LLVM)
Autant j'aime pas Rust, autant conseiller Go plutôt que Rust est plutôt culotté. Ceux deux langages n'ont absolument rien en commun. Rust est un mix entre C et C++ ultra type safe. Go est… inutile.
git is great because linus did it, mercurial is better because he didn't
Faudrait expliquer pourquoi ces deux langages n'ont rien en commun. Et pourquoi Go serait inutile (c'est un troll mais bon).
J'ai pris l'exemple de Go car ça compile en code machine directement, c'est performant, la concurrence est très simple et le langage en lui-même est simple a apprendre et à comprendre. Mais ça pourrait être un autre choix.
Go et Rust ne boxe pas dans la même catégorie. Go est un langage simple, un peu comme java. La généricité vient juste d être introduit.
Rust propose des securités du niveau d ocaml, et meme plus avec le borow checker qui permet de faire de la programation parralel beaucoup plus safe. Mais il est plus complexe.
Go et Rust ne boxe pas dans la même catégorie. Go est un langage simple, un peu comme java. La généricité vient juste d être introduit.
Et donc c'est un problème ? Ça me parait plutôt un avantage.
Rust propose des securités du niveau d ocaml, et meme plus avec le borow checker qui permet de faire de la programation parralel beaucoup plus safe. Mais il est plus complexe.
Je sais que si les performances sont primordiales, Rust est au dessus. Mais c'est assez quand même assez rarement le cas.
Il n y a pas que les performances. Il est difficile de faire du code générique en Go. On utilise trop souvent Interface{}, la reflexivité et la generation de code.
Il n y a pas que les performances en informatique mais quand tu t embête a développer en C c est juste pour les perfs. Et la point de vue concurrence, il y a juste Pascal (archaïque) et Rust.
Le problème du C, c'est l'outillage préhistorique.
Quand j'envisage de coder en C, je ne me dis pas oh non je vais devoir gérer la mémoire à la main ou attention avec les pointeurs, tu vas te faire planter très fort. On apprends à gérer ça en maternelle de développement.
Par contre, je me dis toujours si je le fais en C, je vais devoir me taper un système de build compliquai et gérer mes dépendances à la main.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Le filtrage par motif, c'est le nom en français du pattern matching. Ça permet de déconstruire des structures et lier des variables de façon plus déclarative, par exemple écrire un motif pour les listes qui ont au moins trois éléments et donner dans la foulée un nom à ces trois premiers éléments.
C'est sympa, particulièrement dans les langages fonctionnels. Mais ça reste au final essentiellement juste du sucre syntaxique (récursif). Quand je programme dans un langage impératif, j'en ressens pas vraiment le besoin. Si ça ne s'intègre pas naturellement dans le langage, ça ne vaut pas le coup d'introduire de nouvelles syntaxes juste pour ça, à mon avis.
Posté par _kaos_ .
Évalué à 3.
Dernière modification le 21 février 2021 à 15:14.
Salut,
Ouais, ok. J'avais peur de prendre ça comme une remarque sur les regexp (et du coup, te prendre pour un crétin).
Bah si. Tu peux le faire en java. L'introspection te permet ça. Il y a aussi des librairies (certes contribuées), mais qui vont encore plus loin. Tu peux changer ton bytecode au runtime.
Edit : je crois que j'ai commenté à côté de la plaque :(
Bah si. Tu peux le faire en java. L'introspection te permet ça.
C'est différent : l'introspection apporte de l'expressivité en plus au langage (au sens des choses qu'il n'est pas possible de faire sans).
Le filtrage par motif est une syntaxe déclarative pour écrire plus facilement certains types de code. Par exemple :
matchlwith|[]->(* faire des trucs si la liste l est vide *)|(Some((Somex)::[]))::l'->(* faire un truc spécial si le premier élément est un type option qui contient une liste avec un seul élément qui lui même contient un élément x *)|x::[]->(* dans les autres cas, si la liste n'a qu'un seul élément x *)|x::y::l'->(* faire des trucs avec les deux premiers éléments x et y s'il y a au moins deux éléments dans la liste *)
Une version plus impérative ferait plutôt quelque chose comme :
iflen(l)==0{// faire des trucs si la liste l est videreturn}a:=l[0]ifa!=nil{iflen(*a)==1{x:=(*a)[0]ifx!=nil{// faire un truc spécial si le premier élément est un type// option qui contient une liste avec un seul élément// qui lui même contient un élément xreturn}}}iflen(l)==1{x:=l[0]// dans les autres cas, si la liste n'a qu'un seul élément xreturn}x,y:=l[0],l[1]// faire des trucs avec les deux premiers éléments x et y s'il y a au moins deux éléments dans la liste
Après, c'est très tiré par les cheveux, c'est rare d'avoir à destructurer en profondeur juste un cas très particulier et pouvoir gérer tout le reste de façon homogène. En pratique, la différence en verbosité est moindre.
En fait ça devient tellement léger que tu peux te permettre de t'en servir partout. Par exemple pour destructurer un Optional. Et tu gagne en puissance quand tu as un système de type qui te permet d'ajouter de l'information de type à de la donnée à moindre coût.
Pour continuer sur Optional aujourd'hui en java il s'agit d'un objet qui contient une référence vers ta donnée. Tu as donc un objet alloué en plus et une indirection. Certains langages permettent d'avoir une sorte d'annotation de type. À ce moment là, l'aspect optional n'est plus qu'une information de type qui n'a pas à modifier la mémoire (on pourrait même envisager de faire du type erasure) au final tu a un code qui va avoir la sécurité d'un optional sans sur coût.
C'est un argument fort. Bizarre par rapport à qui/quoi ?
Par rapport à la notion mathématiques de lambda. Le typage n'est pas génial par exemple, tu as du typage structurel au moment de la définition d'une lambda mais pas ensuite. Par exemple :
Ça c'est le genre de choses qui peuvent être relou est obliger à passer par :
foo=bar::test;
Ce qui est assez moche.
Mais il n'y a pas que ça, l'arité des fonctions n'est pas véritablement géré ce qui contraint de temps en temps (tu ne peux pas facilement dire que tu ignore des arguments).
Dernier point au niveau syntaxique tu est obligé de présenter les paramètres même quand tu n'en a pas besoin, là où groovy par exemple ne t'y contraint pas :
Closurecallback={println'coucou'}// pas de paramètreClosure<Boolean>bar={it%2}// utilisation d'un paramètre déclaré automatiquement
Ça peut paraître être du sucre syntaxique mais c'est très pratique pour faire des DSL par exemple.
Dans une dichotomie où on a d'un coté des langages complexes et de l'autre les langages simples, java est plutôt simple.
Pour simplifier, tu peux vouloir que ton langage soit une pièce de mathématiques très sophistiqué permettant divers manières de faire un tas de choses, proposant pleins de paradigmes différents, etc ou tu peux vouloir que ton langage soit accessible et que tout locuteur de ton langage soit capable de relire tout code écrire avec ton langage.
Dans cela java est plutôt simple, il ne cherche pas à être à la pointe de la recherche en langage, il incorpore ce qui est déjà répandu dans la communauté. Il a perdu en simplicité avec le temps et son implémentation ont permis d'effectuer des choses complexes mais on reste encore loin de ce que scala ou groovy peuvent proposer en terme de sophistication.
Ça n'est pas un mal chaque langage propose son propre choix là dedans sachant qu'il y a toujours des inconvénients.
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).
Faudrait expliquer pourquoi ces deux langages n'ont rien en commun. Et pourquoi Go serait inutile (c'est un troll mais bon).
Go est inutile parce que :
Il n'apporte absolument rien, c'est une sorte de Java simple. Au moins Rust suit les langages modernes en fournissant des syntaxes puissantes comme le pattern matching.
Il a un GC, il existe des techniques de programmation qui font qu'il est tout simplement plus nécessaire d'en avoir un dorénavant.
Il supporte les pointeurs du style void * comme en C.
Les développeurs laissent pourrir des problèmes et n'écoutent pas la communauté.
Go est écrit en Go, ce qui rend sa compilation sur des nouvelles plateformes pénible. C'est dingue cette obsession de développer quelque chose puis d'en faire un logiciel self-hosted.
Pas de gestion de RAII propre, il faut faire des defer à tout va.
Toujours pas de généricité type-safe (c'est en cours seulement).
Il y a encore plein d'autres raisons que tu peux trouver sur les moteurs de recherche. Celles que j'ai citées sont celles qui me feront jamais utiliser ce langage.
git is great because linus did it, mercurial is better because he didn't
Il n'apporte absolument rien, c'est une sorte de Java simple. Au moins Rust suit les langages modernes en fournissant des syntaxes puissantes comme le pattern matching.
Il a mis un énorme coup de projecteur aux thread léger et a montré leur utilité quand ils sont bien utilisés.
Il a un GC, il existe des techniques de programmation qui font qu'il est tout simplement plus nécessaire d'en avoir un dorénavant.
Oui et non. Un gc a 2 intérêts :
libérer la mémoire : il y a de techniques effectivement pour gérer ça, mais elles ne viennent pas forcément sans contraintes. rust lui-même pose des contraintes là dessus
compacter la mémoire : les cycles d'allocation libération vont créer des trous de mémoire libre mais difficilement utilisables. La seule autre technique que je connais pour compacter la heap c'est d'utiliser des pool, mais c'est très rébarbatif et revient à gérer sa mémoire à la main
Il supporte les pointeurs du style void * comme en C.
Le fait d'avoir des section unsafe en rust le rend inutile ?
Go est écrit en Go, ce qui rend sa compilation sur des nouvelles plateformes pénible. C'est dingue cette obsession de développer quelque chose puis d'en faire un logiciel self-hosted.
Les développeurs d'un langage apprécient le langage qu'ils conçoivent, chercher à l'utiliser eux-même ne me paraît pas "dingue".
Pas de gestion de RAII propre, il faut faire des defer à tout va.
C'est plus subjectif que tu ne le laisse croire. C'est bien plus explicite ce qui en fait un bon point. Je trouve personnellement que ça s'intègre bien dans la philosophie simple du langage pas trop d'abstraction et pas de bizarrerie utilisateur qui s’exécute silencieusement. Ça a d'autres inconvénients je suis d'accord.
Il y a encore plein d'autres raisons que tu peux trouver sur les moteurs de recherche. Celles que j'ai citées sont celles qui me feront jamais utiliser ce langage.
Oui la simplicité de la compilation croisée, la bibliothèque standard plutôt conséquente, son apprentissage plutôt rapide,…
Tu vois moi ce que je trouve dingue, c'est pourquoi les développeurs qui apprécient un langage ont besoin de pourrir les autres. Je ne suis pas un grand fan de go, je m'en sert personnellement très peu, mais pour des endroits où je ne veux aucune dépendance et/ou il remplace un script qui sera plus long où consommera un peu plus de ressources (sur rpi ou en starter dans un conteneur docker ou pour certains contexte où le temps de démarrage de python est plus important que le temps de calcul de mon code) et il ne m'a pas fallut de temps d'apprentissage pour faire ça. Là où rust demande plusieurs semaines/mois pour devenir confortable avec le langage.
Il supporte les pointeurs du style void * comme en C.
Le fait d'avoir des section unsafe en rust le rend inutile ?
Le problème, en Go, est que tu peux avoir des NullPointerExceptions en écrivant du code normal. En rust, comme tu l’indiques, le « problème » est limité à des sections de code très précises que tu peux analyser avec plus d’attention.
C’est d’autant plus dommage que ce problème n’existe pas dans les autres langages récents (typescript, swift, etc.).
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.
Il a un GC, il existe des techniques de programmation qui font qu'il est tout simplement plus nécessaire d'en avoir un dorénavant.
Utiliser des clôtures ou des structures de données cycliques est très pénible sans GC. Pour les structures, le besoin n'est pas forcément fréquent, mais les clôtures, j'en utilise souvent.
Il supporte les pointeurs du style void * comme en C.
Il n'y a pas de pointeurs du style void * comme en C, non. Ce qu'il y a, c'est un type interface particulier qui peut être utilisé comme une version restreinte et plus explicite du concept de variable en Python ou autres langages dynamiques. C'est très différent. Ça représente rarement une portion significative du code et, même lorsque c'est utilisé, c'est le plus souvent à l'aide de type-switchs qui ne peuvent pas provoquer d'erreurs au runtime.
Les développeurs laissent pourrir des problèmes et n'écoutent pas la communauté.
Chose qui peut s'appliquer à n'importe quel gros projet : impossible de satisfaire tous les utilisateurs. Il y en aura toujours pour se sentir oubliés parce qu'ils n'ont pas écoutés, mais ils oublient souvent que leurs besoins sont en conflits avec ceux d'autres utilisateurs, ou simplement non prioritaires. Par exemple, les utilisateurs de Rust et C++ qui aiment la compilation rapide pourraient se sentir oubliés. Leurs préférences sont juste en conflit avec celles d'autres utilisateurs du langage.
Go est écrit en Go, ce qui rend sa compilation sur des nouvelles plateformes pénible. C'est dingue cette obsession de développer quelque chose puis d'en faire un logiciel self-hosted.
C'est un désavantage en partie, mais bon, tu as gccgo aussi. Personnellement, je trouve que les avantages compensent largement les inconvénients : c'est un compilateur facile à maintenir par n'importe quel utilisateur du langage et qui compile en à peine une minute sur de vieilles machines (bref, ça m'est techniquement accessible, contrairement au compilateur Rust, par exemple).
Celles que j'ai citées sont celles qui me feront jamais utiliser ce langage.
C'est l'impression que tu donnes en effet, celle de n'avoir jamais utilisé ce langage, mais d'être capable de le juger comme « inutile » sur la base d'une compréhension qui n'est pas basée sur un apprentissage du langage. C'est courant comme chose à faire mais, perso, je ne comprends pas.
Et puis, personnellement, si je devais me faire une idée sur un langage que je ne connais pas, je serais méfiant de m'appuyer sur des arguments techniques sortis de contexte et peut-être mal compris. Surtout pour un langage qui est quand même utilisé pour faire plein de choses. L'argument d'autorité n'est pas fiable en lui-même, mais dis-toi quand même que Go est utilisé avec satisfaction par plein de monde, pas forcément que des ignorants, et ses propres créateurs ont un bon bagage dans le domaine. De quoi se dire qu'un jugement rapide risque fortement d'être incorrect.
Perso, d'expérience, avec les langages de programmations, il y a deux types de personnes qui les détestent : ceux qui ne les ont pas utilisé, mais ont des préjugés basés sur leurs préférences dans des contextes qui ne s'appliquent pas ; et ceux qui ont été forcés de les utiliser dans un projet mal bâti.
Ce n'est pas mon impression, je ne sais pas où tu as lu ça. Mon impression, c'est qu'ils ne mettent pas la priorité sur la théorie des types, qui n'est qu'une branche parmi d'autres en théorie des langages (juste un peu à la mode sur reddit et quelques forums, en partie grâce à Rust).
Un langage à la pointe en théorie des types fera des sacrifices ailleurs : les chercheurs ne visent pas à faire un langage pour le rendre le plus productif possible, ils visent à faire un langage qui développe leur théorie (des types ou des langages extensibles ou autre). Tout prendre (types évolués + macros + performant + simple etc.) n'est a priori pas plus raisonnable (ni possible) d'un point de vue design de langage pratique.
la théorie des types, qui n'est qu'une branche parmi d'autres en théorie des langages (juste un peu à la mode sur reddit et quelques forums, en partie grâce à Rust).
Perso, c'est peut-être le principal avantage que je trouve à Rust. Mais bon ça casse pas 3 pattes à un canard non plus. Rust supporte les types algébriques et les type-classes mais il n'y a pas de HKT comme en Haskell ni de module comme en OCaml.
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…
Je connais beaucoup de projets majeurs en Go (Kubernetes, les outils d'Hashicorp, Docker, Grafana) et d'autres très sympathiques (Caddy, Maddy), mais très peu en Rust (Deltachat, un bout de Firefox).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
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.
(ré-écrire Blender ou Gimp en Rust c'est une perte de temps ;
Il faudra y passer si on souhaite toujours attirer des contributeurs le jour où Rust aura pris une grosse place.
Je me vois bien contribuer un jour a un projet Rust mais le C hors de question.
Alors oui, si on pouvait d'un coup de baguette magique transformer le code de Gimp en Rust, et au passage faire que ses contributeurs soient aussi expérimentés en Rust qu'en C, ça serait trop cool.
Mais en pratique c'est déjà souvent compliqué de financer le développement de logiciel libre (Gimp par exemple, et pourtant C est populaire, comme quoi ça ne suffit pas). Donc expliquer aux gens de Gimp "hey passez les 20 prochaines années à réécrire le logiciel, et là peut-être que je vais faire une contribution" illustre bien le problème.
c'est arbitraire de décider que c'est LE critère pour décider d'un gagnant, alors qu'il y a à la fois des tas de critères intéressants, et pas besoin de décider d'un gagnant entre 2 outils qui ne résolvent pas les même problèmes ("je dois absolument décider d'un gagnant entre ma fourchette et mon parapluie").
la popularité d'un langage, ce n'est pas la popularité d'une pop star. Un langage utilisé massivement, ça veut dire de la documentation, du support, des bibliothèques, des développeurs…
Une star plus populaire ça veut dire plus de moyens financiers pour les concerts/clips, plus d'opportunités d'avoir des produits dérivés, de trouver des fan arts, de rencontrer d'autre fans et se faire des amis. Donc au contraire c'est un très bon critère pour choisir une star en un sens ; mais là encore ça serait vraiment dommage de choisir uniquement comme ça…
Les premières versions publiques n'ont que 3 ans d'écart (2009 pour go et 2012 pour rust) tout comme les premières versions dites stables sont arrivées en 2012 pour go et 2015 pour rust.
Docker est créé en 2013 soit 4 ans après la première version publique de go ou un an après sa première version stable. La première version de graphana c'est 2014.
Du coup j'ai pas l'impression que l'argument de l'âge soit très pertinent.
Après est-ce qu'avoir un fleuron est un gage de qualité ou d'intérêt du langage, je ne suis pas sûr.
Après est-ce qu'avoir un fleuron est un gage de qualité ou d'intérêt du langage, je ne suis pas sûr.
Je ne sais pas non plus si ça a grand intérêt. Peut-être est-ce utile pour certains afin se rassurer (ouf! Rust le-langage-dont-je-ne-sais-rien-si-ce-n'est-que-je-l'aime-pas n'a pas encore de flag ship ça fait du bien à mon ego)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Là ils donnent juste un exemple de code qui a été écrit dans un langage «memory-safe», en l'occurrence en Rust, mais ils n'indiquent pas qu'ils ne vont financer que des projets en Rust.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Precisions
Posté par Xinfe (site web personnel) . Évalué à 4.
Donc je suppose que dédier du temps de leurs développeurs pour corriger les problèmes existants (trouvés avec fuzzing ou analyse statique) compte aussi pour cette annonce ?
# Pourquoi Rust ?
Posté par ff9097 . Évalué à 3.
Golang ne serait-il pas plus adapté ? C'est également memory-safe, bien plus simple d'accès et très bien adapté à tout ce qui touche au réseau
[^] # Re: Pourquoi Rust ?
Posté par xules . Évalué à 1.
parce que, au hasard, pas de gc ? pas de null/nil ? des génériques ?
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
La plupart des langages sont memory safe.
Seule la famille C/C++/Objective C/… ainsi que quelques langages peu vivants (snif mon Object Pascal) permettent des fantaisies à base de pointeurs mal pointés.
Ça devient un peu LOURD la rust propaganda :(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par David Demelier (site web personnel) . Évalué à 2.
C'est vrai, je suis assez d'accord.
Ce qui m'énerve le plus en ce moment sur reddit et HN, ce sont les gens qui peuvent pas s'empêcher de “why didn't you write it in Rust” à chaque fois que quelqu'un présente un nouveau projet.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . Évalué à 6.
Ben faut dire que résumer Rust à la memory safety, c'est comprendre 20% des garanties du bidule.
Évidemment dans ce cas là moi aussi j'en aurais marre.
Si y'a que la memory safety qui t'intéresse, y'a même pas besoin de sortir Rust. Java suffit.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par _kaos_ . Évalué à 3. Dernière modification le 20 février 2021 à 10:30.
Salut,
(je met le pied dedans, mais avec une bonne intention : je développe surtout en java ;) et j'espère avoir bien compris que tu ne parle pas de cet exemple)
Je ne sais pas pour rust, mais en java, dès que tu fais du jni, adieu GC et compagnie ;)
jna apporte "un peu" plus de sécurité, mais bon…
Matricule 23415
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . Évalué à 3.
Oui je sais c'est pareil en dotnet, mais je voulais pas me faire moinsser par les haïsseurs de Rust.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Memory safe : meme dans la cas multithread ?
"La première sécurité est la liberté"
[^] # Re: Pourquoi Rust ?
Posté par nokomprendo (site web personnel) . Évalué à 3.
Je pose ça là…
https://arxiv.org/pdf/2003.03296.pdf
https://internals.rust-lang.org/t/proposal-eliminate-wording-memory-safety-and-thread-safety/9416
[^] # Re: Pourquoi Rust ?
Posté par bbo . Évalué à 4.
Voilà un avis qui pourrait donc t'intéresser ;) Avis que j'ai trouvé intéressant car discutant aussi du packaging et des architectures supportées.
Pour te mettre l'eau à la bouche, je cite :
(oui, je sais, mettre cette phrase hors contexte est digne d'un vendredi)
[^] # Re: Pourquoi Rust ?
Posté par abriotde . Évalué à 0.
Cela veut dire que tu n est pas informaticien pour dire ça. Rust est le premier langage mémoire safe efficace, aussi rapide que C. Les autres consomment Ram et CPu.
Et puis Java fais des null pointer exceptions, python des gros plantages… Rust sais ce qu'il va se passer.
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Rust peut même battre Chuck Norris !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . Évalué à 3.
C'est pas le premier langage 'safe' et natif je crois, D et Pascal sont passés par là si je ne m'abuse…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Et peut être Fortran ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . Évalué à 3.
On pourrait même compter C# avec CoreRT et .NET Native…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par barmic 🦦 . Évalué à 4.
Et ocaml par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi Rust ?
Posté par lolop (site web personnel) . Évalué à 2.
En quoi Pascal est safe ?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pourquoi Rust ?
Posté par abriotde . Évalué à -1. Dernière modification le 23 février 2021 à 22:07.
Sauf que si jamais plus de 10 personnes ne se sont intéressés à ces langages il y peut-être une raison. Alors que Rust a convaincu en 10 ans Microsoft, Apple et Google des entreprises qui n avaient jamais pris un langage extérieur depuis 20 ans au moins excepté les leurs.
Alors Rust est pas magique mais il apporte quelque chose de nouveau et de puissant que l on a pas vu dans les langages informatiques depuis les Machines virtuelles avec Java (a rapproché de la révolution LLVM)
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . Évalué à 2.
Ah mais j'adore Rust, là n'est pas la question.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par David Demelier (site web personnel) . Évalué à 0.
Autant j'aime pas Rust, autant conseiller Go plutôt que Rust est plutôt culotté. Ceux deux langages n'ont absolument rien en commun. Rust est un mix entre C et C++ ultra type safe. Go est… inutile.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pourquoi Rust ?
Posté par ff9097 . Évalué à 3.
Faudrait expliquer pourquoi ces deux langages n'ont rien en commun. Et pourquoi Go serait inutile (c'est un troll mais bon).
J'ai pris l'exemple de Go car ça compile en code machine directement, c'est performant, la concurrence est très simple et le langage en lui-même est simple a apprendre et à comprendre. Mais ça pourrait être un autre choix.
[^] # Re: Pourquoi Rust ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Go et Rust ne boxe pas dans la même catégorie. Go est un langage simple, un peu comme java. La généricité vient juste d être introduit.
Rust propose des securités du niveau d ocaml, et meme plus avec le borow checker qui permet de faire de la programation parralel beaucoup plus safe. Mais il est plus complexe.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Rust ?
Posté par ff9097 . Évalué à 2.
Et donc c'est un problème ? Ça me parait plutôt un avantage.
Je sais que si les performances sont primordiales, Rust est au dessus. Mais c'est assez quand même assez rarement le cas.
[^] # Re: Pourquoi Rust ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il n y a pas que les performances. Il est difficile de faire du code générique en Go. On utilise trop souvent Interface{}, la reflexivité et la generation de code.
Go est un bon langage, ce n est pas la question.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Rust ?
Posté par abriotde . Évalué à 0.
Il n y a pas que les performances en informatique mais quand tu t embête a développer en C c est juste pour les perfs. Et la point de vue concurrence, il y a juste Pascal (archaïque) et Rust.
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Et Swift? Et D? Et Ada? Et Nim? Et Zig?
La concurrence ne manque pas.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par Lutin . Évalué à 2.
Et sur pas mal de microcontrôleur on fait du C parce qu'on n'a pas le choix.
[^] # Re: Pourquoi Rust ?
Posté par barmic 🦦 . Évalué à 2.
Le C est portable et permet d'avoir une ABI stable plus que tout autre langage.
Et tu as des gens qui maitrisent très bien le langage et l'apprécient.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Le problème du C, c'est l'outillage préhistorique.
Quand j'envisage de coder en C, je ne me dis pas oh non je vais devoir gérer la mémoire à la main ou attention avec les pointeurs, tu vas te faire planter très fort. On apprends à gérer ça en maternelle de développement.
Par contre, je me dis toujours si je le fais en C, je vais devoir me taper un système de build compliquai et gérer mes dépendances à la main.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par _kaos_ . Évalué à 3.
Salut,
Ah. Comme dit plus haut, je développe principalement en java (mais j'en fais d'autres si besoin).
Peux-tu préciser en quoi java est simple ?
Merci !
Matricule 23415
[^] # Re: Pourquoi Rust ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pas de type sum. Lambda bizarre. Pas de filtrage de motif,etc…
"La première sécurité est la liberté"
[^] # Re: Pourquoi Rust ?
Posté par _kaos_ . Évalué à 2.
Salut,
Possible avec un Visitor à priori.
C'est un argument fort. Bizarre par rapport à qui/quoi ?
Pas compris. Tu parle de quoi ?
Matricule 23415
[^] # Re: Pourquoi Rust ?
Posté par anaseto (site web personnel) . Évalué à 2.
Le filtrage par motif, c'est le nom en français du pattern matching. Ça permet de déconstruire des structures et lier des variables de façon plus déclarative, par exemple écrire un motif pour les listes qui ont au moins trois éléments et donner dans la foulée un nom à ces trois premiers éléments.
C'est sympa, particulièrement dans les langages fonctionnels. Mais ça reste au final essentiellement juste du sucre syntaxique (récursif). Quand je programme dans un langage impératif, j'en ressens pas vraiment le besoin. Si ça ne s'intègre pas naturellement dans le langage, ça ne vaut pas le coup d'introduire de nouvelles syntaxes juste pour ça, à mon avis.
[^] # Re: Pourquoi Rust ?
Posté par _kaos_ . Évalué à 3. Dernière modification le 21 février 2021 à 15:14.
Salut,
Ouais, ok. J'avais peur de prendre ça comme une remarque sur les regexp (et du coup, te prendre pour un crétin).
Bah si. Tu peux le faire en java. L'introspection te permet ça. Il y a aussi des librairies (certes contribuées), mais qui vont encore plus loin. Tu peux changer ton bytecode au runtime.
Edit : je crois que j'ai commenté à côté de la plaque :(
Matricule 23415
[^] # Re: Pourquoi Rust ?
Posté par anaseto (site web personnel) . Évalué à 3.
Héhé, non, je parlais pas des regexps :-)
C'est différent : l'introspection apporte de l'expressivité en plus au langage (au sens des choses qu'il n'est pas possible de faire sans).
Le filtrage par motif est une syntaxe déclarative pour écrire plus facilement certains types de code. Par exemple :
Une version plus impérative ferait plutôt quelque chose comme :
Après, c'est très tiré par les cheveux, c'est rare d'avoir à destructurer en profondeur juste un cas très particulier et pouvoir gérer tout le reste de façon homogène. En pratique, la différence en verbosité est moindre.
[^] # Re: Pourquoi Rust ?
Posté par _kaos_ . Évalué à 2.
Salut,
Ton exemple 1 me semble déjà presque long (et excessivement compliqué).
Pas qu'il n'ait pas d'intérêt, hein !
Mais si j'en arrive là dans mon code, je me remet en question illico : j'ai pas raté un branchement avant ?
Sur de la donnée brute, certes, ça, on peut pas éviter…
T'inquiète, les miens sont longs et ça fait des jouets quand il y a une arrivée d'une nouvelle personne au monde :p Faut juste patienter beaucoup ;)
Matricule 23415
[^] # Re: Pourquoi Rust ?
Posté par barmic 🦦 . Évalué à 4.
En fait ça devient tellement léger que tu peux te permettre de t'en servir partout. Par exemple pour destructurer un Optional. Et tu gagne en puissance quand tu as un système de type qui te permet d'ajouter de l'information de type à de la donnée à moindre coût.
Pour continuer sur Optional aujourd'hui en java il s'agit d'un objet qui contient une référence vers ta donnée. Tu as donc un objet alloué en plus et une indirection. Certains langages permettent d'avoir une sorte d'annotation de type. À ce moment là, l'aspect optional n'est plus qu'une information de type qui n'a pas à modifier la mémoire (on pourrait même envisager de faire du type erasure) au final tu a un code qui va avoir la sécurité d'un optional sans sur coût.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi Rust ?
Posté par _kaos_ . Évalué à 2.
Salut,
Et pour être plus précis, le dernier "jouet" que j'ai regardé est asm.
Un petit coup d'introspection, un coup de regexp, et paf, au runtime, tu change ton bytecode.
Toujours simpliste ?
Matricule 23415
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . Évalué à 2.
Euh vous confondez pas simple et simpliste ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par _kaos_ . Évalué à 2.
Salut,
Hmm, ouais, peut-être. My bad.
Java en soi est simple si on se contente de la base (enfin, il faut faire gaffe, y'a des pièges même à ce niveau, comme pour n'importe quel langage).
Matricule 23415
[^] # Re: Pourquoi Rust ?
Posté par barmic 🦦 . Évalué à 4.
Par rapport à la notion mathématiques de lambda. Le typage n'est pas génial par exemple, tu as du typage structurel au moment de la définition d'une lambda mais pas ensuite. Par exemple :
Ça c'est le genre de choses qui peuvent être relou est obliger à passer par :
Ce qui est assez moche.
Mais il n'y a pas que ça, l'arité des fonctions n'est pas véritablement géré ce qui contraint de temps en temps (tu ne peux pas facilement dire que tu ignore des arguments).
Dernier point au niveau syntaxique tu est obligé de présenter les paramètres même quand tu n'en a pas besoin, là où groovy par exemple ne t'y contraint pas :
Ça peut paraître être du sucre syntaxique mais c'est très pratique pour faire des DSL par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi Rust ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Un visitor ne permet aucune vérification statique d'exhaustivité.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Rust ?
Posté par barmic 🦦 . Évalué à 4.
Dans une dichotomie où on a d'un coté des langages complexes et de l'autre les langages simples, java est plutôt simple.
Pour simplifier, tu peux vouloir que ton langage soit une pièce de mathématiques très sophistiqué permettant divers manières de faire un tas de choses, proposant pleins de paradigmes différents, etc ou tu peux vouloir que ton langage soit accessible et que tout locuteur de ton langage soit capable de relire tout code écrire avec ton langage.
Dans cela java est plutôt simple, il ne cherche pas à être à la pointe de la recherche en langage, il incorpore ce qui est déjà répandu dans la communauté. Il a perdu en simplicité avec le temps et son implémentation ont permis d'effectuer des choses complexes mais on reste encore loin de ce que scala ou groovy peuvent proposer en terme de sophistication.
Ça n'est pas un mal chaque langage propose son propre choix là dedans sachant qu'il y a toujours des inconvénients.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi Rust ?
Posté par GuieA_7 (site web personnel) . Évalué à 10.
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).
[^] # Re: Pourquoi Rust ?
Posté par ff9097 . Évalué à 2.
Je vois oui, merci pour l'explication
[^] # Re: Pourquoi Rust ?
Posté par YetiBarBar . Évalué à 3.
Un "résumé" dans la langue de Shakespeare de "pourquoi pas go" pour moi.
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride
Dans les grandes lignes, go n'est pas aussi simple qu'il en a l'air, le type safety, ça compte!
Le plus gros point noir reste pour moi les comportements mal définis, votre inconsistants.
[^] # Re: Pourquoi Rust ?
Posté par David Demelier (site web personnel) . Évalué à 3.
Go est inutile parce que :
void *comme en C.deferà tout va.Il y a encore plein d'autres raisons que tu peux trouver sur les moteurs de recherche. Celles que j'ai citées sont celles qui me feront jamais utiliser ce langage.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pourquoi Rust ?
Posté par barmic 🦦 . Évalué à 6.
Il a mis un énorme coup de projecteur aux thread léger et a montré leur utilité quand ils sont bien utilisés.
Oui et non. Un gc a 2 intérêts :
Le fait d'avoir des section unsafe en rust le rend inutile ?
Les développeurs d'un langage apprécient le langage qu'ils conçoivent, chercher à l'utiliser eux-même ne me paraît pas "dingue".
C'est plus subjectif que tu ne le laisse croire. C'est bien plus explicite ce qui en fait un bon point. Je trouve personnellement que ça s'intègre bien dans la philosophie simple du langage pas trop d'abstraction et pas de bizarrerie utilisateur qui s’exécute silencieusement. Ça a d'autres inconvénients je suis d'accord.
Oui la simplicité de la compilation croisée, la bibliothèque standard plutôt conséquente, son apprentissage plutôt rapide,…
Tu vois moi ce que je trouve dingue, c'est pourquoi les développeurs qui apprécient un langage ont besoin de pourrir les autres. Je ne suis pas un grand fan de go, je m'en sert personnellement très peu, mais pour des endroits où je ne veux aucune dépendance et/ou il remplace un script qui sera plus long où consommera un peu plus de ressources (sur rpi ou en starter dans un conteneur docker ou pour certains contexte où le temps de démarrage de python est plus important que le temps de calcul de mon code) et il ne m'a pas fallut de temps d'apprentissage pour faire ça. Là où rust demande plusieurs semaines/mois pour devenir confortable avec le langage.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi Rust ?
Posté par abriotde . Évalué à 0.
Pour moi il remplace Java avec que des avantages. Et en terme de perfs il est au même niveau que Java.
[^] # Re: Pourquoi Rust ?
Posté par fork_bomb . Évalué à 1.
Le problème, en Go, est que tu peux avoir des NullPointerExceptions en écrivant du code normal. En rust, comme tu l’indiques, le « problème » est limité à des sections de code très précises que tu peux analyser avec plus d’attention.
C’est d’autant plus dommage que ce problème n’existe pas dans les autres langages récents (typescript, swift, etc.).
[^] # Re: Pourquoi Rust ?
Posté par anaseto (site web personnel) . Évalué à 2.
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.
[^] # Re: Pourquoi Rust ?
Posté par anaseto (site web personnel) . Évalué à 5.
Utiliser des clôtures ou des structures de données cycliques est très pénible sans GC. Pour les structures, le besoin n'est pas forcément fréquent, mais les clôtures, j'en utilise souvent.
Il n'y a pas de pointeurs du style void * comme en C, non. Ce qu'il y a, c'est un type interface particulier qui peut être utilisé comme une version restreinte et plus explicite du concept de variable en Python ou autres langages dynamiques. C'est très différent. Ça représente rarement une portion significative du code et, même lorsque c'est utilisé, c'est le plus souvent à l'aide de type-switchs qui ne peuvent pas provoquer d'erreurs au runtime.
Chose qui peut s'appliquer à n'importe quel gros projet : impossible de satisfaire tous les utilisateurs. Il y en aura toujours pour se sentir oubliés parce qu'ils n'ont pas écoutés, mais ils oublient souvent que leurs besoins sont en conflits avec ceux d'autres utilisateurs, ou simplement non prioritaires. Par exemple, les utilisateurs de Rust et C++ qui aiment la compilation rapide pourraient se sentir oubliés. Leurs préférences sont juste en conflit avec celles d'autres utilisateurs du langage.
C'est un désavantage en partie, mais bon, tu as gccgo aussi. Personnellement, je trouve que les avantages compensent largement les inconvénients : c'est un compilateur facile à maintenir par n'importe quel utilisateur du langage et qui compile en à peine une minute sur de vieilles machines (bref, ça m'est techniquement accessible, contrairement au compilateur Rust, par exemple).
C'est l'impression que tu donnes en effet, celle de n'avoir jamais utilisé ce langage, mais d'être capable de le juger comme « inutile » sur la base d'une compréhension qui n'est pas basée sur un apprentissage du langage. C'est courant comme chose à faire mais, perso, je ne comprends pas.
Et puis, personnellement, si je devais me faire une idée sur un langage que je ne connais pas, je serais méfiant de m'appuyer sur des arguments techniques sortis de contexte et peut-être mal compris. Surtout pour un langage qui est quand même utilisé pour faire plein de choses. L'argument d'autorité n'est pas fiable en lui-même, mais dis-toi quand même que Go est utilisé avec satisfaction par plein de monde, pas forcément que des ignorants, et ses propres créateurs ont un bon bagage dans le domaine. De quoi se dire qu'un jugement rapide risque fortement d'être incorrect.
Perso, d'expérience, avec les langages de programmations, il y a deux types de personnes qui les détestent : ceux qui ne les ont pas utilisé, mais ont des préjugés basés sur leurs préférences dans des contextes qui ne s'appliquent pas ; et ceux qui ont été forcés de les utiliser dans un projet mal bâti.
[^] # Re: Pourquoi Rust ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Les createurs de Go n'ont jamais voulu l'aide des chercheurs en langages par exemple. Au contraire de Rust.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 22 février 2021 à 15:39.
Source?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par barmic 🦦 . Évalué à 2.
C'est le cas de beaucoup de langages parmi les plus populaires.
Je comprends tout à fait que go soit critiquable, mais balancer qu'il est inutile pour autant me semble faux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi Rust ?
Posté par anaseto (site web personnel) . Évalué à 2.
Ce n'est pas mon impression, je ne sais pas où tu as lu ça. Mon impression, c'est qu'ils ne mettent pas la priorité sur la théorie des types, qui n'est qu'une branche parmi d'autres en théorie des langages (juste un peu à la mode sur reddit et quelques forums, en partie grâce à Rust).
Un langage à la pointe en théorie des types fera des sacrifices ailleurs : les chercheurs ne visent pas à faire un langage pour le rendre le plus productif possible, ils visent à faire un langage qui développe leur théorie (des types ou des langages extensibles ou autre). Tout prendre (types évolués + macros + performant + simple etc.) n'est a priori pas plus raisonnable (ni possible) d'un point de vue design de langage pratique.
[^] # Re: Pourquoi Rust ?
Posté par nokomprendo (site web personnel) . Évalué à 2.
Perso, c'est peut-être le principal avantage que je trouve à Rust. Mais bon ça casse pas 3 pattes à un canard non plus. Rust supporte les types algébriques et les type-classes mais il n'y a pas de HKT comme en Haskell ni de module comme en OCaml.
[^] # Re: Pourquoi Rust ?
Posté par anaseto (site web personnel) . Évalué à 3.
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…
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Go a choisi de faire simple. C'est peut être frustrant, mais c'est peut être la stratégie gagnante.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
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.
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Je connais beaucoup de projets majeurs en Go (Kubernetes, les outils d'Hashicorp, Docker, Grafana) et d'autres très sympathiques (Caddy, Maddy), mais très peu en Rust (Deltachat, un bout de Firefox).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par GuieA_7 (site web personnel) . Évalué à 3.
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.
[^] # Re: Pourquoi Rust ?
Posté par ff9097 . Évalué à -1.
Il faudra y passer si on souhaite toujours attirer des contributeurs le jour où Rust aura pris une grosse place.
Je me vois bien contribuer un jour a un projet Rust mais le C hors de question.
[^] # Re: Pourquoi Rust ?
Posté par GuieA_7 (site web personnel) . Évalué à 5.
Alors oui, si on pouvait d'un coup de baguette magique transformer le code de Gimp en Rust, et au passage faire que ses contributeurs soient aussi expérimentés en Rust qu'en C, ça serait trop cool.
Mais en pratique c'est déjà souvent compliqué de financer le développement de logiciel libre (Gimp par exemple, et pourtant C est populaire, comme quoi ça ne suffit pas). Donc expliquer aux gens de Gimp "hey passez les 20 prochaines années à réécrire le logiciel, et là peut-être que je vais faire une contribution" illustre bien le problème.
[^] # Re: Pourquoi Rust ?
Posté par ff9097 . Évalué à 1.
C'est comme la migration Gtk3, il faudra bien y aller un jour. Pas besoin de faire un focus sur ça mais ça peut être fait petit à petit.
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ce n'est pas arbitraire: la popularité d'un langage, ce n'est pas la popularité d'une pop star.
Un langage utilisé massivement, ça veut dire de la documentation, du support, des bibliothèques, des développeurs…
Je ne sais pas si PHP avait une stratégie, mais en tout cas il fait partie des gagnants sur le web :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par GuieA_7 (site web personnel) . Évalué à 1.
c'est arbitraire de décider que c'est LE critère pour décider d'un gagnant, alors qu'il y a à la fois des tas de critères intéressants, et pas besoin de décider d'un gagnant entre 2 outils qui ne résolvent pas les même problèmes ("je dois absolument décider d'un gagnant entre ma fourchette et mon parapluie").
Une star plus populaire ça veut dire plus de moyens financiers pour les concerts/clips, plus d'opportunités d'avoir des produits dérivés, de trouver des fan arts, de rencontrer d'autre fans et se faire des amis. Donc au contraire c'est un très bon critère pour choisir une star en un sens ; mais là encore ça serait vraiment dommage de choisir uniquement comme ça…
[^] # Re: Pourquoi Rust ?
Posté par Thomas Douillard . Évalué à 2.
J’ai envie de suivre la tradition linuxfrienne de faire une substitution de ton commentaire en remplaçant PHP par Johnny et quelques autres
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . Évalué à 2.
Ben c'est logique, ça dépend surtout du fait que Go est beaucoup plus vieux.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Il y a des vieux langages qui n'ont pas connu de succès :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . Évalué à 1.
Il dit qu'il voit pas le rapport.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par barmic 🦦 . Évalué à 3.
Les premières versions publiques n'ont que 3 ans d'écart (2009 pour go et 2012 pour rust) tout comme les premières versions dites stables sont arrivées en 2012 pour go et 2015 pour rust.
Docker est créé en 2013 soit 4 ans après la première version publique de go ou un an après sa première version stable. La première version de graphana c'est 2014.
Du coup j'ai pas l'impression que l'argument de l'âge soit très pertinent.
Après est-ce qu'avoir un fleuron est un gage de qualité ou d'intérêt du langage, je ne suis pas sûr.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . Évalué à 3.
Je ne sais pas non plus si ça a grand intérêt. Peut-être est-ce utile pour certains afin se rassurer (ouf! Rust le-langage-dont-je-ne-sais-rien-si-ce-n'est-que-je-l'aime-pas n'a pas encore de flag ship ça fait du bien à mon ego)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par abriotde . Évalué à 1.
Je pense que Google a suffisamment de chercheurs en interne.
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5. Dernière modification le 21 février 2021 à 16:57.
Il n'a jamais été nécessaire d'avoir un GC. C'est juste la méthode la plus "automagique".
Sur le sujet:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par abriotde . Évalué à 0.
Go compile mais avec un JVM embarqué, Go remplace Java ( y compris en terme de perf) Rust remplace C.
[^] # Re: Pourquoi Rust ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Go compile avec une Java Virtual Machine embarqué ? :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi Rust ?
Posté par abriotde . Évalué à 0.
Oui c est exactement ce qui est fait sur le principe.
[^] # Re: Pourquoi Rust ?
Posté par lolop (site web personnel) . Évalué à 3.
Est-ce que vous avez lu l'article ?
Là ils donnent juste un exemple de code qui a été écrit dans un langage «memory-safe», en l'occurrence en Rust, mais ils n'indiquent pas qu'ils ne vont financer que des projets en Rust.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.