rustacean.net 
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.
Dans un communiqué publié le 31 juillet, la DARPA (Defense Advanced Research Projects Agency) a annoncé travailler sur le projet TRACTOR. Signifiant « TRanslating All C TO Rust », le nom annonce la couleur : traduire tout le code C en Rust. L’agence militaire, opérant pour le ministère américain de la Défense, utilise de grands modèles de langage pour affiner cette tâche.
Une question de sécurité
Comme nous l’avons vu plusieurs fois, le langage Rust intéresse de près de nombreuses entreprises et administrations. Créé par Mozilla, Rust est devenu un projet indépendant, piloté par une fondation dédiée. Le langage a largement gagné en attraction ces dernières années. Il est régulièrement classé premier chez Stack Overflow. En mai dernier, GitHub lui avait consacré un billet intitulé « Pourquoi Rust est le langage le plus admiré par les développeurs ».
La DARPA va plus loin et évoque la perspective d’éliminer « une fois pour toutes les vulnérabilités liées à la sécurité de la mémoire ». Elle travaille donc sur un convertisseur automatique capable, en théorie, de traduire n’importe quel code écrit en C. Ces deux langages nécessitent de gérer manuellement les pointeurs, utilisés pour indiquer à un programme où stocker des données en mémoire.
« 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. S'appuyer sur des outils de recherche de bogues n'est pas suffisant. Même l'Office of the National Cyber Director a appelé à des approches plus proactives pour éliminer les vulnérabilités liées à la sécurité de la mémoire afin de réduire les attaques », indique la DARPA.
Le Rust, langage « memory safe », permet d’éliminer de nombreuses catégories de failles potentielles liées à la mémoire, dont les fameux dépassements de mémoire tampon. « Vous pouvez aller sur n'importe quel site web du LLM, commencer à chatter avec l'un des chatbots d'IA, et tout ce que vous avez à dire est "voici du code C, veuillez le traduire en code Rust idiomatique sûr", couper, coller, et quelque chose sort, et c'est souvent très bon, mais pas toujours », a précisé Dan Wallach, directeur du projet à la DARPA.
TRACTOR ne sera pas toujours utilisable
Si le projet de la DARPA attire l’attention, on sait déjà qu’il ne pourra pas être appliqué systématiquement. En outre, puisque l’outil est basé sur un LLM, des risques subsistent.
« Par exemple, les LLM peuvent donner des réponses étonnamment bonnes lorsque vous leur demandez de traduire du code, mais ils peuvent aussi halluciner des réponses incorrectes. Un autre défi est que le C permet au code de faire des choses avec des pointeurs, y compris de l'arithmétique, ce que Rust interdit. Pour combler ce fossé, il ne suffit pas de traduire du C vers Rust », a expliqué Dan Wallach à The Register.
Le directeur de projet ajoute que tous les travaux sur des bases de code source ouvert ou encore toute la base industrielle de la Défense pourraient directement profiter de TRACTOR. Cependant, d’autres développements « comme le noyau Linux sont explicitement hors du champ d'application ». Ils ont des « problèmes techniques pour lesquels Rust ne conviendrait pas ». On se souvient d’ailleurs que dans les déclarations de Microsoft pour Windows, il n’était jamais question de réécrire intégralement le code en Rust, mais de l’utiliser quand c’était adapté et possible. Même chose chez Linus Torvalds pour le noyau Linux.
TRACTOR pourrait être largement utilisé
Bien que l’on ne sache pas encore tout à fait comment la DARPA compte proposer son convertisseur automatique, TRACTOR pourrait bien être largement utilisé.
« La grande quantité de code C exécuté dans l'infrastructure Internet actuelle rend l'utilisation d'outils de traduction attrayante », a ainsi déclaré à The Register Josh Aas, directeur du projet Prossimo. Ce dernier vise à proposer des versions Rust de certains composants critiques de l’architecture d’Internet aujourd’hui. Sur le site, on peut voir des travaux sur TLS, le noyau Linux (écriture de pilotes en Rust), un résolveur DNS, AV1, zlib ou encore sudo et curl.
« Je pense que [TRACTOR] est très solide en termes de viabilité et qu'il aura un impact considérable dans le domaine de la cybersécurité, où la sécurité de la mémoire fait déjà l'objet d'un grand débat », a déclaré de son côté Peter Morales, CEO de Code Metal, spécialisée dans la conversion de code pour le matériel de pointe.
En attendant que le projet avance et que le convertisseur devienne disponible, la DARPA organisera le 26 août un évènement de présentation. Les personnes intéressées doivent s’inscrire avant le 19 août.
![[Édito] Apple entre greenwashing et renouvellement à marche forcée](https://next.ink/wp-content/uploads/2024/09/Apple_greenwashing-510x247.webp "[Édito] Apple entre greenwashing et renouvellement à marche forcée")
Commentaires (55)
#1
#1.1
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.
#1.2
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.
#1.3
#1.4
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.
Historique des modifications :
Posté le 05/08/2024 à 15h45
Le 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.
#1.5
Ou quelqu'un qui travaille chez Crowdstrike...
Ok je sors
#1.6
#1.7
#1.8
Ç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é.
Historique des modifications :
Posté le 06/08/2024 à 08h26
É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 minime.
#1.9
Bon courage, ça va être un boulot passionnant.
#1.10
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.
#1.11
#2
Historique des modifications :
Posté le 05/08/2024 à 12h57
S'il n'est donc pas question de traduire les noyaux Linux ou Windows en Rust avec cet outils, peut-être que ça pourrait aider à traduire Wayland, lors de l'adaptation de celui-ci pour Redox) et son micro-noyau en Rust.
Posté le 05/08/2024 à 12h59
S'il n'est donc pas question de traduire les noyaux Linux ou Windows en Rust avec cet outils, peut-être que ça pourrait aider à traduire Wayland, lors de l'adaptation de celui-ci pour Redox et son micro-noyau en Rust.
#2.1
#2.2
Quoiqu'il en reste peut-être des traces en open sources, selon https://en.wikipedia.org/wiki/ChorusOS
#3
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.
#3.1
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.
#3.11
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é.
Historique des modifications :
Posté le 07/08/2024 à 09h17
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é.
Penser que la sécurité de Rust qui pousserait à ne pas faire attention au code, ça revient (en très gros) à dire que la ceinture de sécurité pousse à être imprudent sur la route. Dans la pratique boucler sa ceinture est au contraire un rappel quotidien de l'importance de la sécurité.
Posté le 07/08/2024 à 09h18
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é.
Penser que la sécurité de Rust qui 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 boucler sa ceinture est au contraire un rappel quotidien de l'importance de la sécurité.
Posté le 07/08/2024 à 09h20
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 au contraire un rappel quotidien de l'importance de la sécurité.
#3.2
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++.
#3.3
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.
#3.5
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.
#3.7
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.
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 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.
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.
Autant la multiplication a l'infini des outils pose soucis. L'universalisme dans les langages, c'est pas une bonne idée non plus.
Historique des modifications :
Posté le 05/08/2024 à 18h44
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.
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 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.
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
Autant la multiplication a l'infini des outils pose soucis. L'universalisme dans les langages, c'est pas une bonne idée non plus.
Posté le 05/08/2024 à 18h45
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.
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 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.
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
Autant la multiplication a l'infini des outils pose soucis. L'universalisme dans les langages, c'est pas une bonne idée non plus.
#3.4
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.
Historique des modifications :
Posté le 05/08/2024 à 14h46
Le narratif autour de Rust c'est de dire que le langage aide à prévenir certains types d'erreur, et c'est globalement vrai. Pas grand monde ne dit que c'est magique et que ça évite de réfléchir à tout ce que l'on fait.
Et au contraire, Rust s'étant construit avec une préoccupation de la sécurité dès son origine, ces problématiques sont 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ù il y a un vrai soucis vis a vis de la compréhension de la sécurité, c'est plus au niveau de la promotion du C++ ou en entent très souvent dire que l'utilisation du C++ moderne résout 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é. Il s'agit d'un fonctionnement inattendu de l'API (en C) de Windows, que la bibliothèque standard de Rust a rendu inopérant quand il a été découvert. Le problème existe toujours en C et C++ qui font directement appel à l'API Windows, ça n'a pas fait l'objet de CVE car on concidère que c'est l'utilisateur de l'API qui est censé s'assurer lui même des règles d'échappement. Dans la pratique c'est terriblement complexe a 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 la procédure pour bien utiliser la fonction CreateProccess vis a vis de ce risque d'exploitation n'est documenté en complet que par le blog du découvreur du problème. Microsoft n'a même pas jugé nécessaire de le mentionner dans la 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.
Posté le 05/08/2024 à 14h59
Le narratif autour de Rust c'est de dire que le langage aide à prévenir les erreurs mémoire, ce qui est globalement vrai. Pas grand monde ne dit que c'est magique et que ça évite de réfléchir à tout ce que l'on fait.
Et au contraire, Rust s'étant construit avec une préoccupation de la sécurité dès son origine, ces problématiques sont 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ù il y a un vrai soucis vis a vis de la compréhension de la sécurité, c'est plus au niveau de la promotion du C++ où j'ai très souvent entendu dire que l'utilisation des fonctionnalités post C11 du C++ moderne 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é. Il s'agit d'un fonctionnement inattendu de l'API (en C) de Windows, que la bibliothèque standard de Rust a rendu inopérant quand il a été découvert. Le problème existe toujours en C et C++ qui font directement appel à l'API Windows, ça n'a pas fait l'objet de CVE car on concidère que c'est l'utilisateur de l'API qui est censé s'assurer lui même des règles d'échappement. Dans la pratique c'est terriblement complexe a 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 la procédure pour bien utiliser la fonction CreateProccess vis a vis de ce risque d'exploitation n'est documenté en complet que par le blog du découvreur du problème. Microsoft n'a même pas jugé nécessaire de le mentionner dans la 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.
Posté le 05/08/2024 à 15h04
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 par des gens plutôt 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é. Il s'agit d'un fonctionnement inattendu de l'API (en C) de Windows, que la bibliothèque standard de Rust a rendu inopérant quand il 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 des règles d'é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 CreateProccess vis a 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 la 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.
Posté le 05/08/2024 à 15h12
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 par des gens plutôt 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é. Il s'agit d'un fonctionnement inattendu de l'API (en C) de Windows, que la bibliothèque standard de Rust a rendu inopérant quand il 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 des règles d'é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 CreateProccess vis a 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 la 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.
Posté le 05/08/2024 à 15h29
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é. Il s'agit d'un fonctionnement inattendu de l'API (en C) de Windows, que la bibliothèque standard de Rust a rendu inopérant quand il 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 des règles d'é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 CreateProccess vis a 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 la 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.
Posté le 05/08/2024 à 15h34
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é. Il s'agit d'un fonctionnement inattendu de la fonction CreateProcess de l'API (en C) de Windows, que la bibliothèque standard de Rust a rendu inopérant quand il 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 des règles d'é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 a 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 la 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.
#3.8
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.
#3.10
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++.
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.
Historique des modifications :
Posté le 07/08/2024 à 08h52
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.
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.
La clé du discours c'est 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++.
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.
Posté le 07/08/2024 à 09h36
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++.
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.
Posté le 07/08/2024 à 09h36
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++.
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.
#3.6
#3.9
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.
#4
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é.
#4.1
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.
#5
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.
#6
#6.1
#6.2
#6.3
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.
Historique des modifications :
Posté le 07/08/2024 à 09h30
C'est très similaire. Ça reviens à dire que d'une augmentation de sécurité découle une baise de la prudence. La pratique montre que ça n'est généralement pas le cas. 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.
Posté le 07/08/2024 à 09h31
Je suis pas sur d'avoir bien compris ta phrase, mais c'est très similaire.
Ça reviens à dire que d'une augmentation de sécurité découle une baise de la prudence. La pratique montre que ça n'est généralement pas le cas. 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.
Posté le 07/08/2024 à 09h46
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 baise de la vigilance. La pratique montre que ça n'est généralement pas le cas. 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.
#6.4
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.
#6.5
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.
#6.6
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.
#6.7
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.
#6.9
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.
#6.11
Source ?
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 ?)
#6.12
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.
Historique des modifications :
Posté le 11/08/2024 à 15h54
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)
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.
Posté le 11/08/2024 à 15h56
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.
Posté le 11/08/2024 à 16h04
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 sondages, 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.
#6.13
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.
Complètement faux. Aucun de ces langages ne nécessite un accès root.
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.
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.
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é).
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).
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).
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 ;)
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.
Historique des modifications :
Posté le 11/08/2024 à 16h56
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.
Complètement faux. Aucun de ces langages ne nécessite un accès root.
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.
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.
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é).
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).
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).
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é.
#6.8
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.
Historique des modifications :
Posté le 10/08/2024 à 01h20
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. Mais le but de l'outil que souhaite développer la DARPA vise justement a réduire ce coût.
JS c'est principalement construit sur le fait qu'il n'y avait pas d'alternative native sur navigateur côté client, ceci dit, avec le développement de WebAssembly, ça pourrait changer à l'avenir. Il a aussi percé sur serveur, en 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, et 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.
#6.10
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.
#6.14
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.
Historique des modifications :
Posté le 11/08/2024 à 18h42
Sauf que là tu décrètes les langages à conserver selon les critères qui te plaisent, au moment ou ça t'arrange.
Si on avait interdit les langages qui ont déjà un concurrent qui répond a un même cas d'utilisation, le PHP n'existerait pas, le Perl faisait le boulot longtemps avant que le PHP ne devienne vaguement utilisable pour autre chose qu'un site perso. Le C++ n'existerait pas non plus, vu que qu'au final il ne couvre pas de domaine supplémentaire que le C.
Et même la notion de cas d'utilisation est discutable, les frontière n'étant pas toujours parfaitement claires. Que ce soit en front, back, standalone, on peut avoir des besoins différent 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ù tu sort ton 75%, peut être que si tu compte sites Wordpress et les pages Facebook, tu peux arriver à ce chiffre, mais c'est des cas ou il n'y a pas vraiment de développement en PHP.
En tout cas, chez nous, et dans la plupart des boite que je connais, plus personne ne développe quoique ce soit de nouveau en PHP depuis quelques années, sauf pour bricoler un Wordpress. Tout le back-end se fait en Java, C# ou JavaScript. On commence a avoir quelques expérimentations en Rust.
Posté le 11/08/2024 à 18h49
Sauf que là tu décrètes les langages à conserver selon les critères qui te plaisent, au moment ou ça t'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 n'étant pas toujours parfaitement claires. Que ce soit en front, back, standalone, on peut avoir des besoins différent 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ù tu sort ton 75% de PHP. Peut-être que si tu compte les sites WordPress et les pages Facebook, tu peux arriver à ce chiffre, mais c'est des cas ou il n'y a pas vraiment de développement en PHP à réaliser.
En tout cas, chez nous, et dans la plupart des boite 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 a avoir quelques expérimentations en Rust.
Posté le 12/08/2024 à 07h35
Sauf que là tu décrètes les langages à conserver selon les critères qui te plaisent, au moment ou ça t'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 n'étant pas toujours parfaitement claires. Que ce soit en front, back, standalone, 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ù tu sort ton 75% de PHP. Peut-être que si tu comptes les sites WordPress et les pages Facebook, tu peux arriver à ce chiffre, mais c'est des cas ou 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.
Posté le 12/08/2024 à 07h40
Sauf que là tu décrètes les langages à conserver selon les critères qui te plaisent, au moment ou ça t'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ù tu sort ton 75% de PHP. Peut-être que si tu comptes les sites WordPress et les pages Facebook, tu peux arriver à ce chiffre, mais c'est des cas ou 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.
#6.15
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).
#6.16
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é.
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.
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.
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.
Historique des modifications :
Posté le 13/08/2024 à 09h03
D'après ta source, le décompte se base sur une détection automatique, sur les site exposés au Web, et où c'est techniquement possible, et décompte principalement par nom de domaine. Bref les CMS sont surreprésentés alors de c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffre sont faux ou n'ont pas d’intérêt, mais que ce n'est qu'une vision du problème clairement pas suffisante pour décréter qu'il faut sanctifier un langage, sinon PHP lui même n'aurait pas existé.
Jusqu'à preuve du contraire 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, pourquoi Rust n'aurait pas le droit de prouver son interêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisations sont très nombreux, pas toujours aussi important en fonction du projet et pas toujours parfaitement démarqués. Une séparation entre langages front, back et client lourd, 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.
La maintenabilité d'un code ne se mesure absolument pas au nombre de lignes, c'est même souvent le contraire. Faire trop de chose en une ligne cause souvent des mauvaises surprise.
Dieu sait que je n'ai pas envie de défendre JavaScript, mais le PHP non plus n'était pas non plus adapté a autre chose que des petits site perso a l'origine.
Posté le 13/08/2024 à 09h04
Le problème c'est que tes raisons sont quand même beaucoup trop personnelles pour te permettre de décréter quel langages ont le droit d'exister ou non.
D'après ta source, le décompte se base sur une détection automatique, sur les site exposés au Web, et où c'est techniquement possible, et décompte principalement par nom de domaine. Bref les CMS sont surreprésentés alors de c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffre sont faux ou n'ont pas d’intérêt, mais que ce n'est qu'une vision du problème clairement pas suffisante pour décréter qu'il faut sanctifier un langage, sinon PHP lui même n'aurait pas existé.
Jusqu'à preuve du contraire 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, pourquoi Rust n'aurait pas le droit de prouver son interêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisations sont très nombreux, pas toujours aussi important en fonction du projet et pas toujours parfaitement démarqués. Une séparation entre langages front, back et client lourd, 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.
La maintenabilité d'un code ne se mesure absolument pas au nombre de lignes, c'est même souvent le contraire. Faire trop de chose en une ligne cause souvent des mauvaises surprise.
Dieu sait que je n'ai pas envie de défendre JavaScript, mais le PHP non plus n'était pas non plus adapté a autre chose que des petits site perso a l'origine.
Posté le 13/08/2024 à 09h05
Le problème c'est que tes raisons sont quand même beaucoup trop personnelles pour te permettre de décréter que des langages ont le droit de se développer ou non.
D'après ta source, le décompte se base sur une détection automatique, sur les site exposés au Web, et où c'est techniquement possible, et décompte principalement par nom de domaine. Bref les CMS sont surreprésentés alors de c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffre sont faux ou n'ont pas d’intérêt, mais que ce n'est qu'une vision du problème clairement pas suffisante pour décréter qu'il faut sanctifier un langage, sinon PHP lui même n'aurait pas existé.
Jusqu'à preuve du contraire 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, pourquoi Rust n'aurait pas le droit de prouver son interêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisations sont très nombreux, pas toujours aussi important en fonction du projet et pas toujours parfaitement démarqués. Une séparation entre langages front, back et client lourd, 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.
La maintenabilité d'un code ne se mesure absolument pas au nombre de lignes, c'est même souvent le contraire. Faire trop de chose en une ligne cause souvent des mauvaises surprise.
Dieu sait que je n'ai pas envie de défendre JavaScript, mais le PHP non plus n'était pas non plus adapté a autre chose que des petits site perso a l'origine.
Posté le 13/08/2024 à 09h06
Le problème c'est que tes raisons qu'elles soient bonnes ou non (et la plupart ne le sont pas) sont quand même beaucoup trop personnelles pour te permettre de décréter que des langages ont le droit de se développer ou non.
D'après ta source, le décompte se base sur une détection automatique, sur les site exposés au Web, et où c'est techniquement possible, et décompte principalement par nom de domaine. Bref les CMS sont surreprésentés alors de c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffre sont faux ou n'ont pas d’intérêt, mais que ce n'est qu'une vision du problème clairement pas suffisante pour décréter qu'il faut sanctifier un langage, sinon PHP lui même n'aurait pas existé.
Jusqu'à preuve du contraire 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, pourquoi Rust n'aurait pas le droit de prouver son interêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisations sont très nombreux, pas toujours aussi important en fonction du projet et pas toujours parfaitement démarqués. Une séparation entre langages front, back et client lourd, 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.
La maintenabilité d'un code ne se mesure absolument pas au nombre de lignes, c'est même souvent le contraire. Faire trop de chose en une ligne cause souvent des mauvaises surprise.
Dieu sait que je n'ai pas envie de défendre JavaScript, mais le PHP non plus n'était pas non plus adapté a autre chose que des petits site perso a l'origine.
Posté le 13/08/2024 à 09h07
Le problème c'est que tes raisons qu'elles soient bonnes ou non (et la beaucoup ne le sont pas) sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
D'après ta source, le décompte se base sur une détection automatique, sur les site exposés au Web, et où c'est techniquement possible, et décompte principalement par nom de domaine. Bref les CMS sont surreprésentés alors de c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffre sont faux ou n'ont pas d’intérêt, mais que ce n'est qu'une vision du problème clairement pas suffisante pour décréter qu'il faut sanctifier un langage, sinon PHP lui même n'aurait pas existé.
Jusqu'à preuve du contraire 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, pourquoi Rust n'aurait pas le droit de prouver son interêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisations sont très nombreux, pas toujours aussi important en fonction du projet et pas toujours parfaitement démarqués. Une séparation entre langages front, back et client lourd, 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.
La maintenabilité d'un code ne se mesure absolument pas au nombre de lignes, c'est même souvent le contraire. Faire trop de chose en une ligne cause souvent des mauvaises surprise.
Dieu sait que je n'ai pas envie de défendre JavaScript, mais le PHP non plus n'était pas non plus adapté a autre chose que des petits site perso a l'origine.
Posté le 13/08/2024 à 09h16
Le problème c'est que tes raisons qu'elles soient bonnes ou non (et la beaucoup ne le sont pas) sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
D'après votre source, les statistique sont faites, en gros, à partir d'une détection automatique par domaine exposé au Web, quand c'est techniquement possible. Bref les CMS sont surreprésentés alors que c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffres sont faux ou qu'il n'ont n'ont pas d’intérêt, 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é.
Jusqu'à preuve du contraire 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, pourquoi Rust n'aurait pas le droit de prouver son intérêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisations sont très nombreux, pas toujours aussi importants en fonction des projets et pas toujours parfaitement démarqués. Une séparation entre langages front, back et client lourd, 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.
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 non plus n'était pas non plus adapté a autre chose que des petits site perso a l'origine.
Posté le 13/08/2024 à 09h17
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et beaucoup ne le sont pas), sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
D'après votre source, les statistique sont faites, en gros, à partir d'une détection automatique par domaine exposé au Web, quand c'est techniquement possible. Bref les CMS sont surreprésentés alors que c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffres sont faux ou qu'il n'ont n'ont pas d’intérêt, 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é.
Jusqu'à preuve du contraire 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, pourquoi Rust n'aurait pas le droit de prouver son intérêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisations sont très nombreux, pas toujours aussi importants en fonction des projets et pas toujours parfaitement démarqués. Une séparation entre langages front, back et client lourd, 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.
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 non plus n'était pas non plus adapté a autre chose que des petits site perso a l'origine.
Posté le 13/08/2024 à 09h19
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et beaucoup ne le sont pas), sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
D'après votre source, les statistique sont faites, en gros, à partir d'une détection automatique par domaine exposé au Web, quand c'est techniquement possible. Bref les CMS sont surreprésentés alors que c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffres sont faux ou qu'il n'ont n'ont pas d’intérêt, 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é.
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, pourquoi Rust n'aurait pas le droit de prouver son intérêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisations sont très nombreux, pas toujours aussi importants en fonction des projets et pas toujours parfaitement démarqués. Une séparation entre langages front, back et client lourd, 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.
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.
Posté le 13/08/2024 à 09h21
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et beaucoup ne le sont pas), sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
D'après votre source, les statistique sont faites, en gros, à partir d'une détection automatique par domaine exposé au Web, quand c'est techniquement possible. Bref les CMS sont surreprésentés alors que c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffres sont faux ou qu'il n'ont n'ont pas d’intérêt, 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é.
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, pourquoi Rust n'aurait pas le droit de prouver son intérêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisations sont très nombreux, pas toujours aussi importants en fonction des projets et pas toujours parfaitement démarqués. Une séparation entre langages front, back et client lourd, 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.
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.
Posté le 13/08/2024 à 09h26
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et beaucoup ne le sont pas), sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
D'après votre source, les statistique sont faites, en gros, à partir d'une détection automatique par domaine exposé au Web, quand c'est techniquement possible. Bref les CMS sont surreprésentés alors que c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffres sont faux ou qu'il n'ont n'ont pas d’intérêt, 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é.
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, pourquoi Rust n'aurait pas le droit de prouver son intérêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisation sont très nombreux, pas toujours aussi importants en fonction des projets et pas toujours parfaitement démarqués. Une 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.
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.
Posté le 13/08/2024 à 09h29
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et beaucoup ne le sont pas), sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
Votre source a établi ses statistiques, en gros, à partir d'une détection automatique par domaine exposé au Web, quand c'est techniquement possible (pour beaucoup de backend le langage n'est pas détectable). Bref les CMS sont surreprésentés alors que c'est le type de site sur lequel on programme le moins. Je ne dit la que les chiffres sont faux ou qu'il n'ont n'ont pas d’intérêt, 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é.
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, pourquoi Rust n'aurait pas le droit de prouver son intérêt aujourd'hui.
Sauf que comme je l'ai dis au dessus, les cas d'utilisation sont très nombreux, pas toujours aussi importants en fonction des projets et pas toujours parfaitement démarqués. Une 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.
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.
Posté le 13/08/2024 à 09h33
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et beaucoup ne le sont pas), sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
Votre 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é.
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.
Sauf que comme je l'ai dis au dessus, les cas d'utilisation sont très nombreux, pas toujours aussi importants en fonction des projets et pas toujours parfaitement démarqués. Une 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.
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.
Posté le 13/08/2024 à 09h36
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et certaine ne le sont clairement pas), sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
Votre 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é.
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.
Sauf que comme je l'ai dis au dessus, les cas d'utilisation sont très nombreux, pas toujours aussi importants en fonction des projets et pas toujours parfaitement démarqués. Une 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.
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.
Posté le 13/08/2024 à 09h36
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et certaines ne le sont clairement pas), sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
Votre 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é.
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.
Sauf que comme je l'ai dis au dessus, les cas d'utilisation sont très nombreux, pas toujours aussi importants en fonction des projets et pas toujours parfaitement démarqués. Une 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.
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.
Posté le 13/08/2024 à 09h39
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et certaines ne le sont clairement pas), sont quand même beaucoup trop personnelles pour permettre de décréter que des langages ont le droit de se développer ou non.
Votre 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é.
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.
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.
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.
Posté le 13/08/2024 à 13h11
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et certaines ne le sont clairement pas), sont quand même beaucoup trop personnelles pour décréter que certains langages ont le droit de se développer et d'autres non.
Votre 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é.
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.
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.
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.
Posté le 13/08/2024 à 14h19
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et certaines ne le sont clairement pas), sont quand même beaucoup trop personnelles pour décréter que certains langages ont le droit de se développer et d'autres non.
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é.
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.
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.
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.
Posté le 16/08/2024 à 07h16
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'on 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é.
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.
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.
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.
Posté le 16/08/2024 à 07h17
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'on 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é.
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.
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.
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.
#7
#7.1
CQFD... la rouille repousse les margoulins.
#7.2
#7.3
#7.4
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 ...
#7.5
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.
#8
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.
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.
Historique des modifications :
Posté le 11/08/2024 à 17h30
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.
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.
Posté le 11/08/2024 à 17h30
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.
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.
Posté le 11/08/2024 à 17h31
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.
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.
#8.1
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.
Historique des modifications :
Posté le 13/08/2024 à 09h54
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++ a beau fournir des nouveaux mécanismes de gestion mémoire, ils sont tout autant 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.
Posté le 13/08/2024 à 09h54
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 tout autant conditionnés à une bonne utilisation qu'en C, 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.
Posté le 13/08/2024 à 14h21
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 tout autant conditionnés à une bonne utilisation qu'en C, 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.