Discussion :

[OuftiBoy]

Salut Uther. On est pas obligé d'être d'accord, mais c'est sympa de pouvoir dialoguer/débattre avec toi.

Pour la dixième fois (a peu près) : on ne parle pas de réécrire tout Linux mais de permettre d'écrire de nouveaux drivers en Rust.

Je sais, tu l'as dis 10x, j'ai bien vu passer tes réponses. Mais une fois acccepté pour des drivers isolés, ça évoluera et linux deviendra un mixte de code en C et Rust. Une fois le ver dans le fruit, il le mange. On rentre par une petite porte sur le côté, puis ça s'installe partout. C'est peut-etre le danger que resentent les anciens. C'est une situation qui peu étre mal vécue. Ce n'est peut-être pas l'intention de la communauté Rust, mais c'est un reflexe humain.

Je ne dirais pas que le bloc unsafe retire tant de garanties que ça. Les garanties apportées par Rust restent valides sur la très grande majorité du code. Oui il faut être particulièrement prudent à ce que l'on fait dans les bloc unsafe, mais ils restent normalement exceptionnels et le fait qu'ils soient marqué comme tel, fait qu'on sait où concentrer la relecture.

Oui, dans un monde idéal, ça devrais être le cas, mais la nature humaine étant ce qu'elle est, ce mode "unsafe" sera utilisé plus que nécessaire, volontairement ou pas. Mais je suis d'accord avec toi sur le fait qu'ils "marquent" un code auquel il faut faire attention.

Pour le moment on a en est juste a ajouter des nouveaux drivers expérimentaux, principalement pour du matériel qui tourne sur des machines récentes supportées par le compilateur Rust. Si un jour on veut remplacer les driver C actuels par des drivers en Rust ça deviendrait un problème, mais on y est pas encore. D'ici là, il est probable qu'au moins un des deux projets en cours qui visent a avoir un compilateur Rust avec un backend GCC soit fonctionnel.

Si un jour on veut remplacer les driver C actuels par des drivers en Rust ça deviendrait un problème
Oui, ça devriendrait un problème, et pour ma part, je pense que ça arrivera.

Oui mais pour le coup un alpiniste ne s'entraine pas dans les escaliers.

Belle réplique, ça m'a fait sourire, une réplique à la Audiar. Chapeau l'artiste.

Rust est un langage globalement adapté, on le sait, mais au bout d'un moment il faut s'attaquer au vrai problème pour avancer. Le fait que le projet Rust for Linux tourne soit intégré à Linux, a permis d'identifier les problèmes qui sont en cours de correction. Le projet restant optionnel : on peut toujours construire un noyau Linux sans Rust.

Oui, on peut toujours, mais je reste sur ma position, s'il y a trop de code Rust qui entre dans le linux (quelque soit le niveau), il faudra à l'avenir maintenir cela. Vérification du code de deux langages, ainsi que leur intéractions, donc du travail en plus. Puis, on en a vu passer des langages tentant de "remplacer" C, et ils sont maintenant complètement oubliés.

on peut toujours construire un noyau Linux sans Rust.
Pour la onzième fois (à peu près), on ne force à personne à se mettre au Rust. On permet juste a ceux qui le veulent d'expérimenter l'introduction de Rust dans les drivers. Linux c'est construit autour de ce que permettait C pendant 30 ans. C'est normal qu'un langage qui arrive en cours de route ait besoin de travail pour s'intégrer a l'existant, c'est le travail qui est en cours.

On ne force personne à se mettre au 'Rust', je suis bien d'accord. Qu'on l'utilise à la place du C dans de nouveau projets, libre à chacuns de choisir ses outils. Mais si on accepte 'Rust' dans la base de code linux, d'autres risques également d'y entrer. Et quoi qu'on en dise, avoir 2 langages dans une même base de code, c'est pour moi une mauvaise idées.

Pour la douzième fois (à peu près), on exige rien à ce niveau non plus des gens qui travaillent sur le noyau Linux.
Il y a deux projet actuellement en cours avec des gens qui n'ont rien a voir avec le noyau Linux et qui travaillent là dessus, parce que ça les intéresse. Mais faire un compilateur, ça tombe pas du ciel, c'est techniquement aussi complexe que faire un OS, voire plus quand on travaille sur des compilateurs du niveau de GCC.

