Discussion :

[Uther]

Est-ce qu'il y a des chose que l'on peut faire en C/C++ et qui ne sont faisable en Rust?

Tout dépends ce qu'on entent par là. En ce qui concerne les bonne performances, la prédictibilité et l'accès aux ressources bas niveau, le Rust fait aussi bien que le C/C++ ce qui le rend tout a fait utilisable pour des applications très bas niveau.
Pour ce qui est des fonctionnalité du langage tout ce qui est faisable en C l'est en Rust (sauf le goto) même si les choses potentiellement problématique sont volontairement plus complexes a mettre en place pour éviter qu'elles soient utilisées par inadvertance.
Comparé au C++ c'est plus mitigé. Certaines fonctionnalités ne sont pas encore aussi avancées (généralisation, constexpr, ...) mais progressent, d'autres sont volontairement écartée pour garder un langage simple (template metaprogramming, surcharge classes héritées, ...) mais sont remplacés par d'autre mécanismes (traits, génériques, macro hygiéniques, ...)

Est-ce que l'on peut faire de la programmation embarqué en Rust? C.a.d faire un (petit) soft qui tient dans 32kio pour un microcontrôleur 8/16 bit.
Les fabriquant de microcontrôleur commencent-ils à intégrer le Rust dans leur SDK?

Le langage Rust permet de faire des programes qui s'optimisent à peu près aussi bien en taille que le C, mais sa plus grosse limitation a l'heure actuelle est qu'il n'est en effet pas encore supporté par la plupart des tout petits microcontrôleurs.

[Invité]

Une bonne partie du compilateur Rust étant écrite en C++, c'est surprenant de prétendre que le premier langage va surpasser le second.

Plus généralement, Rust apporte un gros plus vis-à-vis de C et C++ pour les applications critiques. Par contre, pour le calcul scientifique par exemple, Rust est très pauvre niveau crates. Et ces dernières sont bien souvent des wrappers vers des libs C/C++, et donc clauses unsafe dans le code. Rust perd alors tout son intérêt, on n'échappera pas aux verbiages excessifs du langage pour autant.

Bref, malgré ses qualités, Rust n'est pas un C/C++ killer.

[onilink_]

Une bonne partie du compilateur Rust étant écrite en C++, c'est surprenant de prétendre que le premier langage va surpasser le second.

Bof, pas grand chose à voir, l'important c'est de regarder la qualité du binaire en sortie et donc les optimisations.
Et de ce que je sais Rust utilise LLVM, tout comme le compilateur C++ Clang, par exemple.

Rust pourrait très bien être écrit en javascript que l'output n'en serait pas plus lent.
Le problème ce serait au niveau des temps de compilation et de la mémoire utilisée pour compiler.

Sur le même principe rien n’empêche d'écrire un compilateur C++ en Rust, ou un compilateur Rust en Rust

[locus]

Je ne suis pas opposé au Rust mais je trouve que ce langage et son environnement n'ont pas atteint un certain niveau de maturité pour être réellement exploitables.
Depuis le coup de python 2 à python 3 et ses changements, je me méfie de certains langages très récents car on peut tout bouleverser en quelques années voir quelques mois (syntaxe, style de programmation...).

Alors initier les prochains projets en les concevant sous Rust, OK mais j'ai besoin de preuve de sa stabilité sur le très très long terme afin de ne pas passer mon temps à refaire mon code.
Déjà que certaines frameworks passent leur temps à évoluer au point que les dévs n'arrivent plus à suivre ou doivent retoucher du code legacy de manière hasardeuse.

[imperio]

Le compilateur Rust est écrit en Rust. La seule partie C++ étant LLVM pour la génération du binaire. Dans le même sujet, il est bon de noter qu'un backend GCC est en cours d'implémentation (ça fournirait une alternative à LLVM, pratique pour certaines targets en embarqué) et qu'il y a aussi quelqu'un de la communauté GCC qui est en train de réécrire le "front-end" du compilateur en C++ pour l'intégrer directement dans GCC. Donc @onilink_ a parfaitement raison.

Par-contre il y a pas mal de différence en terme de résultats entre l'AST fournit à LLVM entre le compilo Rust et un compilo C++ par-exemple, mais cela est dû à des spécificités de Rust. Par-exemple, toutes les variables sont non-mutables par défaut en Rust, contrairement à C/C++, donc cela permet de très chouettes optimisations par défaut.

