Discussion :

[floyer]

Il n'y a plus d'environnement simple et enthousiasment de nos jours, parce qu'il y a trop de couche. Dans l'idéale, j'aimerais qu'en allumant un vieux PC, on tombe directement sur un environnement simple et pouvoir faire de suite qlq petites choses.

Si, si... prends le système FORTH... soit deux couches (un système d'exploitation et FORTH lui même), soit des environnements qui se passent du système d'exploitation. (Recherche Google "FORTH bare metal"). Il existe des versions pour ESP32 ou Arduino (entre autre !)

Cela peut te rappeler ce temps des ordinateurs des années 80 (en particulier le Jupiter ACE qui ne se programmait pas en BASIC mais en FORTH).

J'ai beaucoup aimé ce language. Bon, ok, il a des côtés arides (pas de protection mémoire... ni vérification de type, pire que le C, notation polonaise inverse). Mais contrairement au BASIC de l'époque, tu pouvais créer tes propres "mots" (on évite les GOSUB 1000 peu mémotechniques). Il y a un astucieux mélange interprété/compilé qui produit du code rapide (ou plutôt une liste de routine assembleur à appeler... https://en.wikipedia.org/wiki/Threaded_code). Ce mélange permet typiquement de créer des instructions qui génèrent du code... et les mots de contrôle de flux (IF THEN, LOOP...) sont eux mêmes écrits en FORTH. Comme tu crées tes mots, il n'y a pas de commande RUN comme en BASIC. Tapes simplement dans l'interpréteur un des mots que tu souhaites exécuter, et c'est exécuté.

Même si j'ai beaucoup apprécié ce langage (qui a décuplé la puissance de mon PC sous BASIC interprété), il n'a pas rivalisé avec le Turbo Pascal à l'époque. Mais je reconnais le côté ingénieux et optimisé pour des environnements contraints (il y a aussi des microprocesseurs optimisés pour FORTH).

[OuftiBoy]

Si, si... prends le système FORTH... soit deux couches (un système d'exploitation et FORTH lui même), soit des environnements qui se passent du système d'exploitation. (Recherche Google "FORTH bare metal"). Il existe des versions pour ESP32 ou Arduino (entre autre !)

Oui, je connais cela, L'ESP32, Arduino, le Rpi, mais c'est pas tout à fait ce que je recherche a "reproduire".

Cela peut te rappeler ce temps des ordinateurs des années 80 (en particulier le Jupiter ACE qui ne se programmait pas en BASIC mais en FORTH).

Mes 2 références, c'est la Colecovision et le C64. L'ideé derrière mon projet; c'est que tu allume ton portable, est que tu arrive le plus directement possible sur un "moniteur" du genre du C64. Sans devoir installer des outils qui s'emboitent les uns sur les autres. Non, l'idée c'est vraiment d'arriver le plus vite possible (en bootant via une clef USB par exemple) dans un environnement "confiné", d'où tu ne peux même pas lancer une application windows (ou linux). Une fois sur ce moniteur, tu pourrais charger des "jeux", programmer dans un langage très très simple, ou lancer un mode "Desktop" ou tu peut créer des jeux ou des programme "style mode texte" (sans support de souris par exemple) via le langage/compilateur que je suis en train d'écrire. Ce n'est qu'une brique du projet. Je veux éviter le écosystèmes comme Arduino, ESP32 qui sont plus orienté bidouilleur. Forth, je ne connais pas bien.

J'ai beaucoup aimé ce language. Bon, ok, il a des côtés arides (pas de protection mémoire... ni vérification de type, pire que le C, notation polonaise inverse). Mais contrairement au BASIC de l'époque, tu pouvais créer tes propres "mots" (on évite les GOSUB 1000 peu mémotechniques). Il y a un astucieux mélange interprété/compilé qui produit du code rapide (ou plutôt une liste de routine assembleur à appeler... https://en.wikipedia.org/wiki/Threaded_code). Ce mélange permet typiquement de créer des instructions qui génèrent du code... et les mots de contrôle de flux (IF THEN, LOOP...) sont eux mêmes écrits en FORTH. Comme tu crées tes mots, il n'y a pas de commande RUN comme en BASIC. Tapes simplement dans l'interpréteur un des mots que tu souhaites exécuter, et c'est exécuté. Même si j'ai beaucoup apprécié ce langage (qui a décuplé la puissance de mon PC sous BASIC interprété), il n'a pas rivalisé avec le Turbo Pascal à l'époque. Mais je reconnais le côté ingénieux et optimisé pour des environnements contraints (il y a aussi des microprocesseurs optimisés pour FORTH).

Ah le turbo pascal et le turbo c, que du bonheur

BàT et Peace & Love.

[fdecode]

Mes 2 références, c'est la Colecovision et le C64. L'ideé derrière mon projet; c'est que tu allume ton portable, est que tu arrive le plus directement possible sur un "moniteur" du genre du C64. Sans devoir installer des outils qui s'emboitent les uns sur les autres. Non, l'idée c'est vraiment d'arriver le plus vite possible (en bootant via une clef USB par exemple) dans un environnement "confiné", d'où tu ne peux même pas lancer une application windows (ou linux). Une fois sur ce moniteur, tu pourrais charger des "jeux", programmer dans un langage très très simple, ou lancer un mode "Desktop" ou tu peut créer des jeux ou des programme "style mode texte" (sans support de souris par exemple) via le langage/compilateur que je suis en train d'écrire. Ce n'est qu'une brique du projet. Je veux éviter le écosystèmes comme Arduino, ESP32 qui sont plus orienté bidouilleur. Forth, je ne connais pas bien.

C'est un système confiné pour un matériel donné que vous cherchez à développer, ou un système confiné qui peut se lancer à partir d'un système existant?

[floyer]

Je pensais au FORTH car il correspond à cet aspect minimum de couches : byok tourne sur du PC bare metal (sans OS), et F83 sur FreeDOS qui est un OS très léger. Mais je ne pense pas que byok te permette de sauver ou éditer des programmes. F83 est celui que j’utilisais. Dans des versions comme F83, FORTH est un environment qui permet d’éditer tes programmes, les charger/compiler, les exécuter, voire les debugguer.

Ceci-dit, FORTH est très spécial… pas sûr qu’il te plaise ! Son aspect non sécurisé et bas niveau m’en fait préférer d’autres.

[OuftiBoy]

C'est un système confiné pour un matériel donné que vous cherchez à développer, ou un système confiné qui peut se lancer à partir d'un système existant?

J'aimerais bien, dans l'absolu, que ce soit pour un matériel donné, mais je n'ai ni le temps, ni la compétence pour créer et/ou faire ce matériel, qui serait invendable de toute façon.

Donc, le mieux que je pourrais faire, c'est de "booté" via un systeme existant, le plus léger possible, et qu'une seule application ne soit lancée. Recycler des vieux portable qui ne sont plus suffisants pour faire tourner unsystème "moderne".

Le compilateur tel que je suis en train de la construire, passe par un IRC (Intermediate Code Representation) et produit acuellement un "code assembleur" que je fais évoluer au grès de mes besoins. Mais ce n'est pas impensable de pouvoir générer du code assembleur pour le C64, le WebAssembly, ou du code x86 ou même Arm.

BàV et Peace & Love.

[floyer]

L’OS le plus léger possible, c’est vague… FreeDOS peut coller à la définition (20Mo), mais 16bits non protégé, un peu dépassé. Damn Small Linux devrait être plus adapté. (Moins de 50Mo). Tu peux aussi dériver une version réduite de FreeBSD avec NanoBSD ou TinyBSD. (J’avais ainsi fait une version limitée qui tenait sur une disquette avec picoBSD qui n’est plus maintenu… l’objectif monter un TP réseau avec un OS disposant de capacités de routage et de vlan pour simuler des liens à travers la salle)

[OuftiBoy]

L’OS le plus léger possible, c’est vague… FreeDOS peut coller à la définition (20Mo), mais 16bits non protégé, un peu dépassé. Damn Small Linux devrait être plus adapté. (Moins de 50Mo). Tu peux aussi dériver une version réduite de FreeBSD avec NanoBSD ou TinyBSD. (J’avais ainsi fait une version limitée qui tenait sur une disquette avec picoBSD qui n’est plus maintenu… l’objectif monter un TP réseau avec un OS disposant de capacités de routage et de vlan pour simuler des liens à travers la salle)

La première étape sera certainement que mon "système" se charge comme un jeu, prenant pour lui l'écran et le clavier.

Ce sont des pistes que je vais explorer, mais dans un second temps. Il faut un minimum pour pouvoir faire un affichage correct. Bref, j'ai encore du taf pour longtemps, j'en suis bien conscient.

J'ai pensé à FreeDOS, qu'il soit dépassé ou en 16bits non protégé n'est pas un soucis en soit. Le C64 n'avais que 64k de ram et pourtant on a réalisé des choses magnifiques avec très peu de choses en fait. C'est plutôt vers là que se dirige mon petit projet.

Je me souviens que j'avais dans le temps une disquette 1'44 sur laquelle une version de QNX (un RTOS) tournait très bien et avec une GUI relativement moderne.

BàT et Peace & Love

[Patrick Ruiz]

Linus Torvalds s’exprime à nouveau à propos du débat sur le choix entre C ou Rust pour le développement du noyau Linux
Et laisse entendre que le Rust peut aider à corriger des erreurs commises en C

Après plus de 30 ans, un deuxième langage a fait l’objet d’adoption pour le développement du noyau Linux : Le Rust. La situation à date est telle que les mainteneurs habitués au langage C refusent de porter le code existant en Rust ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. Linus Torvalds s’est à nouveau exprimé sur ce débat et il en ressort que le langage Rust peut aider à corriger des erreurs commises en langage C.

« Le C est, en fin de compte, un langage très simple. C'est l'une des raisons pour lesquelles j'apprécie le C et pour lesquelles beaucoup de programmeurs C apprécient le C, même si le revers de la médaille est évidemment que, parce qu'il est simple, il est aussi très facile de faire des erreurs », a-t-il déclaré.

En effet, Linus Torvalds est d’avis que le langage Rust est une solution d’avenir pour le développement du noyau. Il considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Mais Les habitués du langage C n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du Rust

Les mainteneurs du noyau réfractaires à la mise à jour des bases de code du noyau Linux vers le langage Rust ont fait savoir quelle est leur position lors d’une présentation des systèmes de fichiers Linux et des besoins en termes de migration des bases de code vers le Rust. Il était question pour ces derniers de créer des passerelles permettant de faciliter l’atteinte de cet objectif. L'un des membres de l'auditoire a exprimé son désaccord en disant : « Vous essayez de convaincre tout le monde de passer à la religion du Rust, mais cela n’arrivera pas. »

Ces derniers multiplient donc des attitudes qui frustrent certains mainteneurs Rust qui choisissent de quitter le navire : « Ce type de traitement est exactement la raison pour laquelle j'ai entamé le projet @redox_os en partant de zéro et en l'écrivant principalement en Rust. Il y a beaucoup de résistance aux changements bénéfiques, même mineurs, dans Linux et les projets connexes. C’est la raison pour laquelle je n'essaie même plus de contribuer au noyau Linux. Il y a des projets pour lesquels vous devrez inévitablement faire passer vos changements devant des mégalomanes pédants et condescendants, et si le noyau Linux n'est pas seulement développé par ce type de personnalité, il est aussi contrôlé par lui de manière écrasante. »

Source : Linus Torvalds

Et vous ?

Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[smarties]

Si ça se trouve, ça va se terminer dans plusieurs années avec Redox OS aura rattrapé son retard en ayant récupéré tous les développeurs Rust qui sont sur le noyau C (pour les raisons évidemment citées du créateur de RedoxOS)... Et les utilisateurs (particuliers et entreprises) migreront vers celui-ci car Rust offre la sécurité mémoire sans impacter 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.

[Zeeraptor]

En gros,des tableaux sécurisés avec une notion système?

Et au niveaux du multithreading,+ facile avec Rust?

En regardant Le tuto basique du site officiel,comparé a du openMP,c'est sans équivoque

Mais le Multithread du C standard reste abordable(+ que l'openMP...qui est ultra difficile)

[NotABread]

Le multithread est assez simple en Rust. Tu peux utiliser tokio pour te faciliter la vie, sinon tu as des thread que tu peux créer assez simplement, ou utiliser des coroutines (fonction marquée async).
J'ai l'impression que les coroutines restent privilégiée car la répartition de leur exécution sir les threads est faite efficacement de base.
Le plus dur, c'est de satisfaire le borrow checker qui demandera que le thread/la coroutine possède ce qu'il veut modifier ou que les potentiels data race soient protégés par des types sûrs (et attention, le compilo ne protège pas du dead lock ni des goulots d'étranglement).

Le point un peu genant c'est que selon les dépendances dont tu as besoin, tu peux te retrouver forcer à utiliser une solution car chaque runtime (tokio et consoeur) fait sa vie de son côté et ne regarde pas ce que font les voisins

[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*»

[Uther]

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

La question de ce qu'est un langage de haut niveau reste en effet nébuleuse, il n'y a pas de définition officielle, je pense qu'il faut prendre l'habitude de préciser ce que l'on entend entre les différents types de classification:

• Le dépendance au processeur :
  C'est en effet la première définition historique. Tous les langages d'assemblage sont de bas niveau. Il ne s'agit pas d'un seul langage, car parler d'assembleur est une généralisation, il y a en fait plusieurs langages différents, au moins un par architecture, et même sur la même architecture il peut y avoir des syntaxe différentes.
  Tout le reste est un langage de haut niveau, aussi bien C, C++, Python, JavaScript que Rust.

• Le langage système:
  Un langage système permet de manipuler assez précisément des notions proches du matériel comme la mémoire via des pointeurs ou assimilé. Dans ce cas là C, C++ et Rust sont des langages système que Python et JavaScript ne le sont pas.

• Le niveau d'abstraction:
  Certains langages peuvent fournir des moyen d'abstraire certaines chose sans que ça soit forcément impactant sur les performances. C offre les fonctions, les structures et les unions, mais ça reste très limité. Les vieux Basic (avant Visual Basic), même si il étaient dépendants d'un interpréteurs, étaient aussi dans ce cas là. On peut dire que ces langages ont un faible niveau d'abstraction
  D'autres langages offrent des concepts plus abstraits comme les classes(C++, JavaScript), traits(Rust), générique(C++,Rust), programmation logique(Prolog), par liste (Lisp). On peut dire que ces langages ont un haut niveau d'abstraction.

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

Même ça, ça n'est plus tout a fait vrai, les compilateur C avancés modernes comme gcc ou clang sont des monstres d'optimisation qui peuvent surprendre.

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

Oui en Rust les références sont de simple pointeurs bas niveau. La différence et que le compilateur surveille la façon dont ils sont utilisés et leve une erreur si leur usage est susceptible de commettre une erreur mémoire.
Rust a aussi des pointeur simples, mais ils ne sont déréférençables que sans les blocs unsafe