La DARPA veut traduire automatiquement le code C en Rust

Vers un monde rouillé

La DARPA veut traduire automatiquement le code C en Rust

rustacean.net

L'agence américaine travaille sur un convertisseur automatique de code d’un nouveau genre. Nommé TRACTOR, il ambitionne de pouvoir traduire des pans de code C en Rust. Le projet soulève l’enthousiasme, mais ne s’annonce pas comme une solution universelle adaptée à tous les logiciels.

Le 05 août à 12h05

Commentaires (55)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Sans relecture humaine systématique, cela promet d'être bien foireux ...
votre avatar
C'est bien ce qui est évoqué avec la partie traitant du risque du LLM.

Mais si le modèle peut produire 80% de bon et faire que 20% nécessite une correction, c'est déjà un gain de temps considérable. Après, à voir la qualité de l'entraînement du LLM sur ce langage précis.
votre avatar
On n'a qu'à faire relire le code par une IA. :fumer:

Je ne suis pas sûr que l'on ait assez de gens compétents en Rust pour relire tout le code traduit si la DARPA veut faire passer tout le code militaire des USA par la moulinette.

Plus sérieusement, ce code doit avoir des tests automatiques associés et on doit pouvoir vérifier le résultat avec ces tests.
votre avatar
Sauf que pour déterminer quels code est bon et quels codes ne l'ai pas, il faut bien relire l'ensemble du code. Donc le gain de temps est pas vraiment la.
votre avatar
Le potentiel gain de temps est sur la réécriture, la relecture reste indispensable.

Sauf si on considère qu'on pousse en prod le code du stagiaire sans le relire. Perso j'appelle ça de l'incompétence crasse.
votre avatar
Sauf si on considère qu'on pousse en prod le code du stagiaire sans le relire. Perso j'appelle ça de l'incompétence crasse.
Ou quelqu'un qui travaille chez Crowdstrike...

Ok je sors :D
votre avatar
🫵 👉 🚪
votre avatar
Ceci dit bon exemple car il me semble que ce qui a provoqué la panne Crowstrike est que le code a passé les tests de fiabilité justement 😬
votre avatar
Éventuellement ont peu imaginé un système qui va prendre la fonction originale en C(++) et la fonction traduite en Rust et va automatiquement tester une multitude de combinaisons possible et uniquement vérifier que le résultat des deux fonctions soit identique.

Ça fonctionnerait que sur une petite partie du code, mais au moins ça peut donner une bonne indication sur la validité du code traduit.

Et si le code d'origine est déjà associé à des bons tests unitaires/intégration, pas impossible de faire passer le code traduit dedans.

Du coup, en fonction de la confiance que tu accordes au test, la relecture peut être minimisé.
votre avatar
Relire… mais surtout comprendre, être sûr que ce que fait le code Rust correspond à ce que doit faire le code C+/C++ (donc avoir les deux en parallèle).

Bon courage, ça va être un boulot passionnant.
votre avatar
Oui, je suis pas sûr que cela fasse gagner beaucoup de temps si l'idée est d'avoir en résultat un code de qualité, d'autant qu'il faut valider l'architecture logiciel qui à mon avis ne doit pas être automatiquement considérée comme automatiquement la même en passant d'un langage à l'autre. Si le squelette du code n'est in fine pas celui qu'il faudrait choisir, c'est au choix :
1. Tout le code qu'il faut revoir
2. le risque (avec une proportion inconnue) que le code V2 accumule une dette technique difficile à résorber et qui empêche des évolutions lisibles et faciles, quand bien même le code serait fonctionnel au départ.
votre avatar
J'imagine que l'utilisation du terme "passionnant" est ironique :)
votre avatar
S'il n'est donc pas question de traduire les noyaux Linux ou Windows en Rust avec cet outil, peut-être que ça pourrait aider à traduire Wayland, lors de l'adaptation de celui-ci pour Redox et son micro-noyau en Rust.
votre avatar
Merci pour l'info sur Redox :yes:, je connaissais pas :incline:... J'aime beaucoup le concept de micro kernel, malheureusement pas déployé a ma connaissance (sauf pour Minix :p)
votre avatar
La société Chorus (émanation de l'INRIA) avait développé ChorusOS, mais le tout s'est perdu chez Sun.
Quoiqu'il en reste peut-être des traces en open sources, selon en.wikipedia.org Wikipedia
votre avatar
Le problème c'est le narratif autour de Rust. Cela tend à faire croire que tout va bien. Bin non.


Tada: https://www.guideit.fr/la-faille-de-securite-cve-2024-24576-obtient-le-score-cvss-maximal-de-100/#:~:text=Une%20nouvelle%20faille%20de%20s%C3%A9curit%C3%A9,System)%20de%2010%2C0.

Rust tout comme n'importe lequel des langages, dispositifs, Processing Unit et j'en passe n'est et ne sera jamais exempt de faille.

Et l'erreur est 100% d'origine humaine. Même avec une IA puisque qu'elle est construite par un humain.

On peut ajouter que si on avait des vrais standards internationaux ne serait-ce que sur :
* L'encodage des caractères
* Les fichiers de données qui seraient bien mieux avec un manifeste (ex: content type: image, encoding : JPG, vrs:xxx, payload-size, etc.)

...une bonne fois pour toute ce serait bien. Parce que bon; les petites guéguerre géopolitique n'ont fait que foutre le bordel depuis au moins 4 décades.


On a le recul suffisant pour cela aujourd'hui. Et on éviterai un tas de bêtise (et le mot est léger) en construisant des vraies librairies universelles. A titre d'exemple l'implémentation de RegEx dans différents langages fait pousser de cheveux blancs parfois.
votre avatar
C'est quelque chose que j'avais déjà noté dans les communications autour de Rust. Personnellement, je n'ai pas le bagage pour m'en assurer ou comprendre derrière comment ça marche.

Mais ce qui m'inquiète, c'est qu'avec une comm' basée autour de "c'est un langage sécurisé", ça provoque l'effet inverse par aubaine et un nivellement par le bas de la vigilance. La technique ne se suffit pas à elle-même, il ne faut jamais l'oublier.
votre avatar
Je comprends l'idée mais dans la pratique c'est pas du tout ce que l'on constate. Il faut voir que la sécurité mémoire en Rust ne fonctionne pas comme en Java ou Go ou tout est caché derrière un Garbage Collector, en Rust le développeur est juste contraint de prouver au compilateur que son code ne pose pas de problème. Il reste très conscient de ce qu'il faut faire pour assurer la sécurité.

Dire que la sécurité de Rust pousserait à ne pas faire attention au code, ça revient (en très gros) à dire que la ceinture de sécurité pousserait à être imprudent sur la route. Dans la pratique ce n'est pas du tout ce que l'on constate. Au contraire, boucler sa ceinture est un rappel quotidien de l'importance de la sécurité.
votre avatar
Quel narratif autour de Rust tend à faire croire que tout va bien ?

En tant que programmeur C++ pendant 13 ans et pratiquant le Rust régulièrement depuis 2/3 ans. "Mon narratif" c'est que Rust aide beaucoup à faire mieux, plus facilement.
Bien sur Rust à lui seul n’empêche pas la présence d'erreurs, mais il permet d'en éviter beaucoup, permettant ainsi de se concentrer sur une quantité moins importante de questions.
Le langage en lui-même et tous les outils disponibles sont autant de support pour se concentrer sur ce qu'il reste. Une des difficultés étant de savoir ce à quoi il faut toujours faire attention (en plus de l’algorithme en lui même).
Sur de la collaboration ça a son importance par exemple, et je trouve beaucoup plus reposant en Rust de relire le code d'une autre personne pour vérifier s'il semble ok qu'en C++.
votre avatar
Je suis d'accord, peesonnellement, je n'ai jamais compris "rust évitenent toute faille" ou "ouf, plus besoin de gérer la securité", ni entendu/lu personne le dire.

En revanche, ce que j'ai lu, c'est que la mémoire était nativement bien mieux gérée, et que cela suprimait d'office tout en un pan de failles/bug en comparaison (d'autres languages savent le faire). Cela est compréhensible d'amblé mais cela semble aussi être vérifié empiriquement par des audits sur des libs.
votre avatar
Je parle des articles à foison (notamment parus sur ce site) qui sont plus ou moins des annonces. Ex: "Microsoft nous dit qu'il va reprendre tout Windows en Rust"; "passke c'est sécure".

