Pourtant Rust n'a pas de concurrent sérieux. Il est plus sécurisé que le C et aussi rapide soit plus rapide que le C++ alors forcément plus que le Java et infiniment plus que Python et consort…
En contrepartie évidemment, il est plus complexe et moins productif que les langages interprété. Mais avec un peu d'entrainement, il est même plus productif que C et autant que C++. Autrement dit, il est mieux que C et C++, Java… mais pas concurrent de Python, Go, PHP, etc…
Après évidemment pour un vieux projet en C, C++ ou Java cela ne vaut peut-être pas le coup de tout réécrire.
Rust a des concurrents sur le marché du plus sûr que du C et performant quand même, certains sont à la mode (Go, Swift), d'autres plus confidentiels (D, Nim), en développement (Crystal, Zig) ou anciens (Ada, Pascal, Objective C)…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Go, Swift : Bah c'est comme du Java (Avec garbage-collector) : Performant mais pas autant que C et beaucoup plus lourd binairement parlant et beaucoup plus consommateur de RAM. C'est bien pour des application serveurs mais pas poour de l'embarqué, ou de la haute performances : Carte graphique : Jeux vidéos, IA, pilotes, calculs hautes perfs aux ressources limités…
D, Nim, Crystal, Zig, Pascal, Objective C : Ce sont des concurent de C, mais ils ne sont pas mémory-safe comme Rust.
Ada : Oui top, mais moins productif encore que Rust. Ca n'est nécessaire que quand le plantage logiciel ou même la simple erreur de programme met en jeu des vies humaines (Ou des milliards): Aéronautique, spatial, et parfois dans le transport…
PS : Il n'y a qu'a voir pourquoi Linus Torwald, la maison Blanche, Google (Qui avait développé son concurrent Go) ne jurent maintenant que par Rust. Ce n'est pas parce que c'est hype. C'est parce qu'il y a dans Rust quelques chose de plus qu'il n'y a pas dans les autres concurrents.
PS2 : Alors oui, il se développe quelques langage qui reprennent les concepts Rust et qui sont aussi bien… mais Rust est maintenant le leader, alors je doute qu'il percent réellement sans killer feature.
Il n'y a qu'a voir pourquoi Linus Torwald, la maison Blanche, Google (Qui avait développé son concurrent Go) ne jurent maintenant que par Rust.
Linus Torvalds qui persiste et signe quand il dit que le noyau Linux restera écrit en C, et que le C reste le meilleur langage pour du développement d'OS ne jure que par Rust ? T'as des sources ?
Les politiciens de la maison blanche, on s'en cogne un peu.
Google ne jure pas que par Rust, ils continuent de maintenir Go et ils ont même démarré Carbon en plus.
Tu entends quoi par "langage productif" ? (Et en quoi l'Ada est un langage moins productif ?)
Pour peu qu'on soit un peu à l'aise avec le langage, avec on développe aussi vite qu'en C&cie, et ça s'apprend bien plus vite que le Rust.
"Memory safe" : tout les langages avec GC sont memory safe, Python, C#, Javascript, D, Go, etc…
"Type safe" : tout les langages avec un système de type statique et strict sont type safe, Haskell, Standard ML, Java, etc…
Pour ce qui est des performances, cela va dépendre des algos, du développeur, et des choix fait par les designers du langage et de la librairie standard.
Par exemple, c'est bien connu que la HashMap avec l'algorithme de hashage par défaut de Rust est très lente.
"Pas de concurrent sérieux" c'est juste une ineptie totale.
Pour ce qui est des performances, cela va dépendre des algos, du développeur, et des choix fait par les designers du langage et de la librairie standard.
D'accord mais à algorithme équivalent Rust l'emporte. Et un développeur veut que son programme tourne le plus vite possible sans passer trop de temps à l'optimiser. S'il faut 3 jours de dev en Python pour faire l'équivalent en Rust en 1 jours. Et il y a autre chose, dans un pilote, rajouter une JVM n'est pas envisageable. Et si c'est possible sur un serveur, c'est de la maintenance en plus, d’où la préférence de Go pour sa maintenance simplifié.
T'inquiètes, je pense que des experts se penchent sur chaque détails de chaque langages pour les optimiser avec les dernières techno de pointe. Python, PHP, Java, C, Rust améliorent chaque jours leurs perfs. Si la HashMap avec l'algorithme de hashage par défaut de Rust est très lente ça ne durera pas.
Si la HashMap avec l'algorithme de hashage par défaut de Rust est très lente ça ne durera pas.
Bah si, ça durera. Car c'est l'idée même de cette fonction de hashage, être cryptographiquement solide, cela veut donc dire exécution en temps constant (pour ne pas leak des infos sur la données en fonction du temps d'exécution). Elle ne sera donc jamais pus performante qu'un dict Python, car la team de Rust préfère fournir quelque chose de sécurisé par défaut.
La performance ça ne fait pas tout. Surtout quand tu es dans du IO bound et non du CPU bound (aka: tu passes plus de temps à attendre une réponse de la base de données qu'à faire des calculs).
C'est d'ailleurs pourquoi Java, Python, et Go sont très présents.
Tout langage à garbage collector / interprété est mémory-safe mais ce n'est pas le problème. Le problème c'est qu'ils sont lent. Et en plus Rust apporte un peu plus que ça. Il évite plus que Rust le "Out-of-memory" et surtout "Null-pointer-exception" qui est très commun en Java.
En gros Java crash sans corrompre la mémoire là ou Rust ne crash pas (ou quasiment pas) il s'arrête "proprement" sur une erreur consciemment non gérée.
Je croyais me moquer (et surtout taquiner devnewton), mais ton commentaire montre que « memory safe » mérite d’être explicité un peu. Je doute que Rust augmente automagiquement la quantité de mémoire disponible (le sens littéral de « Out Of Memory » étant que le programme n’a pas assez de mémoire pour continuer son exécution.) La vache, Rust peut aussi utiliser énormément de mémoire, et y a des gens qui s’en plaignent ou juste s’interrogent et sont surpris. À moins que tu sois un des fanboys auquel devnewton fait allusion ? ;)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Aucun programme dans un OS de ses 30 dernières années pourrait corrompre la mémoire comme ça. On est plus en 1990.
Il évite plus que Rust le "Out-of-memory"
Non quelque soit le langage si l'OOM killer veut ta peau il l'aura. rust ne fait rien et ne peut rien faire contre le fait que le système considère qu'il a besoin de libérer de la mémoire. Java te permet juste par configuration de choisir qu'elle est la mémoire maximum utilisée.
"Null-pointer-exception" qui est très commun en Java
C'est l'erreur à un milliard de dollars d'Hoare. C'est évité en rust ce qui est vachement cool, mais quand on parle de sécurité de la mémoire c'est quand comme en C à partir de ce même problème (le fait d'avoir un pointer ou une référence qui ne pointe pas de la mémoire valide) peut causer des choses bien plus graves qu'un crash.
Rust ne crash pas (ou quasiment pas) […]
Bien sûr que si. C'est de l'ordre du fantasme de croire qu'il ne crash pas.
Rust ne crash pas (ou quasiment pas) il s'arrête "proprement" sur une erreur consciemment non gérée.
J'ai aucune idée de ce que signifie s'arrêter proprement particulièrement quand on ne gère pas. D'autant plus quand tu dis que c'est plus que ce que font des langages à runtime comme java pour le quel la JVM fait pas mal de choses.
Posté par abriotde .
Évalué à -6 (+0/-7).
Dernière modification le 17 mars 2024 à 21:12.
Aucun programme dans un OS de ses 30 dernières années pourrait corrompre la mémoire comme ça
Bien sûr que si. La seul chose c'est qu'effectivement l'OS limite le phénomène et généralement la corruption est limité au programme qui tourne et arrive très rarement aux autres programmes/drivers et exceptionnellement à l'OS.
Non quelque soit le langage si l'OOM killer veut ta peau il l'aura
Bien sûr que Rust consomme de la mémoire, mais en quantité plus limité surtout il évite en grande majorité ce que l'on appel la fuite mémoire. La fuite mémoire c'est quand tu alloue de la mémoire en boucle sans jamais la libéré. Or en Java comme tu sais que tu ne peux pas "oublier" de libérer la mémoire gâce au garbage collector, naturellement, tu fais moins attention. En Rust, cette fuite est possible mais bien moins courante car il le programme doit prévoir de libérer sa mémoire par conception. Mais évidemment si tu fait un appel récursif infini (Ou trop important..) par exemple, fatalement, dans un cas comme dans l'autre tu crash.
PS : l'OOM killer, est une "option" sous Linux (par défaut sur la plupart des distribs) mais pas toujours présente. Il est une sécurité pour éviter de crasher l'OS faute de mémoire.
Null-pointer-exception
Oui bien sûr qu'un accès null-pointer en C est bien plus grave en C qu'en Java, reste que c'est un plantage dû à la mémoire indésirable quelques soit le programme.
En Java en gros on quitte "Proprement", sans corrompre la mémoire contrairement à C. Mais en Rust, on a une exception que l'on est censé traité. Evidemment si on la traite pas on est comme en Java. Mais la différence n'est pas négligeable.
J'ai aucune idée de ce que signifie s'arrêter proprement particulièrement quand on ne gère pas.
C'est simple, quand un programme crash il fait n'importe quoi autrement dis il peut faire du dégât comme en C ou il peut aller ailleurs dans la mémoire et écraser tout et n'importe quoi. Mais pire, il peut ne pas planter, et continuer avec des donner qu'il a totalement pourri. Souvent d'ailleurs le crash réel intervient longtemps après.
En Rust et en Java on a une exception. La mémoire n'est pas corrompu et si on gère "l'exception" on peut utiliser les données car elles restent bonnes (Elles n'ont pas été altérées par le programme).
Evidemment, en Rust comme en Java, tu peux par bug, faire entrer le programme dans un comportement impossible et corrompu malgré tout (Par exemple mettre 400° dans un angle censé être entre 0 et 360). Ada est le langage ultime pour ça mais il est encore bien moins productif…
Tu ne prouve que ton manque de compréhension de ce dont tu parle.
Bien sûr que si. La seul chose c'est qu'effectivement l'OS limite le phénomène et généralement la corruption est limité au programme qui tourne et arrive très rarement aux autres programmes/drivers et exceptionnellement à l'OS.
Non et ce n'est pas généralement si ça existe c'est un bug enregistré dans une CVE a haute priorité.
La fuite mémoire c'est quand tu alloue de la mémoire en boucle sans jamais la libéré. Or en Java comme tu sais que tu ne peux pas "oublier" de libérer la mémoire gâce au garbage collector, naturellement, tu fais moins attention. En Rust, cette fuite est possible mais bien moins courante car il le programme doit prévoir de libérer sa mémoire par conception. Mais évidemment si tu fait un appel récursif infini (Ou trop important..) par exemple, fatalement, dans un cas comme dans l'autre tu crash.
Les cas de fuites mémoire en java sont identiques en rust. Rust ne te demande pas de prévoir la libération, il s'assure qu'une zone mémoire n'a qu'un et un seul propriétaire a aucun moment il ne fait quoi que ce soit pour que ce propriétaire ne garde que ce dont il a besoin.
PS : l'OOM killer, est une "option" sous Linux (par défaut sur la plupart des distribs) mais pas toujours présente. Il est une sécurité pour éviter de crasher l'OS faute de mémoire.
Qu'elle distribution retire cette option ?
Mais en Rust, on a une exception que l'on est censé traité.
Et comme elle ne s'appelle pas NullPointerException ça n'a rien à voir ?
C'est simple, quand un programme crash il fait n'importe quoi autrement dis il peut faire du dégât comme en C ou il peut aller ailleurs dans la mémoire et écraser tout et n'importe quoi. Mais pire, il peut ne pas planter, et continuer avec des donner qu'il a totalement pourri. Souvent d'ailleurs le crash réel intervient longtemps après.
Un crash de programme n'est pas propre quand il ne crash pas ?
En Rust et en Java on a une exception. La mémoire n'est pas corrompu et si on gère "l'exception" on peut utiliser les données car elles restent bonnes (Elles n'ont pas été altérées par le programme).
Tout le monde se fout de la mémoire au moment d'un crash. Éventuellement tu peux demander à la jvm de la dumper pour un post-mortem, mais corrompre sa mémoire lors d'un crash n'a pas de sens. Le processus est en cours de libération, le noyau va nettoyer les pages mémoires qui lui était allouées (non pas pour une question de corruption, mais pour éviter la fuite de données quand les pages seront réutilisées).
Evidemment, en Rust comme en Java, tu peux par bug, faire entrer le programme dans un comportement impossible et corrompu malgré tout (Par exemple mettre 400° dans un angle censé être entre 0 et 360). Ada est le langage ultime pour ça mais il est encore bien moins productif…
C'est s'arrêter proprement. Peut être pas volontairement pour le programmeur. Java fait pareil. Mais ils ne corrompent pas la mémoire autour pour autant.
Par contre en Rust pour générer un pannic! il faut normalement faire un ".unwrap()" ou quelque chose de cet ordre. Autrement dis explicitement dire "bah tu t'arrête". Autrement dis c'est clairement que volontairement tu a voulu ne pas géré le plantage. En Java, tu n'a rien qui te préviens et tu ne peux pas t'ammuser à tester chaque pointeur. Et même si tu le fais, tu va en oublier…
Mais l'avantage de Rust sur Java, c'est surtout sa vitesse d'exécution. Autrement dis : "Rust gère mieux la mémoire et surtout va beaucoup plus rapidement pour une productivité similaire"… Evidemment, encore une fois, tout est compromis entre productivité et vitesse d'exécution en langage informatique.
S'arrêter proprement c'est relâcher les resources que l'on a acquise (file descriptor, socket, …) avant l'arrêt effectif. Ou plus communément appelé : "graceful shutdown".
Si ton serveur derrière le socket s'attend à ce que tu lui envoie goodbye avant de fermer le socket, c'est pas l'OS qui va le faire pour toi.
Par contre en Rust pour générer un pannic! il faut normalement faire un ".unwrap()" ou quelque chose de cet ordre.
Oue, il faudrait avoir fait un peu de Rust en fait avant de parler de Rust.
La fonction .unwrap() existe pour les types Result<T, E> et Option<T>. Elle génère effectivement un panic! si le Result<T, E> contient Err(E), ou si le Option<T> contient None.
De la même manière, Result<T, E> a une fonction .unwrap_err() qui génère un panic! si le Result<T, E> contient Ok(T).
C'est pas inné au langage, c'est un design d'API. Un autre design c'est que toutes les allocations faites par la stdlib génèrent un panic! si l'allocation échoue, à savoir notamment :
Box::new(...)
Vec::push(...)
etc…
Note qu'il existe aussi Box::try_new(...) qui au lieu de générer un panic! va retourner un Result<T, E> avec Ok(Box<T>) ou Err(OutOfMemory). Et bien sûr, équivalent pour toutes fonctions allouant de la mémoire.
Mais tout ça, c'est au delà de ce que je disais, à savoir :
Au moins Java est stable binairement … J'aime bien Rust, mais pour remplacer le C, ou avoir sa place dans les foutus gros logiciels d'entreprise, il lui faut une ABI stable, et si possible, simple. Est-ce seulement possible ?
En Java on va pouvoir binder avec du code natif, sans "glue" native. Ça pourrait changer pas mal de choses.
Java n'est pas si stable binairement en tout cas beaucoup moins que C. C est stable sur 30 ans au minimum alors que va faire tourner un programme compilé en Java 3 sur une JVM Java 8… Ca marchera pas car il n'est pas stable (surtout les libs).
C'est aussi un autre problème de Java: Il est dépendant d'une JVM à la bonne version et avec les bonnes lib (Peut-être peut-on les compiler en statique en Java?).
En Rust, c'est la config du compilo qui décide de l'OS sur lequel il va tourner. et pour les libs tu peux les compiler en statique.
Le problème fondamental c'est qu'un programme C ou Rust écris il y a 20/50 ans peut tourner tel quel sur une machine moderne juste en étant recompilé. En Java, il faut soit installer une vielle JVM (Avec les lib) et toutes leurs failles non maintenus soit, migrer le code dans la dernière version de Java.
C'est le même problème que tous les langages interprété à la différence que la JVM reste plus stable binairement que Python, PHP et consorts (Car ils sont interprété et donc sensible au moindre changement de syntaxe).
Pour cette raison entre autre, je préfère encore le Go au Java (Pour plus de productivité que Rust).
Bien sûr tu n'en trouves pas. Mais tu sais que si tu installe un vieux compilo sur un PC tu pourra compiler ton programme comme on le fait avec n'importe quel programme C/C++ ou autre programme compilé. C'est inhérent aux langages compilés. Généralement ils ont un mode de rétro-compatibilité (-c89 pour comilé un programme C de la norme 1989) et sinon tu peux installer le binaire de 1989 sur un PC récent et le recompilé. Le compilateur n'a pas (ou très difficilement) des failles de sécurité.
Alors que trouver un compilo Java qui te produit un binaire compatible JVM8 pour un programme Java aux normes de 1990, c'est une autre paire de manche. Je me trompe peut-être mais ça n'existe pas à ma connaissance.
PS : c'est pire avec un langage interprété comme Python. Il est totalement impossible de faire tourner un programme Python1 sur un Python3.
Bref, l'idée est de dire que la compatibilité binaire d'un programme compilé, n'est généralement pas un problème.
En fait le vrai problème, existe : La compatibilité binaire des librairies Rust pour des programme C (l'inverse est moins vrai). Actuellement c'est un point noir pour lequel Google à donné 1 million de dollars mais il sera résolu.
Mais c'est pire en Java, c'est impossible à ma connaissance: appeler un binaire Java avec un programme C qui a prévu d'appeler un librairie C (Même en le voulant dans le code C, ça doit être bien galère). Et se problème se pose juste parce que l'on veut remplacer C au plus vite morceau par morceau. Ce n'est pas un problème Rust à la base.
Mais c'est pire en Java, c'est impossible à ma connaissance: appeler un binaire Java avec un programme C qui a prévu d'appeler un librairie C (Même en le voulant dans le code C, ça doit être bien galère).
C'est pas ce que faisait OpenOffice dans le temps ?
Le problème de la stabilité binaire est abordé de façon différente en Java. Par exemple, avec Java 1.1 de Sun, les calculs arithmétiques sont binairement identique, quelque soit la FPU HW… D'où des perfo pas terrible et de nombreuses critiques.
Si tu dis "Java n'est pas stable binairement", tu dois le prouver concrètement, nous utilisons des binaires de 2007 aujourd'hui, pas de problèmes.
L'importance d'avoir une ABI stable :
Binding stable ;
Pour certains programmes d'analyse numérique, les dépendances, la version du compilateur et les options de compilation doivent être contrôlées. Donc le binaire est la forme la plus simple de partage ;
Temps de compilation, mise en route, lorsque tu utilises des tonnes de dépendances ;
C n'a rien de stable "binairement", vu que c'est dépendant de l'implémentation :-)
La rétrocompatibilité de Java est excellente au contraire et tu as de bonnes chances de faire tourner de vieux programmes avec un JRE récent, mais il y a des limites : une API dépréciée finira toujours par être retirée à un moment ou un autre et il est imprudent de ne pas mettre à jour son programme au moins une fois par an.
La dépendance à un runtime pose des problèmes, car les OS ne font pas leur boulot.
Le problème fondamental c'est qu'un programme C ou Rust écris il y a 20/50 ans peut tourner tel quel sur une machine moderne juste en étant recompilé. En Java, il faut soit installer une vielle JVM (Avec les lib) et toutes leurs failles non maintenus soit, migrer le code dans la dernière version de Java.
Un vieux programme C jamais mis à jour aura des problèmes similaires : il dépendra d'un vieux gcc, d'un vieux make…
# Et en plus
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+2/-1).
Java est vraiment memory safe lui !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et en plus
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Comprendre que les OutOfMemoryError sont des exceptions ? (…du coup on peut ranger EMAT et consort au placard ?) Ou tu parles d’autre chose ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et en plus
Posté par devnewton 🍺 (site web personnel) . Évalué à 1 (+1/-3).
Je me moque de la propagande des rust fanboys :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et en plus
Posté par abriotde . Évalué à -2 (+2/-6).
Pourtant Rust n'a pas de concurrent sérieux. Il est plus sécurisé que le C et aussi rapide soit plus rapide que le C++ alors forcément plus que le Java et infiniment plus que Python et consort…
En contrepartie évidemment, il est plus complexe et moins productif que les langages interprété. Mais avec un peu d'entrainement, il est même plus productif que C et autant que C++. Autrement dit, il est mieux que C et C++, Java… mais pas concurrent de Python, Go, PHP, etc…
Après évidemment pour un vieux projet en C, C++ ou Java cela ne vaut peut-être pas le coup de tout réécrire.
[^] # Re: Et en plus
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+4/-1).
Rust a des concurrents sur le marché du plus sûr que du C et performant quand même, certains sont à la mode (Go, Swift), d'autres plus confidentiels (D, Nim), en développement (Crystal, Zig) ou anciens (Ada, Pascal, Objective C)…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et en plus
Posté par abriotde . Évalué à -4 (+2/-7).
Non :
PS : Il n'y a qu'a voir pourquoi Linus Torwald, la maison Blanche, Google (Qui avait développé son concurrent Go) ne jurent maintenant que par Rust. Ce n'est pas parce que c'est hype. C'est parce qu'il y a dans Rust quelques chose de plus qu'il n'y a pas dans les autres concurrents.
PS2 : Alors oui, il se développe quelques langage qui reprennent les concepts Rust et qui sont aussi bien… mais Rust est maintenant le leader, alors je doute qu'il percent réellement sans killer feature.
[^] # Re: Et en plus
Posté par David Delassus (site web personnel) . Évalué à -6 (+5/-13). Dernière modification le 20 mars 2024 à 15:10.
Linus Torvalds qui persiste et signe quand il dit que le noyau Linux restera écrit en C, et que le C reste le meilleur langage pour du développement d'OS ne jure que par Rust ? T'as des sources ?
Les politiciens de la maison blanche, on s'en cogne un peu.
Google ne jure pas que par Rust, ils continuent de maintenir Go et ils ont même démarré Carbon en plus.
[phrase retirée par la modération]NdM: commentaire édité par la modération
https://link-society.com - https://kubirds.com
[^] # Re: Et en plus
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Merci de rester courtois dans les échanges.
[^] # Re: Et en plus
Posté par Lutin . Évalué à 7 (+5/-0).
Tu entends quoi par "langage productif" ? (Et en quoi l'Ada est un langage moins productif ?)
Pour peu qu'on soit un peu à l'aise avec le langage, avec on développe aussi vite qu'en C&cie, et ça s'apprend bien plus vite que le Rust.
[^] # Re: Et en plus
Posté par David Delassus (site web personnel) . Évalué à 6 (+5/-1).
"Sécurisé" ça veut tout et rien dire.
Rust a 2 types de sécurités :
Pour ce qui est des performances, cela va dépendre des algos, du développeur, et des choix fait par les designers du langage et de la librairie standard.
Par exemple, c'est bien connu que la HashMap avec l'algorithme de hashage par défaut de Rust est très lente.
"Pas de concurrent sérieux" c'est juste une ineptie totale.
https://link-society.com - https://kubirds.com
[^] # Re: Et en plus
Posté par abriotde . Évalué à -3 (+1/-5).
D'accord mais à algorithme équivalent Rust l'emporte. Et un développeur veut que son programme tourne le plus vite possible sans passer trop de temps à l'optimiser. S'il faut 3 jours de dev en Python pour faire l'équivalent en Rust en 1 jours. Et il y a autre chose, dans un pilote, rajouter une JVM n'est pas envisageable. Et si c'est possible sur un serveur, c'est de la maintenance en plus, d’où la préférence de Go pour sa maintenance simplifié.
T'inquiètes, je pense que des experts se penchent sur chaque détails de chaque langages pour les optimiser avec les dernières techno de pointe. Python, PHP, Java, C, Rust améliorent chaque jours leurs perfs. Si la HashMap avec l'algorithme de hashage par défaut de Rust est très lente ça ne durera pas.
[^] # Re: Et en plus
Posté par David Delassus (site web personnel) . Évalué à 6 (+4/-0).
Bah si, ça durera. Car c'est l'idée même de cette fonction de hashage, être cryptographiquement solide, cela veut donc dire exécution en temps constant (pour ne pas leak des infos sur la données en fonction du temps d'exécution). Elle ne sera donc jamais pus performante qu'un dict Python, car la team de Rust préfère fournir quelque chose de sécurisé par défaut.
La performance ça ne fait pas tout. Surtout quand tu es dans du IO bound et non du CPU bound (aka: tu passes plus de temps à attendre une réponse de la base de données qu'à faire des calculs).
C'est d'ailleurs pourquoi Java, Python, et Go sont très présents.
https://link-society.com - https://kubirds.com
[^] # Re: Et en plus
Posté par abriotde . Évalué à -4 (+0/-5).
Tout langage à garbage collector / interprété est mémory-safe mais ce n'est pas le problème. Le problème c'est qu'ils sont lent. Et en plus Rust apporte un peu plus que ça. Il évite plus que Rust le "Out-of-memory" et surtout "Null-pointer-exception" qui est très commun en Java.
En gros Java crash sans corrompre la mémoire là ou Rust ne crash pas (ou quasiment pas) il s'arrête "proprement" sur une erreur consciemment non gérée.
[^] # Et en moins
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à -1 (+5/-8).
Je croyais me moquer (et surtout taquiner devnewton), mais ton commentaire montre que « memory safe » mérite d’être explicité un peu. Je doute que Rust augmente automagiquement la quantité de mémoire disponible (le sens littéral de « Out Of Memory » étant que le programme n’a pas assez de mémoire pour continuer son exécution.)
La vache, Rust peut aussi utiliser énormément de mémoire, et y a des gens qui s’en plaignent ou juste s’interrogent et sont surpris. À moins que tu sois un des fanboys auquel devnewton fait allusion ? ;)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et en moins
Posté par Joalland . Évalué à 6 (+4/-0).
Tes deux derniers liens parle d'un jeu vidéo qui s'appelle Rust et qui n'a rien avoir avec le langage de programmation Rust.
[^] # Re: Et en moins
Posté par Joalland . Évalué à 7 (+5/-0).
En fait tes 3 derniers liens.
[^] # Re: Et en plus
Posté par barmic 🦦 . Évalué à 6 (+4/-0).
Aucun programme dans un OS de ses 30 dernières années pourrait corrompre la mémoire comme ça. On est plus en 1990.
Non quelque soit le langage si l'OOM killer veut ta peau il l'aura. rust ne fait rien et ne peut rien faire contre le fait que le système considère qu'il a besoin de libérer de la mémoire. Java te permet juste par configuration de choisir qu'elle est la mémoire maximum utilisée.
C'est l'erreur à un milliard de dollars d'Hoare. C'est évité en rust ce qui est vachement cool, mais quand on parle de sécurité de la mémoire c'est quand comme en C à partir de ce même problème (le fait d'avoir un pointer ou une référence qui ne pointe pas de la mémoire valide) peut causer des choses bien plus graves qu'un crash.
Bien sûr que si. C'est de l'ordre du fantasme de croire qu'il ne crash pas.
J'ai aucune idée de ce que signifie s'arrêter proprement particulièrement quand on ne gère pas. D'autant plus quand tu dis que c'est plus que ce que font des langages à runtime comme java pour le quel la JVM fait pas mal de choses.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et en plus
Posté par abriotde . Évalué à -6 (+0/-7). Dernière modification le 17 mars 2024 à 21:12.
Bien sûr que si. La seul chose c'est qu'effectivement l'OS limite le phénomène et généralement la corruption est limité au programme qui tourne et arrive très rarement aux autres programmes/drivers et exceptionnellement à l'OS.
Bien sûr que Rust consomme de la mémoire, mais en quantité plus limité surtout il évite en grande majorité ce que l'on appel la fuite mémoire. La fuite mémoire c'est quand tu alloue de la mémoire en boucle sans jamais la libéré. Or en Java comme tu sais que tu ne peux pas "oublier" de libérer la mémoire gâce au garbage collector, naturellement, tu fais moins attention. En Rust, cette fuite est possible mais bien moins courante car il le programme doit prévoir de libérer sa mémoire par conception. Mais évidemment si tu fait un appel récursif infini (Ou trop important..) par exemple, fatalement, dans un cas comme dans l'autre tu crash.
PS : l'OOM killer, est une "option" sous Linux (par défaut sur la plupart des distribs) mais pas toujours présente. Il est une sécurité pour éviter de crasher l'OS faute de mémoire.
Oui bien sûr qu'un accès null-pointer en C est bien plus grave en C qu'en Java, reste que c'est un plantage dû à la mémoire indésirable quelques soit le programme.
En Java en gros on quitte "Proprement", sans corrompre la mémoire contrairement à C. Mais en Rust, on a une exception que l'on est censé traité. Evidemment si on la traite pas on est comme en Java. Mais la différence n'est pas négligeable.
C'est simple, quand un programme crash il fait n'importe quoi autrement dis il peut faire du dégât comme en C ou il peut aller ailleurs dans la mémoire et écraser tout et n'importe quoi. Mais pire, il peut ne pas planter, et continuer avec des donner qu'il a totalement pourri. Souvent d'ailleurs le crash réel intervient longtemps après.
En Rust et en Java on a une exception. La mémoire n'est pas corrompu et si on gère "l'exception" on peut utiliser les données car elles restent bonnes (Elles n'ont pas été altérées par le programme).
Evidemment, en Rust comme en Java, tu peux par bug, faire entrer le programme dans un comportement impossible et corrompu malgré tout (Par exemple mettre 400° dans un angle censé être entre 0 et 360). Ada est le langage ultime pour ça mais il est encore bien moins productif…
[^] # Re: Et en plus
Posté par barmic 🦦 . Évalué à 6 (+4/-0).
Tu ne prouve que ton manque de compréhension de ce dont tu parle.
Non et ce n'est pas généralement si ça existe c'est un bug enregistré dans une CVE a haute priorité.
Les cas de fuites mémoire en java sont identiques en rust. Rust ne te demande pas de prévoir la libération, il s'assure qu'une zone mémoire n'a qu'un et un seul propriétaire a aucun moment il ne fait quoi que ce soit pour que ce propriétaire ne garde que ce dont il a besoin.
Qu'elle distribution retire cette option ?
Et comme elle ne s'appelle pas NullPointerException ça n'a rien à voir ?
Un crash de programme n'est pas propre quand il ne crash pas ?
Tout le monde se fout de la mémoire au moment d'un crash. Éventuellement tu peux demander à la jvm de la dumper pour un post-mortem, mais corrompre sa mémoire lors d'un crash n'a pas de sens. Le processus est en cours de libération, le noyau va nettoyer les pages mémoires qui lui était allouées (non pas pour une question de corruption, mais pour éviter la fuite de données quand les pages seront réutilisées).
Tu confond bug, corruption de mémoire, crash,…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et en plus
Posté par David Delassus (site web personnel) . Évalué à 6 (+4/-0).
Depuis quand un
panic!lors d'unBox::new(...)ouVec::push(...)c'est s'arrêter proprement ?C'est l'équivalent de :
Faut arrêter un peu les fantasmes sur le Rust.
https://link-society.com - https://kubirds.com
[^] # Re: Et en plus
Posté par abriotde . Évalué à -4 (+0/-5).
C'est s'arrêter proprement. Peut être pas volontairement pour le programmeur. Java fait pareil. Mais ils ne corrompent pas la mémoire autour pour autant.
Par contre en Rust pour générer un pannic! il faut normalement faire un ".unwrap()" ou quelque chose de cet ordre. Autrement dis explicitement dire "bah tu t'arrête". Autrement dis c'est clairement que volontairement tu a voulu ne pas géré le plantage. En Java, tu n'a rien qui te préviens et tu ne peux pas t'ammuser à tester chaque pointeur. Et même si tu le fais, tu va en oublier…
Mais l'avantage de Rust sur Java, c'est surtout sa vitesse d'exécution. Autrement dis : "Rust gère mieux la mémoire et surtout va beaucoup plus rapidement pour une productivité similaire"… Evidemment, encore une fois, tout est compromis entre productivité et vitesse d'exécution en langage informatique.
[^] # Re: Et en plus
Posté par David Delassus (site web personnel) . Évalué à 6 (+4/-0).
S'arrêter proprement c'est relâcher les resources que l'on a acquise (file descriptor, socket, …) avant l'arrêt effectif. Ou plus communément appelé : "graceful shutdown".
Si ton serveur derrière le socket s'attend à ce que tu lui envoie
goodbyeavant de fermer le socket, c'est pas l'OS qui va le faire pour toi.Oue, il faudrait avoir fait un peu de Rust en fait avant de parler de Rust.
La fonction
.unwrap()existe pour les typesResult<T, E>etOption<T>. Elle génère effectivement unpanic!si leResult<T, E>contientErr(E), ou si leOption<T>contientNone.De la même manière,
Result<T, E>a une fonction.unwrap_err()qui génère unpanic!si leResult<T, E>contientOk(T).C'est pas inné au langage, c'est un design d'API. Un autre design c'est que toutes les allocations faites par la stdlib génèrent un
panic!si l'allocation échoue, à savoir notamment :Box::new(...)Vec::push(...)Note qu'il existe aussi
Box::try_new(...)qui au lieu de générer unpanic!va retourner unResult<T, E>avecOk(Box<T>)ouErr(OutOfMemory). Et bien sûr, équivalent pour toutes fonctions allouant de la mémoire.Mais tout ça, c'est au delà de ce que je disais, à savoir :
Il n'y a aucune différence entre
panic!et :https://link-society.com - https://kubirds.com
[^] # Re: Et en plus
Posté par YBoy360 (site web personnel) . Évalué à 1 (+1/-1).
Au moins Java est stable binairement … J'aime bien Rust, mais pour remplacer le C, ou avoir sa place dans les foutus gros logiciels d'entreprise, il lui faut une ABI stable, et si possible, simple. Est-ce seulement possible ?
En Java on va pouvoir binder avec du code natif, sans "glue" native. Ça pourrait changer pas mal de choses.
[^] # Re: Et en plus
Posté par abriotde . Évalué à -1 (+1/-3).
Java n'est pas si stable binairement en tout cas beaucoup moins que C. C est stable sur 30 ans au minimum alors que va faire tourner un programme compilé en Java 3 sur une JVM Java 8… Ca marchera pas car il n'est pas stable (surtout les libs).
C'est aussi un autre problème de Java: Il est dépendant d'une JVM à la bonne version et avec les bonnes lib (Peut-être peut-on les compiler en statique en Java?).
En Rust, c'est la config du compilo qui décide de l'OS sur lequel il va tourner. et pour les libs tu peux les compiler en statique.
Le problème fondamental c'est qu'un programme C ou Rust écris il y a 20/50 ans peut tourner tel quel sur une machine moderne juste en étant recompilé. En Java, il faut soit installer une vielle JVM (Avec les lib) et toutes leurs failles non maintenus soit, migrer le code dans la dernière version de Java.
C'est le même problème que tous les langages interprété à la différence que la JVM reste plus stable binairement que Python, PHP et consorts (Car ils sont interprété et donc sensible au moindre changement de syntaxe).
Pour cette raison entre autre, je préfère encore le Go au Java (Pour plus de productivité que Rust).
[^] # Re: Et en plus
Posté par BAud (site web personnel) . Évalué à 2 (+1/-1). Dernière modification le 17 mars 2024 à 21:53.
comment trouves-tu en 2024 un programme en Rust de plus de 18 ans ? (déjà que de plus de 9 ans, ça doit être un chouilla compliqué…)
[^] # Re: Et en plus
Posté par David Delassus (site web personnel) . Évalué à 2 (+0/-0).
18/20, on a le droit de faire des arrondis quand même ?
https://link-society.com - https://kubirds.com
[^] # Re: Et en plus
Posté par abriotde . Évalué à -3 (+1/-5).
Bien sûr tu n'en trouves pas. Mais tu sais que si tu installe un vieux compilo sur un PC tu pourra compiler ton programme comme on le fait avec n'importe quel programme C/C++ ou autre programme compilé. C'est inhérent aux langages compilés. Généralement ils ont un mode de rétro-compatibilité (-c89 pour comilé un programme C de la norme 1989) et sinon tu peux installer le binaire de 1989 sur un PC récent et le recompilé. Le compilateur n'a pas (ou très difficilement) des failles de sécurité.
Alors que trouver un compilo Java qui te produit un binaire compatible JVM8 pour un programme Java aux normes de 1990, c'est une autre paire de manche. Je me trompe peut-être mais ça n'existe pas à ma connaissance.
PS : c'est pire avec un langage interprété comme Python. Il est totalement impossible de faire tourner un programme Python1 sur un Python3.
Bref, l'idée est de dire que la compatibilité binaire d'un programme compilé, n'est généralement pas un problème.
En fait le vrai problème, existe : La compatibilité binaire des librairies Rust pour des programme C (l'inverse est moins vrai). Actuellement c'est un point noir pour lequel Google à donné 1 million de dollars mais il sera résolu.
Mais c'est pire en Java, c'est impossible à ma connaissance: appeler un binaire Java avec un programme C qui a prévu d'appeler un librairie C (Même en le voulant dans le code C, ça doit être bien galère). Et se problème se pose juste parce que l'on veut remplacer C au plus vite morceau par morceau. Ce n'est pas un problème Rust à la base.
[^] # Re: Et en plus
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
C'est pas ce que faisait OpenOffice dans le temps ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et en plus
Posté par YBoy360 (site web personnel) . Évalué à 3 (+2/-0).
Le problème de la stabilité binaire est abordé de façon différente en Java. Par exemple, avec Java 1.1 de Sun, les calculs arithmétiques sont binairement identique, quelque soit la FPU HW… D'où des perfo pas terrible et de nombreuses critiques.
Si tu dis "Java n'est pas stable binairement", tu dois le prouver concrètement, nous utilisons des binaires de 2007 aujourd'hui, pas de problèmes.
L'importance d'avoir une ABI stable :
[^] # Re: Et en plus
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 18 mars 2024 à 07:48.
C n'a rien de stable "binairement", vu que c'est dépendant de l'implémentation :-)
La rétrocompatibilité de Java est excellente au contraire et tu as de bonnes chances de faire tourner de vieux programmes avec un JRE récent, mais il y a des limites : une API dépréciée finira toujours par être retirée à un moment ou un autre et il est imprudent de ne pas mettre à jour son programme au moins une fois par an.
La dépendance à un runtime pose des problèmes, car les OS ne font pas leur boulot.
Par contre on peut faire une appimage.
Un vieux programme C jamais mis à jour aura des problèmes similaires : il dépendra d'un vieux gcc, d'un vieux make…
Le patch management n'est pas une option :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.