Je confirme, écrire un OS c'est loin d'être compliqué (je l'ai vécu en créant un petit RTOS), quand au développement d'un compilateur, c'est aussi très compliqué une fois qu'on sort des petits exemples qu'on trouve sur le net. Je suis en train d'en construire un "from scratch", pour un nouveau lanagage, pour le fun quand j'ai le temps, et c'est effectivement très difficile, une multitude de petits détails complique les choses.

Pour la treizième fois (à peu près), les gens du projet Rust for Linux n'exigent rien des développeurs Linux actuels.
Pour continuer l’analogie, on est dans le cas d'un étranger qui fait tout ce qu'il faut pour s'intégrer mais qui est quand même victime de racisme.

Mon analogie ne visait personne en particulier, et je n'ai pas envie de rentrer dans un débat "politique" (qui n'a pas ça place ici). Mais force est de constater que faire cohabiter 2 "choses", (ici 2 langages), n'apporte pas forcément une plus-value.

Pas de soucis, moi aussi sur le forum j'ai tendance a passer du tutoiement au vouvoiement, et inversement, sans m'en rendre compte.

Moi aussi

Oui j'ai oublié de préciser que je parlais dans le contexte du développement d'OS où on a pas encore assez de retour pour être absolument formel. Mais de manière globale je suis totalement d'accord avec votre point de vue.

Yes !

Il évolue, mais de manière rétrocompatible donc pas vraiment dangereuse.

Mais ne dit qu'un jour ce ne sera pas le cas. Le 'C' étant là et pour toujours, c'est une sécurité.

En gros, pas grand chose. De ce que je vois en suivant les rapport d'avancement de rust_codegen_gcc, le back-end gcc est globalement adapté, il y a juste des petits patchs nécessaires pour bien gérer certains détails.

Tant mieux, mais il faut finir ce travail avant de penser à autre chose. Il existe aussi le risque d'un "fork", où on aurait d'un côté un "linux" avec une code de base en 'C', et un autre avec dus 'Rust' en plus dedans. Et en y réfléchissant, c'est ce que devrait faire l'équipe 'Rust'. Faire un fork, le remanier comme ils l'entendent, y faire leur changement, puis laisser choisir qui s'oriente vers quoi. On constatera si l'ajout de 'Rust' apporte plus d'avantage que d'inconvéniants, tout en laissant actuellement la base de code linux en pur 'C'

Ce n'est que la liste des cibles dites de tiers 1, dont le projet Rust garantit lui même un support complet. Si on rajoute les cible Tiers 2 et Tiers 3 ça fait plus. De plus Linux n'est de toute façon pas capable de fonctionner sur tous les microcontrôleurs que tu évoques. Si on fait le croisement entre les cibles que Linux supporte et celles que le compilateur Rust actuel supporte, il ne doit pas en manquer tant que ça.

J'ai du mal m'exprimer. Je ne pensait pas une seule seconde à faire tourner linux sur des petits µControlleur. Je disais juste que le 'C' est la seul offre (et parfois même l'aasembleur), et qu'avoir un compilateur 'Rust' pour une grande majorité des µControlleur reste pour le moment un doux fantasme. Qui de toute façon n'apporterait rien, puisque l'on de devra pratiquement tout faire en mode "unsafe".

Si c'était le cas Rust ne serait pas a la mode, car il faut plus d'efforts pour maitriser le Rust que le C.

Oui, rien qu'en regardant la syntaxe, ça saute aux yeux. Et s'il est plus difficile à apprendre que le 'C', les gens resteront sur 'C'. Là on est un peut dans le 'Pourquoi faire simple quand on peut faire compliqué'.

Tu dis: "Si c'était le cas Rust ne serait pas a la mode". et c'est cela qui est le plus a craindre, c'est qu'il ne reste pas "à la mode" (personne ne peut prédire l'avenir). Le 'C', lui, n'est pas une 'mode'.

BàT et merci d'échanger courtoisement.

Peace & Love.

[floyer]

Tant mieux, mais il faut finir ce travail avant de penser à autre chose. Il existe aussi le risque d'un "fork", où on aurait d'un côté un "linux" avec une code de base en 'C', et un autre avec dus 'Rust' en plus dedans. Et en y réfléchissant, c'est ce que devrait faire l'équipe 'Rust'. Faire un fork, le remanier comme ils l'entendent, y faire leur changement, puis laisser choisir qui s'oriente vers quoi. On constatera si l'ajout de 'Rust' apporte plus d'avantage que d'inconvéniants, tout en laissant actuellement la base de code linux en pur 'C'