Sous entendu "mettez vous à Rust" ...histoire qu'on puisse faire pression sur les salaires. Une manœuvre parmi tant d'autres.

Ca colle le sticker "sécurité" alors que ce n'est pas censé être la seul chose d'un langage. Et il y en a pas mal des chose a regarder dans un langage.

Et il y a le syndrome "open BSD". Avant sa sortie de la première mouture, ca disait "tain c'est trop sécure". Moins de 15 jours après des gens on trouvé des failles et la grosse rigolade a commencé.

Rust n'y fait pas exception. Et le jour ou tu en a un qui trouve un super gros trou... Ca se passera comme dans l'Internet habituel... pas besoin d'expliquer la déferlante de commentaires de répéteurs lolesque.

Je n'émets pas de critique sur Rust lui même. Pour moi (à mon âge) c'est un énième. Il y a une approche et tant mieux si cela fonctionne.

Mais les schémas se reproduisent. A cause de problèmes plus humain et structurels (voire d'un niveau religieux) on a du mal à améliorer un dispositif existant. L'entrepreneur n'y est pas pour rien non plus (Oracle???). Ca finit par se comporter comme un pachyderme à force d'immobilisme.


Du coups avec l'impatience qui frustre; cela fait "poper" un nouveau venu (comme Rust) un peu naturellement. Parfois en faisant de pires bêtises qu'avant. Ca n'a pas l'air d'être le cas de Rust mais ne jurons de rien.

La formation aussi n'est pas en reste. C'est l'humain qui fait la bêtise de ne pas gérer les erreurs ou de bien contrôler ce qui rentre et sort de ses programmes faute d'y avoir été sensibilisé ou d'avoir un problème de comprenette. Rust ou pas.


Et pour me faire comprendre. Et si on prenait la com' Rust à l'envers pour voir ? S'il se focalise sur la sécurité, y a-t-il des domaines ou c'est pas vraiment au top (gestion de liste, hash et j'en passe)? Vois tu ?



Le problème c'est qu'à chaque tour on revient en arrière. C'est à dire que plus on fait de langages ou cadriciels (dont la plupart restent dans l'oubli) plus on s'éloigne de l'universalisme.

Je ne suis pas un zélote, toutefois on a besoin de bases solides (nos chers libs et fonctionnalités de base). Et bien malheureusement il y a un trop grand nombre de problèmes non adressés sur le plan global.

Le bon sens a du mal a émerger. A chaque article Rust on parle de sécurité. Le bon sens voudrait qu'on parle de tout. Même des gros défauts.



Et comme SEBGF le dis. Restons vigilant.
votre avatar
Sous entendu "mettez vous à Rust" ...histoire qu'on puisse faire pression sur les salaires. Une manœuvre parmi tant d'autres.
J'ai l'impression que beaucoup des gens qui râlent sur Rust le considèrent comme un langage de type Java ou Python. Ça reste un langage de bas niveau avec des considération et des postes similaires. Des comparaisons que j'avais vues, les salaires étaient de l'ordre du C voire plus élevés.

Rust n'y fait pas exception. Et le jour ou tu en a un qui trouve un super gros trou... Ca se passera comme dans l'Internet habituel... pas besoin d'expliquer la déferlante de commentaires de répéteurs lolesque.
Là encore j'ai vraiment l'impression que ça parle de Rust sans bien le comprendre. Rust n'est pas une technologie de sandbox dans laquelle des hackers auraient a chercher des trous mais un langage de programmation qui permet, entre autre, de cadrer la façon dont on manipule les pointeurs pour empêcher les erreurs mémoire. Il y a déjà des bugs connus qui permettraient à du code complètement tordu, de contourner le borrow checker, mais personne n'écrirait ce genre de code.

La formation aussi n'est pas en reste. C'est l'humain qui fait la bêtise de ne pas gérer les erreurs ou de bien contrôler ce qui rentre et sort de ses programmes faute d'y avoir été sensibilisé ou d'avoir un problème de comprenette. Rust ou pas.
La situation continue depuis depuis 50 ans y compris dans les endroits critiques particulièrement surveillés. Si la formation suffisait, on aurait pas 2/3 des vulnérabilités critique causées par des erreurs mémoire dans les base de code C et C++ les plus surveillées (Google, Windows, Linux, Oracle, Apple, ...).
Les gens sont quand même relativement sensibilisé au problèmes du C depuis bien longtemps, particulièrement là ou la sécurité est importante, mais les humains, même les meilleurs et les bien formés sont faillibles.

Et pour me faire comprendre. Et si on prenait la com' Rust à l'envers pour voir ? S'il se focalise sur la sécurité, y a-t-il des domaines ou c'est pas vraiment au top (gestion de liste, hash et j'en passe)? Vois tu ?
En effet Rust n'est pas le meilleur langage pour tout et il ne prétend pas l'être. Aucun langage ne le peux.
Typiquement si la sécurité et la fiabilité ne sont pas un soucis et que les restrictions imposées par Rust posent problème, je ne vais certainement pas te recommander le Rust. Zig peut être une solution intéressante si on veut garder les performances du C avec des fonctionnalité plus modernes et moins de contraintes que le Rust.

Le problème c'est qu'à chaque tour on revient en arrière. C'est à dire que plus on fait de langages ou cadriciels (dont la plupart restent dans l'oubli) plus on s'éloigne de l'universalisme.
Autant la multiplication a l'infini des outils pose soucis. L'universalisme dans les langages, c'est pas une bonne idée non plus.
votre avatar
Le narratif autour de Rust c'est de dire que le langage aide à prévenir les erreurs mémoire, ce qui est globalement vrai, ça offre même pas mal de garanties au delà. Par contre, pas grand monde ne prétend que c'est magique et que ça éviterait de réfléchir à ce que l'on fait.
Rust s'étant construit avec une préoccupation de la sécurité dès son origine, ces limites sont au contraire souvent bien plus prise en compte par l'écosystème qui tourne autour que dans les autres langages.
Les limites de la sécurité fournie par le langages sont plutôt bien documentées.

Là où je vois très souvent un soucis vis a vis de la compréhension de la sécurité, c'est plus au niveau de la promotion du C++. J'ai très souvent entendu dire, y compris par des gens relativement expérimentés que l'utilisation des fonctionnalités post C11 suffit à résoudre les problèmes de sécurité, alors qu'on est vraiment très loin du compte.

L'exemple que tu cites est justement un bon exemple de l’intérêt de Rust pour la sécurité. La base du problème c'est le fonctionnement inattendu de la fonction CreateProcess de l'API (en C) de Windows dans un cas particulier qui permet une injection. La bibliothèque standard de Rust a fourni un échappement automatiquement quand ça a été découvert.
Le problème existe toujours en C et C++ qui font directement appel à l'API problématique de Windows. Ça n'a pas fait l'objet de CVE car on considère que c'est l'utilisateur de l'API qui est censé s'assurer lui même de l'échappement. Dans la pratique c'est terriblement complexe à faire de manière exacte, mais à la limite on pourrait dire que c'est dans la tradition du C : l'utilisateur doit bien maitriser ses outils. Sauf que pour cela, encore faudrait il que la procédure pour bien utiliser la fonction CreateProcess vis à vis de ce risque d'exploitation soit documenté. A ma connaissance, le seul endroit où c'est bien documenté c'est sur le blog du découvreur du problème. Microsoft pas jugé nécessaire ne serais-ce que de mentionner le risque dans sa documentation officielle.
Ça montre clairement que s'il y a un soucis de désintérêt de la sécurité, il n'est clairement pas a chercher du coté du Rust.
votre avatar
"Le problème existe toujours en C et C++ qui font directement appel à l'API problématique de Windows."

Oui et? On est ici dans du code applicatif et si c'est Mozilla qui a initié Rust ce n'est pas pour rien: Quand on fait de l'applicatif en frontal sur internet, cela a du sens. Pour le reste, si un API de l'OS pose pb c'est ici à Microsoft de faire le job, le rôle de l'appelant aidant potentiellement à contrarier l'exploitation mais c'est un emplâtre sur une jambe de bois.

Car pour du code noyau/modules, si c'est pour passer son temps à contourner les barrières d'un langage qui prétends résoudre le problème largement traité de la gestion mémoire, je dirais que pour le C++ l'affaire se discute mais que le C n'est pas délogé. Et je ne parle même pas de code de démarrage ou sur certaines architectures, virer le C serait un retour vers l'assembleur (au lieu d'en avoir besoin de quelques %).