Plus généralement, Rust apporte un gros plus vis-à-vis de C et C++ pour les applications critiques. Par contre, pour le calcul scientifique par exemple, Rust est très pauvre niveau crates. Et ces dernières sont bien souvent des wrappers vers des libs C/C++, et donc clauses unsafe dans le code. Rust perd alors tout son intérêt, on n'échappera pas aux verbiages excessifs du langage pour autant.

Pas d'accord sur ce point. Si tu concentres le "unsafe" dans une API qui se charge de bien wrapper comme il faut pour toi, tu limites finalement les bugs habituels à cette partie là. Cela n'enlève pas les problèmes inhérents au code C en dessous mais en principe, utiliser ce binding de Rust t'assure que tu ne pourras pas mal utiliser la lib C en dessous (en principe). Après si tu n'aimes pas la syntaxe de Rust, c'est un autre débat...

[prisme60]

J'ai proposé à ma boite de porter et faire les évolutions de notre projet sous Rust, mais le responsable était frileux. Beaucoup de notre code se remplaçait par des bibliothèques (Crates), ce qui nous évitait de le réécrire, et nous assurait de respecter les bonnes pratiques du Rust. Une bibliothèque statique pour la gestion du dongle de protection était appelable via FFI (cela demander évidemment d'utiliser le mot clé "unsafe" que l'on essaye d'éviter).
Je leur affirmais que vu le peu de source de redévelopper le soft (20 fichiers c++), mais qui utilise massivement du multithreading (que j'avais moi-même écrit auparavant, donc je ne m'attaque pas à quelque chose que je ne comprends pas).

Comme l'outil doit en plus respecter le niveau outil T2 (en-50128 norme de sureté de fonctionnement logiciel ferroviaire : outils), Rust convenait parfaitement et en plus garantit une stabilité de fonctionnement et gestion des erreurs.

Mais on m'a répondu, que j'étais le seul à connaître le Rust , et effectivement en continuant sur ce genre de stratégie, je vais continuer à écrire du code Rust pour mes projets persos.

[smarties]

Pour moi RUST est suffisamment mature pour un certains nombre de projets.
C'est évident qu'il manque des bibliothèques et qu'il faut préparer les projets en amont de ce côté là.

C et C++ seront encore présent longtemps mais leur chaîne de compilation est souvent problématique sur les gros projets quand il faut installer beaucoup de bibliothèques. De ce que j'ai peu croiser, ce n'était pas forcément bien documenté sur ce point.

Au niveau sécurité, il n'y a pas photo. Quand j'ai fait du C et du C++ il y a longtemps j'avais souvent des "Segmentation fault" que je n'ai pas en RUST. Etre averti en amont par le compilateur est vraiment bien.

Pour des projets stables et qui n'ont pas eu de bugs remontés depuis longtemps, ça ne servirait pas à grand chose de les réécrire.

Pour les nouveaux projets, je suis d'avis de se poser la question entre rester sur C ou C++ ou de le développer en RUST... surtout si le process manque d'industrialisation.

[locus]

Tant que l'on devra faire appel aux FFI par manque de bibliothèques propres à rust, je me dis que Rust est encore loin d'être un environnement mature. Même avec Python, je dois utiliser ctypes chose qui m'agace.

[imperio]

Tant que l'on devra faire appel aux FFI par manque de bibliothèques propres à rust, je me dis que Rust est encore loin d'être un environnement mature. Même avec Python, je dois utiliser ctypes chose qui m'agace.

Tant que des OS sont écrits en C tu veux dire ? Je crains fort que l'on doive attendre longtemps alors...

[Dymmm]

Si j'avais a choisir entre C et Rust pour le boulot alors je choisirais Rust. J'ai trop souvent eu des collègues prétendant savoir développer en C (ou C++) et produisant du code de merde. Si Rust peut limiter la casse alors je suis partant.

[Markand]

Le gros problème de Rust, c'est qu'il a copié npm.

