Discussion :

[CaptainDangeax]

Moi, je veux bien apprendre un nouveau langage qui est plus simple, plus rapide et plus sécurisé. Mais pour ça il faut que:
- il y ait des compilateurs disponibles pour les cibles que j'utilise (ce n'est pas le cas)
- si le compilateur est disponible, il faut qu'il y ait les librairies disponibles (je n'ai pas encore cherché, je termine les projets en cours d'abord)
C'est aussi simple que ça

[Uther]

Moi, je veux bien apprendre un nouveau langage qui est plus simple, plus rapide et plus sécurisé. Mais pour ça il faut que:
- il y ait des compilateurs disponibles pour les cibles que j'utilise (ce n'est pas le cas)
- si le compilateur est disponible, il faut qu'il y ait les librairies disponibles (je n'ai pas encore cherché, je termine les projets en cours d'abord)
C'est aussi simple que ça

Si vous cherchez un langage plus simple, Rust n'est pas forcément le meilleur choix. Il est techniquement plus simple que le C++, mais bon ça c'est pas très difficile. Par contre, il ne fait clairement pas partie des langages taillé sur mesure pour la simplicité comme Go, ou Python. Il y a clairement des notion particulières a appréhender.
Pour le compilateur, en effet ça va dépendre de vos cibles. En général ce qui est supporté par LLVM est supporté par Rust, mais tout n'a pas un support optimal.
Pour les bibliothèques, il commence a y avoir pas mal de choix, et sinon il y a toujours moyen de s'interfacer avec un bibliothèque C.

[fdecode]

Si vous cherchez un langage plus simple, Rust n'est pas forcément le meilleur choix. Il est techniquement plus simple que le C++, mais bon ça c'est pas très difficile. Par contre, il ne fait clairement pas partie des langages taillé sur mesure pour la simplicité comme Go, ou Python. Il y a clairement des notion particulières a appréhender.
Pour le compilateur, en effet ça va dépendre de vos cibles. En général ce qui est supporté par LLVM est supporté par Rust, mais tout n'a pas un support optimal.
Pour les bibliothèques, il commence a y avoir pas mal de choix, et sinon il y a toujours moyen de s'interfacer avec un bibliothèque C.

Déjà, on ne peut pas faire l'impasse d'une compréhension de la gestion des données en mémoire (la pile et le tas).
C'est un préalable à la compréhension de la sémantique de prêt qui est incontournable dès le début pour écrire du code compilable en Rust.
Un petit détail comme le fait que la donnée soit copiable (et stockée dans la pile) ou non copiable a des conséquences sur l'accès aux données.
Par exemple:

• Le code: [playground]

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

   let a = [[1,2],[3,4]]; let x = a[0]; let y = a[1];

  compile car les sous-tableaux '[1,2]' et '[3,4]' sont copiables
• Alors que le code: [playground]

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

   let a = [vec![1,2],vec![3,4]]; let x = a[0]; let y = a[1];

  ne compile pas car les sous-tableaux 'vec![1,2]' et 'vec![3,4]' sont non copiables (stockés dans le tas). Il s'ensuit que les affectations sur 'x' et 'y' nécessitent un move non autorisé des données.

Rien de bien compliqué, mais c'est le genre d'exemple déroutant pour le débutant en Rust. Et au début, avant d'avoir des réflexes de conduite, on en rencontre souvent des petits exemples comme ça...

[NotABread]

Je trouve que certains oublient bien vite que le choix d'un langage de programmation est un choix technique. Il se base sur:
- le budget
- le temps
- les ressources disponible
- les besoins

Par exemples, j'ai écris un bot pour Discord:
- budget: 0€, je ne veux utiliser que ce que j'ai actuellement
- temps: une dizaine d'heure
- ressources disponible: moi, une lib pour faciliter l'usage de l'api discord, mon pc et mes petits doigts musclés
- besoins:
- tourner h24
- consommer le moins de RAM et de CPU possible
- résister aux saisis malicieuse