Même pour de l'applicatif, un manque de maturité des chaînes de génération (et leur évolution encore rapide) pose des problèmes aux mainteneurs/distribution.
votre avatar
Pour le reste, si un API de l'OS pose pb c'est ici à Microsoft de faire le job, le rôle de l'appelant aidant potentiellement à contrarier l'exploitation mais c'est un emplâtre sur une jambe de bois.
La solution de fournie par Rust aurait pu être plus simple si Microsoft avait fourni une meilleure API, mais ce n'est pas un emplâtre sur jambe de bois : le problème n'est clairement plus exploitable en Rust contrairement a pas mal d'autre langages.
On est d'accord que Microsoft aurait du faire quelque chose, il ne pouvait probablement pas changer l'API, car cela aurait pu causer des régressions, mais il aurait du au minimum documenter le problème, au mieux il aurait pu fournir une fonction alternative qui n'interprète pas les paramètres qu'on lui passe comme une commande batch.

Il est quand même important de noter que Rust évite de laisser des trous béant au prétexte que ça n'est pas son problème (jusqu'à une certaine limite quand même). L'approche de la sécurité est généralement bien plus sérieuse dans l’environnement Rust que C et C++.

Car pour du code noyau/modules, si c'est pour passer son temps à contourner les barrières d'un langage qui prétends résoudre le problème largement traité de la gestion mémoire, je dirais que pour le C++ l'affaire se discute mais que le C n'est pas délogé. Et je ne parle même pas de code de démarrage ou sur certaines architectures, virer le C serait un retour vers l'assembleur (au lieu d'en avoir besoin de quelques %).
En effet dans les cas ou la majorité du code aurait besoin d'être "unsafe" pour contourner les règles de sécurité du Rust, l'intérêt du Rust est discutable et autant utiliser un autre langage. Mais dans la pratique, ce genre de code est extrêmement rare. On a déjà quelques noyaux d'OS et des modules Linux fait en Rust, et il apparait que la très grande majorité du code n'a pas besoin des blocs "unsafe". En limitant la quantité de code exploitable on améliore grandement la sécurité.