L'utilisateur final ne regardera que les fonctionnalités. Si la version avec Rust apporte un driver incontournable pour certains ou un système de fichiers "must-have", cette version aura peut-être plus de succès. Si le fork peine à intégrer les évolutions de la version originale... il ne s'imposera pas. Ceci-dit, il y a déjà des forks ou des choses qui s'y apparente (OpenVZ ? patch RT ?), mais est-ce une bonne chose ? Si je veux les avantages de tel fork et de tel autre, je serais embêté, alors qu'une version unique offrirait toute les fonctionnalités.

J'ai du mal m'exprimer. Je ne pensait pas une seule seconde à faire tourner linux sur des petits µControlleur. Je disais juste que le 'C' est la seul offre (et parfois même l'aasembleur), et qu'avoir un compilateur 'Rust' pour une grande majorité des µControlleur reste pour le moment un doux fantasme. Qui de toute façon n'apporterait rien, puisque l'on de devra pratiquement tout faire en mode "unsafe".

Pas, sûr. Peut-être des fonctions unsafe aux interfaces, mais le coeur du programme en safe. Après, Rust est intéressant lorsqu'il y a des structures de données (avec allocation dynamique), de l'asynchrone (risque de race condition). Sur un µControlleur, j'imagine peu d'applications avec des besoins de gestion mémoire particulier. L'asynchrone, à voir.

Oui, rien qu'en regardant la syntaxe, ça saute aux yeux. Et s'il est plus difficile à apprendre que le 'C', les gens resteront sur 'C'. Là on est un peut dans le 'Pourquoi faire simple quand on peut faire compliqué'.

C++ est plus compliqué que C, pourtant il s'est imposé dans certains contexte. ET l'idée de Rust, est de rendre l'écriture de code buggué plus difficile. Cela peut justifier une écriture plus difficile car les les règles sur les emprunts empêchent de compiler quelque chose sur lequel le compilateur a des doutes.

Tu dis: "Si c'était le cas Rust ne serait pas a la mode". et c'est cela qui est le plus a craindre, c'est qu'il ne reste pas "à la mode" (personne ne peut prédire l'avenir). Le 'C', lui, n'est pas une 'mode'.

Le succès d'un langage dépend des qualités intrinsèques, de l'écosystème (outils, bibliothèques), et des promoteurs derrières (il peut aussi y avoir des aspects coûts qui ont dû plomber ADA avant la disponibilité de GNAT). Derrière Rust, il y a la fondation Mozilla, cela fait quelques gages de pérennité. Il y a un effet oeuf et la poule... le succès d'un langage permet le développement de plus de bibliothèques/outils, ce qui concourt au succès.

[fdecode]

Oui, rien qu'en regardant la syntaxe, ça saute aux yeux.

Un exemple? Cela ne me saute pas aux yeux personnellement.

Et s'il est plus difficile à apprendre que le 'C', les gens resteront sur 'C'. Là on est un peut dans le 'Pourquoi faire simple quand on peut faire compliqué'.

Syntaxiquement et sémantiquement, l'assembleur est plus simple que le C. Et si on veut de la portabilité, un peu de LLVM IR? Curieusement, il n'y a pas foule pour coder dans ces langages.
Mais en réalité, on le comprend très bien: la syntaxe et surtout la sémantique associée sont très utiles d'un point de vue humain; ce sont des outils pour aider les hommes à programmer.

La sémantique de Rust pourrait paraître complexe (de mon point de vue pas tant que ça), mais c'est aussi une aide puissante pour des projets complexes.
Cela demande surtout d’acquérir certains réflexes de programmation, mais cela vient progressivement à force d'être corrigé par le compilateur de Rust (qui est plutôt un bon prof en général).
Pour ce qui est des connaissances de base, si on a utilisé un langage avec gestion directe de la mémoire, on sait très vite utiliser Rust de manière impérative. Et si on est familier des paradigmes de programmation haut niveau des langages "modernes", il est plutôt simple d'utiliser les paradigmes puissants de Rust.

" les gens resteront sur 'C' "
À la bonne heure! Il feront selon leur désir et tant mieux. Les horizons de Rust me semblent plutôt ouverts, sans qu'il y ait besoin de faire des conversions
Éventuellement, je vois plutôt positivement la monté de Rust dans les OS (Linux est un exemple), car cela consolidera et accélèrera peut-être encore plus le développement de Redox, qui est l'OS qui m'intéresse dans le monde du libre.