J'ai éliminé dès le début JS, je n'ai pas les connaissances pour m'assurer qu'il n'y a pas d'injection de code, un oubli pourrait vite compromettre mon serveur. Python aurait donner des résultats très rapidement et certainement suffisant pour mon usage mais pour tourner des jours sans interruption, il me faudra des try/catch sur tout ce qui peut échouer, et pour la beauté de l'art, je voulais quelque chose de plus optimisé en CPU et RAM.
Au final, j'ai choisi Rust car il répondait à tous mes critères et je voulais tester le langage, j'aurais aussi pu le faire en Golang. Je ne regrette pas ce choix pour ce projet perso, des mois que le bot tourne et a résisté au tentative d'injection et autre, la seule interruption que j'ai eu fut en raison d'une coupure d'électricité. Les points noirs que j'ai vu, c'est un exécutable de 200 Mo et l'usage de la RAM qui tourne autour de 100 Mo. Je pense que les moulte dépendances en sont principalement responsable, mais au moins, l'usage de la RAM reste stable.


L'ajout de Rust dans Linux semble plus que pertinent de part la garantie de la sécurité mémoire et les performances très proche de C. Il sera dommage de s'en priver parce que "c'est pas du C, moi je suis un vrai développeur qui peut faire du C mieux que tout le monde donc j'en ai pas besoin"

[Fagus]

Python aurait donner des résultats très rapidement et certainement suffisant pour mon usage mais pour tourner des jours sans interruption, il me faudra des try/catch sur tout ce qui peut échouer, et pour la beauté de l'art, je voulais quelque chose de plus optimisé en CPU et RAM.

Python est lent en général (quoique pour la plupart des usages c'est good enough), mais sur les exceptions, il ne faut pas hésiter à en mettre, c'est tellement optimisé que c'est gratuit tant que l'exception n'est pas déclenchée.

[Metal3d]

Je vais même pas faire un long commentaire, je trouve juste ultra ironique qu'une personne de la communauté Rust trouve d'autres développeurs "condescendants"

[pcdwarf]

ouais... alors les "mégalomanes pédants et condescendants", il sont peut-être désagréables, mais en général, ils maitrisent leur sujet. C'est d'ailleurs la raison pour laquelle ils sont vu comme pédants et condescendants alors que souvent ils sont juste compétant et exigents.

Simple curiosité, j'ai un peu regardé ce que c'était que Rust. Et j'avoue que j'ai pas été convaincu que ça présente tellement d’intérêt par rapport à du C.
Je m'attendais à un langage ressemblant à C mais avec plus de garde-fous. Finalement, j'ai eu du mal ne serais-ce qu'a en lire.

En fait, je m'attendais à ce qu'une part de C++ finisse par entrer dans le noyau malgré les réticences de Torvalds mais pas à ce qu'il pousse un langage aussi différent.

Le problème va être la maintenabilité.
ça suppose que beaucoup de dev deviennent compétents dans ce langage...
Il y aura des spécialistes de l'un et de l'autre. ça ne me semble pas être une bonne chose question organisation.

[OuftiBoy]

ouais... alors les "mégalomanes pédants et condescendants", il sont peut-être désagréables, mais en général, ils maitrisent leur sujet. C'est d'ailleurs la raison pour laquelle ils sont vu comme pédants et condescendants alors que souvent ils sont juste compétant et exigents.

Je n'ai pas fréquenté la communauté 'Rust'. Ici sur développer.com, il y a des participants de tout niveau, ça va des fanatiques décérébrés à des gens très compétants. Et oui, des fois, quand on a raison (et si c'est contre l'avis d'une majorité), c'est parfois difficile de se faire entendre. Je ne prétend pas avoir LA vérité, mais il me faut de solides arguments pour me convaincre. On peut être compétant, mais ce n'est pas une raison pour rabaisser les autres. Il faut garder un seine humilité sincère, car on tous des choses à apprendre des autres. Tant que la discution reste polie et non fanatisée, j'aime bien participer.