Quand on voit un projet comme exa qui nécessite un paquet crates pour lister des répertoires. Ça fait tâche.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
exa v0.10.1 (/tmp/exa)
├── ansi_term v0.12.1
├── datetime v0.5.2
│   ├── libc v0.2.93
│   ├── locale v0.2.2
│   │   └── libc v0.2.93
│   └── pad v0.1.6
│       └── unicode-width v0.1.8
├── git2 v0.13.20
│   ├── bitflags v1.2.1
│   ├── libc v0.2.93
│   ├── libgit2-sys v0.12.21+1.1.0
│   │   ├── libc v0.2.93
│   │   └── libz-sys v1.1.2
│   │       └── libc v0.2.93
│   │       [build-dependencies]
│   │       ├── cc v1.0.67
│   │       │   └── jobserver v0.1.22
│   │       │       └── libc v0.2.93
│   │       └── pkg-config v0.3.19
│   │   [build-dependencies]
│   │   ├── cc v1.0.67 (*)
│   │   └── pkg-config v0.3.19
│   ├── log v0.4.14
│   │   └── cfg-if v1.0.0
│   └── url v2.2.1
│       ├── form_urlencoded v1.0.1
│       │   ├── matches v0.1.8
│       │   └── percent-encoding v2.1.0
│       ├── idna v0.2.3
│       │   ├── matches v0.1.8
│       │   ├── unicode-bidi v0.3.5
│       │   │   └── matches v0.1.8
│       │   └── unicode-normalization v0.1.17
│       │       └── tinyvec v1.2.0
│       │           └── tinyvec_macros v0.1.0
│       ├── matches v0.1.8
│       └── percent-encoding v2.1.0
├── glob v0.3.0
├── lazy_static v1.4.0
├── libc v0.2.93
├── locale v0.2.2 (*)
├── log v0.4.14 (*)
├── natord v1.0.9
├── num_cpus v1.13.0
│   └── libc v0.2.93
├── number_prefix v0.4.0
├── scoped_threadpool v0.1.9
├── term_grid v0.2.0
│   └── unicode-width v0.1.8
├── terminal_size v0.1.16
│   └── libc v0.2.93
├── unicode-width v0.1.8
├── users v0.11.0
│   ├── libc v0.2.93
│   └── log v0.4.14 (*)
└── zoneinfo_compiled v0.5.1
    ├── byteorder v1.4.3
    └── datetime v0.5.2 (*)
[build-dependencies]
└── datetime v0.5.2 (*)

Je comprendrai jamais les langages où les gestionnaires de paquets contiennent des modules avec une fonction unique.

[locus]

Tant que des OS sont écrits en C tu veux dire ? Je crains fort que l'on doive attendre longtemps alors...

Tant que la majorité des libs/bibliothéques internes ou externes utilisées (par des projets ou des entreprises) sont en C ou C++, cela va décourager beaucoup de boites de se lancer dans des projets RUST car ils n'auront pas la certitude que des libs incontournables pour leurs projets pourront fonctionner en Rust de manière optimale ou de la pérennisation du projet. ils n'auront pas le temps de tester chaque lib.

C'est déjà arrivé sur des projets initialement prévus sur python qui ont été revus pour devenir du pur C++ à cause des craintes de réutilisation.

[Aiekick]

Rust remplace le C pour ceux qui préfèrent le Rust au C, ce qui n'est pas du tout la même chose .

ca me semblat evident mais a priori il faut reexpliquer... par "remplacer a merveille le c" c'est "il peut faire tout ce que peu faire le c" a part peu etre l'integration de code asm, quoi que.

evidemment que les gens font ce qu'ils veulent, mais je ne parlais pas de ca..........

[Pyramidev]

Le gros problème de Rust, c'est qu'il a copié npm.

Si c'est l'aspect cybersécurité qui t'inquiète, il faut noter la présence du projet CREV (Code REView) qui permet de partager des audits sur les crates de crates.io.
Pour l'instant, il y a encore énormément de crates importants pour lesquels il n'y a pas encore d'audit. Mais cela va s'améliorer petit à petit.

a part peu etre l'integration de code asm, quoi que.

Oui, Rust permet d'intégrer de l'assembleur :
https://doc.rust-lang.org/stable/rus...nsafe/asm.html
https://doc.rust-lang.org/stable/ref...-assembly.html

[Jamatronic]

Alors perso, dans le domaine du jeu vidéo, j'ai très rarement besoin de listes chaînées.

Dans une Liste Chaînée, on peut insérer ou supprimer un élément sans modifier l'ordre des autres et temps constant.

J'en vois plein d'utilisations possibles dans le JV.

[Bousk]

Dans une Liste Chaînée, on peut insérer ou supprimer un élément sans modifier l'ordre des autres et temps constant.

J'en vois plein d'utilisations possibles dans le JV.

On peut en imaginer pleins avec ces avantages, mais les simple cache-miss font qu'une liste chaînée dans un code de JV est très rare. Je me souviens pas en avoir rencontré une, encore moins écrit une depuis des années.
Si je prends la codebase de UE5, j'en compte 7 non intrusives, donc qui ne contiennent que des pointeurs vers des éléments et n'en ont pas la responsibilité, et 10 intrusives, principalement dans les systèmes de shader et qui utilisent des allocateurs custom qui allouent les éléments linéairement pour éviter les cache-miss.