Tu dis: "Si c'était le cas Rust ne serait pas a la mode". et c'est cela qui est le plus a craindre, c'est qu'il ne reste pas "à la mode" (personne ne peut prédire l'avenir). Le 'C', lui, n'est pas une 'mode'.

Il y a un petit côté sophiste dans l'argumentation. Je ne sais pas ce qu'est une mode. J'utilise un langage quand il m'est utile et agréable.

[fdecode]

Derrière Rust, il y a la fondation Mozilla, cela fait quelques gages de pérennité.

Ce n'est plus Mozilla qui finance Rust, mais la Rust fondation:
https://foundation.rust-lang.org/members/
dont le membres sont:


Mozilla reste identifiée comme membre fondateur, mais n'est que membre "Silver".

[Uther]

Je sais, tu l'as dis 10x, j'ai bien vu passer tes réponses. Mais une fois acccepté pour des drivers isolés, ça évoluera et linux deviendra un mixte de code en C et Rust. Une fois le ver dans le fruit, il le mange. On rentre par une petite porte sur le côté, puis ça s'installe partout. C'est peut-etre le danger que resentent les anciens. C'est une situation qui peu étre mal vécue. Ce n'est peut-être pas l'intention de la communauté Rust, mais c'est un reflexe humain.

Certes mais pour le coup, de l'autre coté, on peu aussi essayer de comprendre les gens qui font un gros travail pour que l'intégration entre C et Rust ce passe au mieux, pour rendre le développement de drivers Linux plus ouvert, plus rapide et plus sûr sans impacter l'existant, et qui se font limite cracher dessus.

Oui, dans un monde idéal, ça devrais être le cas, mais la nature humaine étant ce qu'elle est, ce mode "unsafe" sera utilisé plus que nécessaire, volontairement ou pas. Mais je suis d'accord avec toi sur le fait qu'ils "marquent" un code auquel il faut faire attention.

Rust a déjà presque 10 ans d'ancienneté, il a assez de code publié pour se faire une idée de comment le gens codent avec, et la tendance que vous décrivez n'est clairement pas ce qu'on constate dans la pratique. Le code unsafe n'est clairement pas bien vu quand il est évitable. Dans les projets avec un minimum de suivi, comme c'est le cas pour le noyau Linux, on trouve généralement vite des gens qui vont essayer de retirer les blocs unsafe dispensables.

Oui, rien qu'en regardant la syntaxe, ça saute aux yeux. Et s'il est plus difficile à apprendre que le 'C', les gens resteront sur 'C'. Là on est un peut dans le 'Pourquoi faire simple quand on peut faire compliqué'.

Y'a une question de familiarité avant tout : la syntaxe de C est juste plus naturelle quand on a l'habitude de travailler avec mais elle n'est pas particulièrement simple non plus.
Et si il est plus rapide d'apprendre les concepts de base du C, il est clairement beaucoup plus complexe d'apprendre à bien les maitriser. J'ai beau le connaitre le C depuis plus de 25 ans, je suis bien plus confiant de la qualité de ce que je produit avec du Rust.

[OuftiBoy]

Un exemple? Cela ne me saute pas aux yeux personnellement.

En voici un :

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
 
#[derive(Debug, PartialEq, Copy, Clone)]
enum ShirtColor {
    Red,
    Blue,
}
 
struct Inventory {
    shirts: Vec<ShirtColor>,
}
 
impl Inventory {
    fn giveaway(&self, user_preference: Option<ShirtColor>) -> ShirtColor {
        user_preference.unwrap_or_else(|| self.most_stocked())
    }
 
    fn most_stocked(&self) -> ShirtColor {
        let mut num_red = 0;
        let mut num_blue = 0;
 
        for color in &self.shirts {
            match color {
                ShirtColor::Red => num_red += 1,
                ShirtColor::Blue => num_blue += 1,
            }
        }
        if num_red > num_blue {
            ShirtColor::Red
        } else {
            ShirtColor::Blue
        }
    }
}
 