Quand à la sécurité mémoire en C et C++, c'est en effet un problème beaucoup traité, mais absolument pas résolu. Le constat est a peu près le même dans toutes les sociétés qui maintiennent de grosses applications C et C++ surveillées : 2/3 des CVE sont dues a des erreurs mémoire.
votre avatar
je ne sais pas pourquoi, la partie sur "construire un vrai standard international" m'a fait furieusement penser à ça :mad2:
votre avatar
C'est une possibilité en effet.

D'un autre coté on a UTF-8 aujourd'hui. Mais ça a mis le temps. L'humanité s'en porte quand même mieux même s'il a ses travers.
votre avatar
A chaque fois que je lis DARPA, je pense nécessairement à Metal Gear Solid.
Alors c'est C qui fait face à Rust et qui lui demande : "tu veux qu'on se tire l'oreille ?".

Blague à part, s'ils ont un outil qui est capable de comprendre les intentions du code C pour le traduire correctement en Rust, alors ils sont aussi capables de corriger le code C d'origine; comme un analyseur statique de code survitaminé.
votre avatar
J'ai bien peur que cela n'arrive pas.

C'est l'analyse qui permet de faire cela. Le code "déplié" doit permettre de corréler une instruction avec un état de la mémoire A->B. Puis de traduire l'instruction avec son équivalent qui produira le même état mémoire ou très approchant (ou considéré égal). Mais c'est la que les bactéries attaquent.

Je suis pas certain qu'un IA sache faire car il faut conceptualiser... C'est pas le point fort des IA. C'est plus des moulinettes programmables semi autonome.
votre avatar
C'est évidemment une excellente idée, car il faut une entité qui a des moyens pour s'adonner à ce genre de tentative.
Espérons que cela produise bien les résultats escomptés et que l'outil puisse bien aider à la réécriture massive de bouts de code non-triviaux.

Quant à tout le débat sur l'absolue perfection de la sécurité qu'apporterait Rust dans les commentaires : Mouarf.
Est-ce toujours comme cela quand vous n'avez rien à apporter de positif ?

D'ailleurs, on a croisé la faille concernant l'exécution de scripts Windows, faussement attribuée à Rust par les partisans du FUD. Je rappellerai aux personnes de bonne foi (laissant les autres sur le bord de la route) que cela touchait plusieurs langages, dont un n'est pas corrigeable, qui n'était pas Rust.

Il est grand temps de se séparer des tous les problèmes d'une manipulation manuelle de pointeurs mémoire hors des cas où cela est absolument nécessaire.
Pourquoi donc continuer à faire cela, outre une incapacité à accueillir le changement ou de la fierté mal placée ?
L'erreur humaine restera toujours présente : le mieux que l'on puisse faire est d'en réduire la probabilité ainsi que la surface de leurs conséquences.
votre avatar
Dans la mesure ou Rust est vendu comme une solution "sécurisée", cela peut contribuer à justement rendre les développeurs plus négligents.
votre avatar
C’est drôle, c’était l’argument employé par les opposants à l’obligation de la ceinture de sécurité dans les années 1970.
votre avatar
Débattre sur l'utilisation de la ceinture ne correspond pas au sujet de changer de langage de programmation, pour passer d'un langage qui peut être sécurisé à un langage qui peut être sécurisé.
votre avatar
Je suis pas sur d'avoir bien compris ta phrase, mais la comparaison avec la ceinture de sécurité est plutôt valable.

Dans les deux cas, ça reviens à dire qu'une augmentation des mécaniques de sécurité entraine une baisse de la vigilance. Dans la pratique, ça n'est généralement pas ce que l'on constate. En tout cas ça n'est pas le cas de la ceinture et il ne semble pas non plus que ça soit le cas pour Rust.
votre avatar
Changer de langage de programmation a des couts en terme de développement, de compatibilité et de maintenance (rien à voir avec une ceinture donc), et puisque le c/c++ ne disparaitra pas, rust ne fait qu'ajouter de la complexité à un monde déjà assez complexe, si le c/c++ est jugé comme pas assez safe, alors en ce qui me concerne il serait préférable de corriger ces problèmes.

