Linus Torvalds l’avait promis lors du dernier Open Source Summit : il pousserait pour l’inclusion de Rust for Linux à la version 6.1 du noyau. La manœuvre est désormais en cours comme le confirme un récent Pull Request. Après 31 ans, un deuxième langage sera donc admis pour le développement du noyau : c’est le Rust. Les débats y relatifs tournent au tour de la possibilité d’une mise au rebut du C au profit du langage Rust compte tenu des avantages qu’il introduit. Petite précision néanmoins : pour le moment, le Rust gagne juste une API officielle pour permettre de développer des modules séparés ou pilotes. Sur la question de l’éventualité d’une mise au rebut du langage C, le créateur du langage C3 liste un ensemble de raisons pour lesquelles les initiatives allant dans ce sens ont de fortes chances d’échouer :
La chaîne d'outils du langage C
Le langage C n'est pas seulement le langage lui-même, mais aussi tous les outils de développement développés pour ce langage. Vous voulez faire une analyse statique de votre code source ? - Il y a beaucoup de gens qui travaillent sur ce sujet pour le C. Des outils pour détecter les fuites de mémoire, les courses de données et autres bogues ? Il y en a beaucoup, même si votre langage est mieux outillé.
Si vous voulez cibler une plateforme obscure, il est probable que vous utilisiez le C. Le statut du C en tant que lingua franca de l'informatique d'aujourd'hui fait qu'il vaut la peine d'écrire des outils pour ce langage, et de nombreux outils sont donc écrits.
Si quelqu'un a mis en place une chaîne d'outils qui fonctionne, pourquoi risquer de changer de langage ? Un "meilleur C" doit apporter beaucoup de productivité supplémentaire pour motiver le temps passé à mettre en place une nouvelle chaîne d'outils. Reste même à savoir si cela est possible.
Les incertitudes d'un nouveau langage
Avant qu'un langage ne soit arrivé à maturité, il est probable qu'il comporte des bogues et qu'il soit modifié de manière significative pour résoudre les problèmes de sémantique du langage. Et le langage est-il même conforme à la publicité ? Il offre peut-être quelque chose comme "des temps de compilation exceptionnels" ou "plus rapide que le C" - mais ces objectifs s'avèrent difficiles à atteindre lorsque le langage ajoute l'ensemble des fonctionnalités.
Et qu'en est-il des mainteneurs ? Bien sûr, un langage open source peut être bifurqué, mais je doute que de nombreuses entreprises soient intéressées par l'utilisation d'un langage qu'elles pourraient être obligées de maintenir plus tard. Parier sur un nouveau langage est un gros risque.
Le fait que le langage pourrait tout simplement ne pas être assez bon
Le langage s'attaque-t-il aux véritables points faibles du C ? Il s'avère que les gens ne sont pas toujours d'accord sur ce que sont les points sensibles du C. L'allocation de mémoire, la gestion des tableaux et des chaînes de caractères sont souvent délicates, mais avec les bonnes bibliothèques et une bonne stratégie mémoire, elles peuvent être minimisées. Le langage ne traite-t-il pas des problèmes dont les utilisateurs avancés ne se soucient pas vraiment ? Si c'est le cas, sa valeur réelle pourrait être beaucoup plus faible que prévu.
Et pire encore, que se passe-t-il si le langage omet des fonctionnalités cruciales qui sont présentes en C ? Des fonctionnalités sur lesquelles les programmeurs avancés du C comptent ? Ce risque est accru si le concepteur du langage n'a pas beaucoup utilisé le C, mais vient du C++, du Java, etc.
L’absence de développeurs expérimentés pour un nouveau langage
Un nouveau langage disposera naturellement d'un groupe beaucoup plus restreint de développeurs expérimentés. Pour toute entreprise de taille moyenne ou grande, c'est un énorme problème. Plus il y a de développeurs disponibles pour une entreprise, mieux elle se porte.
De plus, si l'entreprise a l'expérience du recrutement de développeurs C, elle ne sait pas comment recruter pour ce nouveau langage.
L'ABI C
Si le langage ne peut pas facilement appeler - ou être appelé - par...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par Ti-Slackeux
), lent à compiler etc... mais en tant qu'expert seriez-vous capable de me citer des langages libres (compilateur inclu) qui sont à la fois memory-safe, null-safe, thread-safe et qui ne requirent pas une VM que l'on doit installer et qui doit gérer un système de ramasse-miettes ?