fn main() {
    let store = Inventory {
        shirts: vec![ShirtColor::Blue, ShirtColor::Red, ShirtColor::Blue],
    };
 
    let user_pref1 = Some(ShirtColor::Red);
    let giveaway1 = store.giveaway(user_pref1);
    println!(
        "The user with preference {:?} gets {:?}",
        user_pref1, giveaway1
    );
 
    let user_pref2 = None;
    let giveaway2 = store.giveaway(user_pref2);
    println!(
        "The user with preference {:?} gets {:?}",
        user_pref2, giveaway2
    );
}

Des "let" et des accolades partout, des ";" inutiles, que fait "vec!" ?, pourquoi la nécessité d'un "!", ça ne saute pas au yeux, et dans user_preference.unwrap_or_else(|| self.most_stocked()) ? n'est pas limpide... des "symboles" qui partent dans tous les sens. Le "formatage" des string via des {} qui ne fait pas mieux que le printf du 'C', avec juste 40 ans de retard. Bref, (mais ce n'est que mon opinion, je ne prétend pas avoir raison) tout un tas de choses qui aurait pu (et qui aurait du) être faite bien mieux, qui semble d'un autre âge, alors que Rust est jeune/vieux de 10ans.
'Rust' me fait penser à un langage qui a été spécifié par des théoriciens "académique", alors que le 'C' a été écrit d'une façon "pratique". Il y a aussi cette manie de changer les noms de choses juste pour le plaisir (les "crates" ça fait plus smarts que module ou lib), un truc qui s'appel cargo.

En fait sans voulir être méchant, 'Rust' existe depuis bien plus que 10 ans, ça s'apelle Ada (utilisé par les militzires Américains) et ça a 40 ans (et dont "Rust' n'est qu'une ré-implémentation des mêmes concepts).

Attention, je répéte que je n'ai rien contre 'Rust'. Je ne suis pas dans une démarche d'évangeliste pour le C. Franchement, j'ai autre chose a faire du temps qu'il me reste. La Syntaxe de 'Rust' est plus proche du 'C++' qui, au fil de ces évolutions, est devenir un brol imbuvable. Je ne suis anti-rien. Mais mon choix c'est porté sur 2 langages. Le 'C' pour l'embarqué, et 'Python' pour le reste.

Syntaxiquement et sémantiquement, l'assembleur est plus simple que le C. Et si on veut de la portabilité, un peu de LLVM IR? Curieusement, il n'y a pas foule pour coder dans ces langages. Mais en réalité, on le comprend très bien: la syntaxe et surtout la sémantique associée sont très utiles d'un point de vue humain; ce sont des outils pour aider les hommes à programmer.