Les langages de programmation bénéficient d'effets de mode, le ruby c'était moderne, le c c'est dépassé, python c'est l'avenir il faut l'apprendre à l'école, etc. Maintenant c'est rust est sécurisé. Quoi qu'on dise c'est ce que la mode veut bien nous faire croire, chose fausse bien sûr. Nous avons eu la chance côté back end d'avoir php qui a été capable de tenir la barre et de permettre un environnement globalement uniformisé, je n'aimerais pas que cela devienne la foire côté bas niveau.
votre avatar
Certes il ne faut pas changer de langage tous les 4 matins pour suivre la dernière mode, il faut mesurer clairement les avantage et les coût d'un changement. Perso le Ruby ne m'a jamais parru intéressant, contrairement au Rust. Mais d'un autre côté, refuser globalement le changement est un vrai problème.

Corriger C et C++, beaucoup ont essayé, mais soit le résultat était très partiel, pas pratique et/ou incompatible. Le résultat général est que ça ne peux pas vraiment se faire bien sans créer autant d'incompatibilités qu'avec un nouveau langage.
C'était l'idée de base de Mozilla avant qu'il investisse dans Rust. ils auraient voulu sécuriser C++ mais ils se sont rendu compte que vu le nombre de changement que ça impliquait il était préférable de partir sur une nouvelle base.

PHP et JavaScript sont d'autre langage qui sont clairement une plaie due à leur héritage. Il sont passés de langage de script simple à des langages complets pas vraiment adaptés à leur usage actuel.
votre avatar
On ne peut pas bâtir une société sur des bases qui ne font que changer. En 2024 c'est un soit disant manque de sécurité qui pousserait à réécrire tout le code de la planète, en 2050 ce sera quoi ? et en 2100 ? sommes nous vraiment si médiocre que l'on est incapable d'évoluer, condamné à stagner ?

Les changements sont nécessaires quand il y a un blocage, je n'en vois pas avec le c/c++.

PHP et JS sont parfaitement adaptés à leur domaine, et pour cause, ce sont les gagnants de la compétition pour ces cas d'utilisation. Flash, java, tout cela a échoué. Pareil pour les divers frameworks backend, VB.NET, et autres perl, aujourd'hui le web moderne c'est php et sql.
votre avatar
Javascript a gagné côté client, car c'est le seul langage utilisable dans chacun des navigateurs aujourd'hui.

Par contre, PHP n'a rien gagné côté backend. Au contraire, il est en perte de vitesse.Il suffit de regarder les enquêtes stackoverflow par exemple (2024, 2023, et les années antérieures sont aussi consultables)

PHP maintient un score relativement "élevé" grâce à Wordpress. Retire wordpress de l'équation, et la part de PHP chute drastiquement. Côté backend, aujourd'hui, on trouve plus de dev en JS, Python, Java ou C# qu'en PHP.

Le web moderne reste sur une base JS et SQL (quasiment incontournable), mais certainement pas PHP pour le back.
votre avatar
PHP représente plus de 75% des backends et si on croit qu'il est en perte de vitesse, c'est parce qu'il continue à avoir des concurrents, comme ruby ou nodejs à l'époque. Ces tentatives sont vouées à l'échec car PHP est trop bien implanté et trop adapté pour son environnement.

Java et C#, et python également, ne sont pas des langages taillé pour le back end, ce sont des langages polyvalent. Mieux vaut utiliser le meilleur outil pour chaque usage.
votre avatar
PHP représente plus de 75% des backends
Source ?
Java et C#, et python également, ne sont pas des langages taillé pour le back end, ce sont des langages polyvalent.
On voit clairement que tu ne connais pas ces langages...