Simple curiosité, j'ai un peu regardé ce que c'était que Rust. Et j'avoue que j'ai pas été convaincu que ça présente tellement d’intérêt par rapport à du C. Je m'attendais à un langage ressemblant à C mais avec plus de garde-fous. Finalement, j'ai eu du mal ne serais-ce qu'a en lire.

Oui, Rust (que je connais pas profondément, mais dont j'essaye de comprendre les forces, et les faiblesses) apporte des "avançées" par rapport au 'C', mais oui, c'est via des concept et construction assez éloignée du C. Rust s'imposera peut-être dans la séries des grands langages reconnus, mais je reste persuadé qu'il ne remplacera pas le 'C'. Mais il apporte de bonnes idées, mais qui ne sont pas aussi révolutionnaire que ça. ça dépend de ton niveau en C.

En fait, je m'attendais à ce qu'une part de C++ finisse par entrer dans le noyau malgré les réticences de Torvalds mais pas à ce qu'il pousse un langage aussi différent.

Honnêtement, si il doit y avoir 2 langages dans la base de code linux, je ne pense pas que C++ soit une bonne idée. ça aurait pu l'être, j'adorait le C++ à ces début. Mais maintenant, je suis dégouté de ce qu'il est devenu.

Le problème va être la maintenabilité.
ça suppose que beaucoup de dev deviennent compétents dans ce langage...
Il y aura des spécialistes de l'un et de l'autre. ça ne me semble pas être une bonne chose question organisation.

Oui, c'est le danger, il faudra des développeurs de haut niveau autant en C qu'en 'Rust'. Perso, même si Rust propose de bonnes chose, une base de code avec un seul langage (le C), ça reste plus sécure. Rust est encore jeune, il évolue encore. Mias le C est là pour longtemps, et est disponible partout, c'est la "brique" fondamentale de l'informatique, et il n'est pas près de disparaître. Il évite des erreurs qu'on peut facilement faire un 'C', mais c'est comme quand on élève un enfants, il faut laisser faire des erreurs pour en tirer des leçons et progresser. Les devs qui ne connaissent pas le bas niveau, sont souvent moins compétants que ceux qui sont passés par l'assembleur et le C.

BàT. et Peace & Love.

[floyer]

Effectivement, Rust est loin d’un C amélioré… il emprunte pas mal de choses à différents langages (types algébriques et pattern matching ML, async Javascript, tableau ADA (la taille du tableau est échangé acec le tableau s’il est de taille variable), traits ?, macro Scheme?, RAII C++). Avec des choses originales (emprunts, gestion des erreurs). S’il est positionné comme une alternative au C c’est plus car il a de bonnes performances aussi. Il possède aussi des constructions facilitant l’interface au C.

[Uther]

Simple curiosité, j'ai un peu regardé ce que c'était que Rust. Et j'avoue que j'ai pas été convaincu que ça présente tellement d’intérêt par rapport à du C.
Je m'attendais à un langage ressemblant à C mais avec plus de garde-fous. Finalement, j'ai eu du mal ne serais-ce qu'a en lire.

Oui Rust n'est pas une surcouche de C comme C++. Il faut apprendre ses particularités, qui ne sont tout de même pas si complexes que ça en ce qui concerne la syntaxe elle même. Ça reste un langage impératif, techniquement plus simple que le C++ moderne.

Le problème va être la maintenabilité.
ça suppose que beaucoup de dev deviennent compétents dans ce langage...

C'est pas faux, mais il faut aussi prendre en compte que Rust a quand même un avantage pour la maintenabilité par rapport au C : dans la plupart des cas le code techniquement problématique ne compile juste pas.
Un développeur avec peu d'expérience en Rust risque de mettre plus longtemps qu'un expert avant d'arriver au résultat qu'il veut, mais la fiabilité devrait être au rendez vous. Alors qu'avec d'autre langages il y aurait clairement plus de risques.

[thal1]

Et combien coûte cette étude en énergie , qu'elle en est l'impacte ?
Et combien coûte en énergie la résolution des multiples bugs ?
Et combien coûte en energie le remplacement du matériel hardware suite
aux upgrades informatiques sensés apporter des miracles à des tas de personnes
qui n'en n'ont pas besoin et qui son obligées de suivre le mouvement ?
Voilà qui serait réellement intéressant ...

[floyer]

Oui, effectivement, il y a un aspect coût. D’où l’approche pragmatique (adaptation du noyau à des extensions nouvelles en Rust : driver, système de fichier)… ou verra pour plus tard ou jamais pour des éléments plus internes.

Des coûts aussi… quel est coût d’un système de fichiers vérolé, d’une attaque à cause d’une CVE, d’une mise à jour malheureuse (Crowdstrike) ? (Sans compter en amont, le coût du débugage dans les versions de développement).

Quand au coût matériel, Rust est connu pour être très performant. Cela ne devrait pas impacter significativement les performances.

[Zeeraptor]

Le C est primaire,Léger...
Quasiment bas niveau

Rust est ultra portable...avec un repository intégré (bonne idée)...
Haut niveau...

Le Rust est moins rapide que le C,Le C est moins sécurisé que le Rust

Pour Un gros projet,Rust est certainement meilleur que le C.

[NotABread]

Ca dépend d'où tu mets ta barrière entre le haut niveau et le bas niveau. Dans la mesure où Rust t'impose de savoir ce qu'il se passe avec la mémoire et que cela est une forte contrainte dans l'écriture d'un programme, je dirai plutôt que Rust est bas niveau, à l'inverse de Python qui est très permissif sur l'écriture et masque la gestion de la mémoire.
Mais d'après certain, C serait un langage de haut niveau d'après la définition Wikipédia d'un langage de haut niveau
https://fr.wikipedia.org/wiki/Langag...de_haut_niveau

Un langage de haut niveau fait abstraction des caractéristiques techniques du matériel utilisé pour exécuter le programme, tels que les registres et les drapeaux du processeur

Aussi, Rust et C sont du même ordre de grandeur du point de vu performance. Pour certain problème, C est devant, pour d'autre c'est Rust. On peut dire qu'ils sont au même niveau en perf
https://benchmarksgame-team.pages.de.../rust-gcc.html

Le gros avantage du C reste sa simplicité, qui font qu'il est facile d'écrire un compilateur pour une plateforme personnalisé. Si on connait bien l'assembleur et le C, on sait à peu près ce que donnera l'assembleur d'un programme C

[Zeeraptor]

Rust est clairement impressionnant...

Le C restera un roc pour l'apprentissage et la légereté


Je n'ai jamais programmer en assembleur mais le HLA m’intéresse

[N_BaH]

Mais d'après certain, C serait un langage de haut niveau d'après la définition Wikipédia d'un langage de haut niveau
https://fr.wikipedia.org/wiki/Langag...de_haut_niveau

Le langage C présente la particularité d'être à la fois un langage de haut niveau et de bas niveau. Cependant cette notion a tendance à évoluer dans le temps : le langage C qui était généralement considéré comme de haut niveau s'est vu progressivement rapprocher du bas niveau

ce n'est donc pas si clair.

[NotABread]

ce n'est donc pas si clair.

Oui, c'est clair, sinon on aurait que l'assembleur en bas niveau de nos jour. De nos jour on parle plus de langage bas niveau quand il faut savoir manipuler la mémoire proprement et avec typage statique, et haut niveau quand on fait abstraction de la mémoire avec typage dynamique

[Zeeraptor]

De mon point de vue,le C est le parfait mix entre bas niveau et haut niveau

La gestion de la mémoire en Rust je ne me souvient pas...quel mechanisme? Quelque chose de similaire avec les pointeurs?

Oui, c'est clair, sinon on aurait que l'assembleur en bas niveau de nos jour. De nos jour on parle plus de langage bas niveau quand il faut savoir manipuler la mémoire proprement et avec typage statique, et haut niveau quand on fait abstraction de la mémoire avec typage dynamique

exactement

[NotABread]

De mon point de vue,le C est le parfait mix entre bas niveau et haut niveau

La gestion de la mémoire en Rust je ne me souvient pas...quel mechanisme? Quelque chose de similaire avec les pointeurs?

La manière dont tu vas utilisera tes variables va grandement changer ce que tu vas utiliser (lis un tuto sur les Box, Rc, Mutex, Arc, la durée de vie et l'ownership dans Rust, ça sera plus clair que tout ce que je pourrais dire en un message. Pour bien les utiliser, il faut savoir ce que tu fais avec la mémoire, sinon tu te feras constamment engueuler par le compilateur)
Typiquement, si tu veux faire un tableau d'un trait, le compilateur te fera utiliser à minima Box (qui est un pointeur vers le tas) car le compilateur ne peut connaître la taille de ce qu'il stockera dans chaque index du tableau.

[floyer]

Aussi, Rust et C sont du même ordre de grandeur du point de vu performance. Pour certain problème, C est devant, pour d'autre c'est Rust. On peut dire qu'ils sont au même niveau en perf
https://benchmarksgame-team.pages.de.../rust-gcc.html

Il faut faire attention à ce type de benchmark. Certains de leurs programmes en C utilisent des extensions GCC pour utiliser les instructions MMX ou SSE du processeur. Cela tient plus de l’assembleur que du C.

Il serait plus opportun d’avoir une rubrique C avec des constructions typiques du C et une C/MMX qui ouvre la porte à de telles optimisations.

[

De mon point de vue,le C est le parfait mix entre bas niveau et haut niveau

La gestion de la mémoire en Rust je ne me souvient pas...quel mechanisme? Quelque chose de similaire avec les pointeurs?

Les structures sont placées dans la pile par défaut. Donc la libération est très rapide. Pour éviter des problèmes (usage d’une référence obsolète car pointe sur une partie libérée), le compilateur impose des contraintes (ownership…) que C n’impose pas.

Ainsi, en C, on peut écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
{
  int *p;
  {
     int a;
     p = &a;
  }
  *p = 42;
}

On voit que a est libéré, mais un pointeur p pointe toujours dessus… le langage Rust ne permettrait pas cela. On aurait sur un code équivalent des erreurs:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
6 |     r = &mut  a;
  |     ^^^^^^^^^^ cannot assign twice to immutable variable
 
error[E0597]: `a` does not live long enough
 --> a.rs:6:9
  |
6 |     r = &mut a;
  |         ^^^^^^ borrowed value does not live long enough
7 |   }
  |   - `a` dropped here while still borrowed
8 |   *r = 5;
  |   ------ borrow later used here

Pour certains besoins, on peut allouer de la mémoire sur le tas. Et lorsque le compilateur voit que plus aucun pointeurs pointe sur la structure, il fait un free() implicite. Il est aidé pour cela par les contraintes citées plus haut. C’est comme les smart pointers de C++. On a le type Box pour les unique_ptr et Rc ou Arc pour shared_ptr. Il y a toutefois une différence majeure. En C++, std::move annule un pointeur (ce qui ralentit légèrement) et le pointeur ne doit donc pas être déréférencé sous peine d’erreur à l’exécution (segmentation fault). En Rust, la référence est marquée lors de la compilation comme inutilisable (inutile de la mettre à 0 à l’exécution), et un usage provoque une erreur à la compilation.

Ainsi, le code suivant échoue à l’exécution.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  std::unique_ptr<int> p1 = std::make_unique<int>();
  std::unique_ptr<int> p2 = std::move(p1);
  std::cout << *p1;

L’équivalent Rust dont on note la syntaxe plus concise ne compile pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  let b1 = Box::new(5);
  let b2 = b1;
  println!("{}",*b1);

Les pointeurs (comme en C) existent mais sont plutôt conçus pour l’interopérabilité avec C et ne sont pas encouragés pour un usage général. Et l’usage de ces raw pointer doit être taggué «*unsafe*»