Non, l'assembleur n'est pas "plus simple que le 'C'". Le 'C' est connus pour rester au plus près de la machine, au début on parlait de 'C' comme étant un assembleur de haut niveau. Et qui est assez portable. Oui, il a des défauts, mais rien de dramatique pour un développeur un peu malin. Il a survécu depuis 40 ans à tout une série de "nouveau langage" qui prétendait le supplenter, mais TOUS on échoué. (le dernier qui le prétendait et que j'ai regardé), c'était D. Où est-on avec ce 'D' ? Nulle part. Il y a aussi 'C3' 'ou 'C4', mais la mayonnaise ne semble pas prendre non plus. Il n'y a pas que le langage en lui même, il y a tout une culture, des outils, des libraires "autours" du C.

Oui, 'Rust' et ses concept sont intéressants, Mias le 'C' est tout simplement incontournable.
C'est un peu le 'COBOL' du domaine banquaire, qu'on a essayé de remplacer par C++, puis par Java, et ça n'a jamais abouti à rien.
Tout comme le 'Fortran' pour le monde des matématiciens.

La sémantique de Rust pourrait paraître complexe (de mon point de vue pas tant que ça)

On peut considérer ça comme un point de vue. Elle t'es peut-être famillière. Mais pour un vieux dinosauore qui a fait du C ça spécialité, 'Rust' est verbeux. Et les mécanismes borrow/lifetime sont plus compliqués que de faire de simple un alloc/free en 'C'.

Mais c'est aussi une aide puissante pour des projets complexes.
Cela demande surtout d’acquérir certains réflexes de programmation, mais cela vient progressivement à force d'être corrigé par le compilateur de Rust (qui est plutôt un bon prof en général).

Mais c'est un peu comme pour tout. Est-il si 'inimaginable' pour un développeur qui 'aime/soutient' 'Rust', qu'un développeur maîtrissant le C n'y voit pas grand intérêt ?

Pour ce qui est des connaissances de base, si on a utilisé un langage avec gestion directe de la mémoire, on sait très vite utiliser Rust de manière impérative. Et si on est familier des paradigmes de programmation haut niveau des langages "modernes", il est plutôt simple d'utiliser les paradigmes puissants de Rust.

Je ne dis pas le contraire. Le point de départ de la discution concernant Rust, c'était de l'introduire dans la base de code 'C' de linux., et que je trouvais que ça apportait plus de difficulté que d'avantage. C'est aussi ce que pensent les mainteneurs 'C' du noyau linux. 'Rust' aura peut être disparu dans 10 ans, mais le C sera toujours là, c'est la brique fondamentable du développement de "l'informatique".

Go a disparu, Kotlin surnage, Java est immonde, tous comme l'est le C++, C# change si vite que les auteurs de l'écosystème qui l'entoure n'arrive plus à suivre et son système "d'intellicense", pousse les dèv C# a écrire trop vote et sans réflexion aucune. Il faut même des outils externe (genre Resharper) pour arriver à l'utiliser un peu plus facilement. Pour le bas niveau, le 'C' fait le taf, et pour le haut-niveau, Python fait le 'taf'.

C++ n'a pas remplacé le C. Java n'a pas remplacé le C++, et 'Rust' ne remplacera pas le 'C', pour la simple et bonne raison qu'il ya pleins de langage de plus au niveau qui sont plus abordables, mieux supportés et plus simple pour des logiciels qui n'ont pas a se rapprocher trop du matériel (et qui ont pleins de "wrapper" autours de libs/fonctions écritent en 'C'). Et 'Rust' fera ou fait déjà cela.

Je connais des dizaines d'ingénieurs (je ne parle même pas de pur développeurs) qui font leur petits truc facilement avec Python et pour qui 'Rust' ressemble à Frankenstein, et qui ne comprennent rien quant ils voient du code 'Rust', alors qu'il comprennent en quelque minute un script Python qui fait la même chose mais avec 10 lignes de code au mieu de 50.

" les gens resteront sur 'C' ". À la bonne heure! Il feront selon leur désir et tant mieux. Les horizons de Rust me semblent plutôt ouverts, sans qu'il y ait besoin de faire des conversions

100% d'accord.

Éventuellement, je vois plutôt positivement la monté de Rust dans les OS (Linux est un exemple), car cela consolidera et accélèrera peut-être encore plus le développement de Redox, qui est l'OS qui m'intéresse dans le monde du libre.

En 30 ans, linux a pris (environ) 5% du marché desktop (les serveurs c'est 50-50 avec Windows). Je ne serais plus là dans 30 ans, mais redox (qui est très certainement un projet intéressant) ne fera pas mieux. Même si Microsoft est en train de devenir fou avec les changements de Windows qui se détériore de version en version. Mais comme je disais dans un autre poste, 99% utilise leur OS pour soit lancer un navigateur web, soit pour lancer une application. Pour eux, l'OS c'est comme la dalle qui supporte leur maison.

J'ai appris que redox existait via des réponses dans ce forum, personne ne m'en n'avait jamais parlé avant.

Il y a un petit côté sophiste dans l'argumentation. Je ne sais pas ce qu'est une mode. J'utilise un langage quand il m'est utile et agréable.

Mais si tu sais ce qu'est une "mode", on y a droit tous les deux ans en "informatique". Des exemples ? "Prolog", "RubyOn Rail", "D", "C3/C4", "Les systèmes experts", "les outils case", la "logique floue", les ORM, les BDD orientée Objet et d'autres dont je ne me rappel même plus le nom (Y'a un 'No' dans le nom), la POO, les langages "fonctionnels" (Ocalm, Haskell), Perl, Javascript qui est utilisé, mais qui est une horreure absolue, "Flash", les sites web fait pour les smarphone mais qui sont pénibles a utiliser sur un "deskop", HTML/CSS dont on dit qu'ils sont des langages de programmation, les "framework" web qui existe 2 mois avant d'être remplacé par s'autres, l'IoT. Là maintenant, c'est la mode "IA", une bulle qui va éclater et faire des ravages.

Mais sinon, je pense comme toi, j'utilise les outils dont j'ai besoin, et en quarante ans, 'C' pour l'embarqué et Python pour le reste.

BàT et Peace & Love.