Plus sérieusement, si tu veux avoir un commentaire constructif, je t'invite à :
- sourcer (car balancer des chiffres en l'air ne sert à rien)
- argumenter (en quoi Java, C# ou Python ne sont pas taillés pour le backend ? Pourquoi PHP le serait plus ?)
votre avatar
Voici une source : https://w3techs.com/technologies/overview/programming_language

PHP est un langage orienté back end, ses outils, ses librairies sont spécifiquement faites pour le back end. Cela explique pourquoi le PHP est systématiquement présent, comme une évidence, chez les hébergeurs web, qui constituent internet tel que nous le connaissons.

Python, java, c#, comme je l'ai dit ne sont pas fait pour être des langages backend bien que étant des langages desktop, peuvent remplir les fonctions d'un langage backend.

Ces langages vont en général demander un accès root les empêchant d'être supportés par les hébergeurs, demandant l'utilisation d'un VPS. Très souvent la maintenance du VPS est sous la responsabilité du développeur, et un développeur à moins d'être polyvalent a des connaissances limitées en administration réseau, ce qui est problématique car la sécurisation d'un OS est fondamental pour une application web.

Python quant à lui est beaucoup plus lent que PHP le rendant objectivement inférieur. (ce n'est pas étonnant puisque le python n'a pas été fait pour être un langage spécifique au back end, mais plus un langage facile "fait tout")

Le nombre de lignes nécessaires à la création d'un outil sera toujours plus élevée en java ou en c#, et je n'ai jamais eu de contre exemple. Plus de ligne signifie une maintenance moins simple. Et une maintenance moins simple se traduit par des couts plus élevés en entreprise. D'ailleurs on observe que les salaires de dev java et c# sont en général un peu plus élevés que pour les dev PHP ce qui corrobore mon propos.

En cas de problème de performance, pour du calcul pur, un langage bas niveau s'impose, une situation ou php peut faire office de liant efficace entre les différentes parties.

En ce qui concerne l'utilisation de ce langage bas niveau pour toute l'architecture du backend, bien que certains développeurs courageux se pensent capable de maintenir un backend en c ou en c++ (des outils comme Drogon existent), ils doivent en assumer la complexité, et les risques qui vont avec.

Je comprends que l'on puisse être tenté par apprendre un seul langage et tout faire avec, mais cela n'est à mon sens pas idéal.

J'ajoute une dernière chose : les enquêtes stackoverflow montrant PHP à "20%" ne représente pas son utilisation dans les serveurs backend, elles semblent juste confirmer ma thèse comme quoi les langages sont des modes, que le front end est actuellement très tendance, avec des bootcamps où des débutants peuvent apprendre le "front" ou le python. Cela ne traduit pas la réalité professionnelle. Le backend semble juste être moins sexy comparé à ce qui peut se faire hors back end. Cela n'empêche qu'il est là pour durer.
votre avatar
Voici une source : https://w3techs.com/technologies/overview/programming_language
Tu sembles confondre allègrement popularité et utilisation.

Ton discourt consistant à dire que PHP a gagné la bataille est complètement erroné. La plupart de ceux qui utilisent PHP... ne savent pas qu'ils utilisent PHP ! Si PHP aujourd'hui est aussi utilisé, c'est grâce aux CMS, Wordpress en premier (qui représenterait, à lui seul, plus de 40% des sites internets de la toile).

Maintenant, est-ce que cela veut dire que PHP est populaire ? Non.

Car la popularité d'un langage, c'est son adoption par les développeurs. Pas son utilisation par les personnes qui ne savent même pas qu'il existe. Je suis sûr que 80% des personnes qui ont un site Wordpress ne savent même pas ce qu'est PHP.
Ces langages vont en général demander un accès root les empêchant d'être supportés par les hébergeurs
Complètement faux. Aucun de ces langages ne nécessite un accès root.
Python quant à lui est beaucoup plus lent que PHP le rendant objectivement inférieur
PHP est beaucoup plus lent que le C, le rendant objectivement inférieur.

Plus sérieusement, avant de dire ça, il faut savoir où se trouve le goulot d'étranglement dans ton application. Si ce sont les accès à la base de données par exemple, qu'importe que PHP soit 2x plus rapide que Python. Changer de langage ne te fera rien gagner.
Ce n'est pas étonnant puisque le python n'a pas été fait pour être un langage spécifique au back end, mais plus un langage facile "fait tout"
Non. Python n'a pas été conçu en tant que langage fait tout, mais en tant que langage éducatif. L'important était donc la pédagogie de ses concepts, pas sa rapidité d'exécution.
Le nombre de lignes nécessaires à la création d'un outil sera toujours plus élevée en java ou en c#, et je n'ai jamais eu de contre exemple. Plus de ligne signifie une maintenance moins simple. Et une maintenance moins simple se traduit par des couts plus élevés en entreprise
Absolument pas. Que de contre-vérités. Un plus grand nombre de lignes d'un langage n'a jamais signifié une maintenance moins simple. C'est même parfois le contraire (car on gagne en clarté et en expressivité).
D'ailleurs on observe que les salaires de dev java et c# sont en général un peu plus élevés que pour les dev PHP ce qui corrobore mon propos.
Ca ne corrobore absolument pas ton propos. Les salaires des développeurs sont basés avant tout sur un principe très capitalistique : celui de l'offre et la demande. Rien à voir avec les difficultés supposées de maintenance liées au langage. La seule chose que l'on peut en déduire c'est que nb_dev_php/offre_php > nb_dev_C#/offre_C# (idem avec Java).
En cas de problème de performance, pour du calcul pur, un langage bas niveau s'impose, une situation ou php peut faire office de liant efficace entre les différentes parties.
Et Python excelle dans cette catégorie, beaucoup plus que PHP. Il suffit de regarder les bibliothèques de calculs numériques. Python est très largement dominant sur ce marché (et pas que pour PHP, bien au delà pour C# et Java également).
Je comprends que l'on puisse être tenté par apprendre un seul langage et tout faire avec, mais cela n'est à mon sens pas idéal.
La dessus, nous sommes d'accord. Un langage qui fait tout, ça n'existe pas. Mais ce n'est pas parce qu'un langage fait bien une chose, qu'il ne peut pas faire bien autre chose. Autrement dit, et pour reprendre tes expressions, ce n'est pas parce qu'un langage est adapté au Desktop qu'il n'est pas adapté au backend.

Et ce n'est pas parce qu'un langage est majoritairement utilisé pour une utilisation qu'il est le mieux placé pour cette utilisation. Exemple : javascript, côté client. Ce langage s'est imposé non pas parce que c'est le meilleur (d'un point de vue langage), mais historiquement, car c'est le seul qui est supporté par l'ensemble des navigateurs (bien qu'on commence à avoir WebAssembly ayant un très large support aujourd'hui).

La part d'utilisation de PHP aujourd'hui provient surtout d'un côté historique. Pendant longtemps, c'était le seul langage gratuit et facilement proposable par les hébergeurs. Aujourd'hui, de nombreux hébergeurs proposent des solutions (hors VPS j'entends) pour faire de l'hébergement de site web "non PHP". Et à mon sens, c'est aussi ça qui explique en partie le déclin que l'on peut constater de PHP.

Et honnêtement, dans le cadre de mon travail, je ne vois jamais un projet backend être démarré en PHP juste pour le PHP. Quand le PHP est utilisé, c'est soit :
- qu'il existe déjà des applicatifs en PHP (donc homogénéïté du langage pour éviter d'en avoir 36 en backend)
- que le nouveau projet va s'intégrer dans un projet déjà codé en PHP (typiquement, les plugins pour Wordpress, Joomla, etc.).

