Pas le seul surpris, donc! J'espère que cela ne cache pas le début d'une évolution fâcheuse (client lourd-> web app?).
Mais il semble que JS sorte de plus en plus de son cadre de langage dédié au web dynamique côté client (pendant de PHP côté serveur), poussé par la masse de développeurs web? L'autre exemple en tête qui m'attriste c'est pour le protocole domotique ZWave (l'unique mainteneur de la librairie C++ Open-Zwave ayant claqué la porte depuis bientôt 2 ans) et zwavejs ou la situation est pire (faute de devoir déjà intégrer l'interpréteur, comme Thunderbird, donc pb de dépendances complexes ajoutées réglées malpropre à coup de docker vs la simplicité d'une lib compilée dans l'applicatif qui l'utilise).
Surtout que si je suis assez peu confiant dans la capacité de Rust à remplacer le C dans le codage d'OS/modules/boot-loader, pour de l'applicatif réseau en frontal sur internet et en évolution rapide/constante il semble plus justifié de:
-Se lancer dans un langage nouveau/offrant moins de liberté... et objet, qui a toujours posé le pb de la fine maîtrise de la gestion mémoire/allocations,
-Accepter une petite baisse de perf contre la sécurité intrinsèque,
-Ne pas devoir se reposer sur des outils d'analyse de code, coûteux en ressources, si on veut les perf maximales du C ET la sécurité (ce qui se justifie plus pour du code qui va moins changer dans le temps, ce qui est à mon sens la raison pour laquelle Rust ne percera pas là ou les performances sont le critère premier, car elles ont un coût matériel ajouté évitable donc in-fine évité par l'industrie).
[^] # Re: Pour des raisons de sécurité
Posté par lym . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 2. Dernière modification le 03 novembre 2022 à 14:56.
Surtout en considérant d’où vient Rust :o)
Pas le seul surpris, donc! J'espère que cela ne cache pas le début d'une évolution fâcheuse (client lourd-> web app?).
Mais il semble que JS sorte de plus en plus de son cadre de langage dédié au web dynamique côté client (pendant de PHP côté serveur), poussé par la masse de développeurs web? L'autre exemple en tête qui m'attriste c'est pour le protocole domotique ZWave (l'unique mainteneur de la librairie C++ Open-Zwave ayant claqué la porte depuis bientôt 2 ans) et zwavejs ou la situation est pire (faute de devoir déjà intégrer l'interpréteur, comme Thunderbird, donc pb de dépendances complexes ajoutées réglées malpropre à coup de docker vs la simplicité d'une lib compilée dans l'applicatif qui l'utilise).
Surtout que si je suis assez peu confiant dans la capacité de Rust à remplacer le C dans le codage d'OS/modules/boot-loader, pour de l'applicatif réseau en frontal sur internet et en évolution rapide/constante il semble plus justifié de:
-Se lancer dans un langage nouveau/offrant moins de liberté... et objet, qui a toujours posé le pb de la fine maîtrise de la gestion mémoire/allocations,
-Accepter une petite baisse de perf contre la sécurité intrinsèque,
-Ne pas devoir se reposer sur des outils d'analyse de code, coûteux en ressources, si on veut les perf maximales du C ET la sécurité (ce qui se justifie plus pour du code qui va moins changer dans le temps, ce qui est à mon sens la raison pour laquelle Rust ne percera pas là ou les performances sont le critère premier, car elles ont un coût matériel ajouté évitable donc in-fine évité par l'industrie).
Mais la stratégie de Mozilla est parfois étrange.