Il faut choisir son langage en fonction de son besoin. Mais la vision que tu as du PHP me semble complètement déconnectée de la réalité.

[edit] Forcément, tu as rajouté un paragraphe pendant que je te répondais ;)
J'ajoute une dernière chose : les enquêtes stackoverflow montrant PHP à "20%" ne représente pas son utilisation dans les serveurs backend, elles semblent juste confirmer ma thèse comme quoi les langages sont des modes
C'est effectivement la limite de l'étude. Néanmoins, généralement, qui dit backend dit frontend, et on voit bien la forte demande en frontend (cf. HTML/CSS, quasiment obligatoire), qui représente 50% des projets. Les clients lourds étant en perte de vitesse dans notre monde toujours de plus en plus connecté, on peut supposer que l'utilisation des différents langages qui n'ont pas leur place en front web (comme le C# / Java / Python) sont majoritairement utilisés en back... Pour le JS, c'est plus compliqué d'avoir un avis.
votre avatar
Depuis les débuts de l'informatique, il y a eu plusieurs langages qui cohabitent et ça ne l'a pas empêche d'évoluer bien au contraire. On ne va pas bien sur pas migrer tout le code C en Rust du jour au lendemain. Une migration ça a des coût qui sont a mettre en balance avec les bénéfices. Le but de l'outil que souhaite développer la DARPA vise justement a réduire ce coût.

Le JS malgré son coté peu adapté aux grosses applications, s'est imposé de par le fait qu'il n'y avait pas d'alternative native sur navigateur (ceci dit, avec le développement de WebAssembly, ça pourrait changer à l'avenir). Il c'est répandu ensuite coté backend, en bonne partie grâce aux gens qui, comme vous, préfèrent avoir un seul langage mal adapté que faire l'effort d'en apprendre plusieurs efficaces, mais aussi grâce à npm qui a permis de gérer facilement un écosystème complexe.

Quant a PHP, non seulement il n'a jamais été dominant, sauf dans les CMS, mais il est clairement sur la pente descendante.
votre avatar
PHP est dominant puisqu'il représente plus de 75% des backends, et qu'il est plus simple que ses compétiteurs, qui d'ailleurs cherchent à être polyvalent, assurant un avenir radieux au PHP.

J'ai dû mal me faire comprendre, je crois en la nécessité d'avoir un langage par cas d'utilisation. On ne fait pas de desktop avec un langage backend, et inversement. Utiliser JS pour le front et le back, c'est une expérience qui s'est soldée par un échec pour ma part. Nodejs n'a pas réussi et n'arrivera pas à remplacer PHP, fort heureusement.
votre avatar
Sauf que là vous décrétez les langages à conserver selon les critères qui vous plaisent, au moment ou ça vous arrange.

Si on avait interdit les langages qui ont déjà un concurrent installé qui répond au même cas d'utilisation, le PHP n'existerait pas : le Perl faisait le boulot longtemps avant que le PHP ne devienne utilisable pour autre chose qu'un site perso. Le C++ n'existerait pas non plus, vu qu'au final il ne couvre pas de domaine que le C ne puisse aussi couvrir.

Même la notion de cas d'utilisation est discutable, les frontières ne sont pas toujours parfaitement claires. Même à l’intérieur d'un même domaines comme le front, back, standalone, ou l'embarqué, suivant les projets on peut avoir des besoins différents en terme de rapidité d'exécution, rapidité de développement, facilité de maintenance, sécurité, capacité d'abstraction, outils de dev disponibles, ...

Je sais pas d'où vous sortez vos 75% de PHP. Peut-être que si vous comptez les sites WordPress et les pages Facebook, vous arrivez à ce chiffre, mais c'est des cas où il n'y a pas vraiment de développement en PHP à réaliser.
En tout cas, chez nous, et dans la plupart des boites que je connais, plus personne ne développe quoique ce soit de nouveau en PHP depuis plusieurs années déjà, sauf pour bricoler un Wordpress. Le back-end se fait majoritairement en Java, C# ou JavaScript. On commence à avoir quelques expérimentations en Rust.
votre avatar
J'ai donné de bonnes raisons, ainsi que des sources, voir autre message.

Pourquoi vouloir interdire des langages ? mieux vaut laisser l'adoption se faire de façon naturelle, et ici PHP s'est imposé, grâce à ses qualités.

Je suis d'accord avec le fait que l'on ait besoin de langages selon les projets, c'est d'ailleurs la thèse que je défend : utiliser un langage par cas d'utilisation, et pas un langage polyvalent partout qui cherche à tout faire (python, java, etc)

Chez vous, vous faites ce que vous voulez, cela vous regarde si vous voulez produire du code avec plus de lignes de code à maintenir, et avec des technologies qui n'étaient pas adaptées à l'origine (javascript).
votre avatar
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et certaines ne le sont clairement pas), sont de toute façon trop personnelles pour permettre de décréter que certains langages ont le droit de se développer et d'autres ne l'ont pas.

Le site que vous donnez pour source a établi ses statistiques, en gros, à partir d'une détection automatique par domaine exposé au Web(ce qui exclut les intranet), quand c'est techniquement possible (pour beaucoup de backends le langage n'est pas détectable). Bref les CMS sont certainement surreprésentés alors que c'est le type de site sur lequel on programme le moins. Je ne dis pas que les chiffres sont faux, mais que c'est une vision partielle, clairement pas suffisante pour décréter qu'il faut sanctuariser un domaine avec un langage dédié.
Pourquoi vouloir interdire des langages ? mieux vaut laisser l'adoption se faire de façon naturelle, et ici PHP s'est imposé, grâce à ses qualités.
Vous êtes le seul ici qui veuille interdire des langages. Si PHP a eu le droit de prouver son intérêt dans les années 2000 alors que Perl faisait bien le boulot jusque là, pourquoi Rust n'aurait pas le droit de prouver son intérêt aujourd'hui.
Je suis d'accord avec le fait que l'on ait besoin de langages selon les projets, c'est d'ailleurs la thèse que je défend : utiliser un langage par cas d'utilisation, et pas un langage polyvalent partout qui cherche à tout faire (python, java, etc)
Sauf que comme je l'ai dit au dessus, les cas d'utilisation sont très nombreux, d'une importance variable en fonction des projets, et pas toujours parfaitement démarqués. La séparation entre langages front, back et client lourd, correspond peut-être bien à votre approche quotidienne du développement, mais c'est terriblement réducteur. Il peut y avoir plein d'autres critères qui font qu'un langage à de l’intérêt pour un projet.
Chez vous, vous faites ce que vous voulez, cela vous regarde si vous voulez produire du code avec plus de lignes de code à maintenir, et avec des technologies qui n'étaient pas adaptées à l'origine (javascript).
La maintenabilité d'un code ne se mesure absolument pas au nombre de lignes, c'est même souvent le contraire. Faire trop de choses en une ligne cause souvent des mauvaises surprises.
Enfin, Dieu sait que je n'ai pas envie de défendre JavaScript, mais le PHP n'était pas non plus adapté à autre chose que des petits sites persos à l'origine.
votre avatar
J'adore le monde d'aujourd'hui quand même. Pour sécuriser les choses, on en est à passer une couche de rouille. Le monde marche sur la tête :dd:.
votre avatar
J'ai un vieux vélo de ville rouillé qui a 22 ans, pas besoin d'antivol pour le "sécuriser" le temps de faire une course!

CQFD... la rouille repousse les margoulins. :fumer:
votre avatar
Pas certains que si la rouille couvrait entièrement une porte en métal d'un local que ledit local soit très sécurisé et repousse les margoulins :D
votre avatar
Pas certain que cela soit apprécié de la même manière pour une porte (une bonne serrure sur une porte d'apparence pourrie mais solide sera remarquée par qqun d'attentif se cherchant une cible), mais mon vélo est parfaitement fonctionnel, j'avais oublié de le signaler, même si j'ai laissé son aspect se dégrader: Transmission, roulements, freinage, pneus sont changés quand il y a besoin.
votre avatar
bah, le vélo rouillé, s'il tombe en lambeaux c'est pas pratique pour s'en servir
la porte rouillée, si elle tombe en lambeaux, c'est très pratique pour récupérer ce qu'il y a derrière sans la clef ...
votre avatar
L'aspect n'est pas forcément lié à la solidité: La Zoé nickel d'un voisin, mon chat monte sur le toit cela plie sous ses 5kg tellement ils ont rogné l'épaisseur pour compenser le surpoids de la batterie. Heureusement sans dépasser la limite élastique mais la première fois qu'on voit cela ça surprends.
La Ford Taunus des années 70 (qui fait pourtant 400kg de moins que le mixer "moderne") garée devant la maison juste a côté, elle a de la corrosion (même si globalement en bon état pour son âge) mais il peut sauter dessus le matou, ça bouge pas.
votre avatar
"Après plus de vingt ans de lutte contre les problèmes de sécurité de la mémoire en C et C++, la communauté des ingénieurs logiciels est parvenue à un consensus."
Ah bon, j'étais pas au courant, elles sont où les stats ou les sources ? Ah non on me dit que c'est juste une phrase toute faite à la "De tout temps..." Je sais que c'est des relations publiques mais c'est impressionant de voir ce genre de phrase émanant d'un scientifique.

Contrairement à ce que l'article mentionne, il n'est pas fait mention de convertir du C++ vers Rust dans les communiqués et documents mentionnés.

L'objectif du projet, c'est donc de convertir le vieux "legacy" code C, probablement des années 70/80/90 jamais restructuré ou réimplementé. Ils auraient pu investir plus tôt pour ça mais ne l'ont pas fait parce que ça coûte cher et "si ça marche...", dette technique au plafond. Pour le projet, le C++ moderne est une alternative possible, mais vu que l'auteur le met, à tort, dans le même panier.
Buffer overflow vulnerabilities and other related “memory safety” software flaws allow an attacker to inject messages that hijack control of a computer. These vulnerabilities are only possible because programs written in C and C++ don’t force their developers to check conditions, such as array bounds or pointer arithmetic, for correctness
Effectivement "les programmes écrits en C et C++" ne peuvent pas agir sur leurs développeurs... c'est le compilateur qui peut s'en charger, et il peut le faire simplement pour cette classe d'erreurs. Si au moins il parlait de multithreading...

Bref un projet de recherche (trop putaclic à mon goût) surfant sur la vague LLM et sécurité, objectif sympathique vu la quantité de legacy code dans la nature, mais rien de spécial sous le soleil.
votre avatar
Alors oui le projet vise le C legacy, entre autre pour permettre d'utiliser des fonctionnalités plus modernes et faciliter la maintenance. Sur ce point C++ aurait en effet pu être une alternative valable.

Par contre, si on souhaite améliorer la sécurité de l'application lors de ses évolutions à l'avenir, et particulièrement la sécurité mémoire, le Rust est clairement un choix bien plus avisé que le C++. Le C++ moderne a beau fournir des nouveaux mécanismes de gestion mémoire, ils sont, comme en C, conditionnés à une bonne utilisation, là ou en Rust (hors code unsafe) il y a des mécanismes qui garantissent l'absence d'erreur mémoire et de data race.

La DARPA veut traduire automatiquement le code C en Rust

  • Une question de sécurité

  • TRACTOR ne sera pas toujours utilisable

  • TRACTOR pourrait être largement utilisé

Fermer