Je pense qu'on peut regretter le fait historique que Linux, en tant que projet communautaire de noyau libre, est parti sur un noyau monolithique plutôt qu'un micro-noyau—aujourd'hui le noyau est presque impossible à sécuriser (je parle de sortir du jeu du chat et de la souris des attaques/réponses en rendant toute les classes d'attaques courantes impossibles grâce à la conception du système)
Deux choses. Encore une fois, tu oublies significativement le contexte ou tu le rends négligeable. Pourtant ils sont fondamentaux.
Linux était un projet jouet pour Torvalds, pour apprendre l'x86. Le monolithique était juste le moyen le plus simple pour aboutir à un résultat rapidement. Ce sont ensuite les autres qui ont porté Linux au delà du projet jouet, car Linux était à ce moment là, le seul noyau libre convenable. *BSD avait l'épée de Damoclès du procès (et est de toute façon monolithique aussi), Minix n'était pas libre et Hurd on l'attend toujours.
Torvalds n'aurait jamais lancé un tel projet si un micro-noyau libre existait et fonctionnait, Linux n'aurait jamais été un micro-noyau car ce n'était pas l'objectif de Torvalds avec le contexte de l'époque.
Et l'avenir lui a donné raison, il n'existe aucun micro-noyau pur avec une utilisation très large. Windows et macOS (qui ne sont pas codés par des ignorants non plus) n'ont jamais franchi le pas de tout mettre en espace utilisateur faute de performances acceptables.
Et on peut largement sécuriser encore le noyau Linux sans aller dans le micro-noyau fondamentalement. Mais là encore, la sécurité absolue au niveau noyau, c'est contre les performances aussi. Il faut faire des compromis. Et le compromis, ce n'est pas un micro-noyau pur.
Mais il y a une différence importante, c'est que (1) à l'époque les micronoyaux étaient difficiles à rendre efficace (L4 a fait beaucoup de progrès depuis), et (2) tu parles d'un choix de design fondamental qui demande de complètement tout refaire.
Tu as pourtant reproché des choses à Go qui demanderaient de changer l'architecture de Go. et qui est difficile à faire aujourd'hui car ce n'est pas cohérent avec l'architecture choisie. Que c'est trop tard.
Il ne s'agit pas de demander de tout changer au langage, ou de le transformer en une variante de Coq. C'est une fonctionnalité qui n'est pas copmliquée à expliquer ou implémenter, qui se mélange bien avec la plupart des autres traits du langage, et qui lui donne une meilleure capacité à modéliser les domaines métiers—et donc d'écrire du code plus clair. On n'est pas du tout au niveau du "il faut tout refaire avec un micro-noyau".
Mais pourtant on te l'a expliqué que les développeurs de Go, sur cet aspect, connaissait ce que tu énonçais mais l'ont ignoré pour certaines raisons. Tu peux dire ce que tu veux, mais ils ont fait un choix, un compromis et c'est nécessaire d'en faire sur certains sujets. Honnêtement, je ne suis toujours pas convaincu que c'est un manque aussi important que tu l'énonces.
Tu parles de récrire des millions de lignes de code, mais au moment où Go a été conçu, il n'y avait aucune ligne déjà écrite dans ce langage (ou alors juste des exemples exploratoires).
Tu oublies le code passé et la formation des gens. Il y a bien plus de gens, surtout dans le milieu où Go évolue, où le C (voire C++ et Python) est la référence qu'OCaml ou Rust. Go était destiné quand même à ces gens là, une évolution en douceur. Cela ne me paraît pas débile de garder un langage simple et assez proche d'un autre langage pour attirer les développeurs sans leur faire peur.
De la même façon que développeurs COBOL n'est pas parti sur OCaml non plus pour refaire les systèmes bancaires alors que les avantages du langage sont évidents. Mais voilà, pareil, les gens efficaces en Java tu en as suffisamment et les développeurs de COBOL trouvent sans doute la transition plus douce aussi.
C'est un ensemble de choix fait par des gens, et l'un des choix qui se propose c'est de réfléchir à l'apport de la théorie, d'écouter ce qu'elle a à dire et d'entrer en contact avec des gens qui en font
Tu es toujours dans l'histoire du théorie -> pratique, mais au vue de tes déclarations où tu sembles (volontairement ou non) ignorer ce qu'est la vraie vie d'un projet informatique en entreprise, du savoir des développeurs. Je dirais que l'inverse devrait aussi se faire, que les théoriciens ne s'offusquent pas car ils n'ont pas été entendus par eux. Peut être qu'ils l'ont été mais qu'ils ont arbitré différemment avec leur justification (ce que Go notamment a explicité sur certains choix). Je trouve facile de toujours réclamer à être entendu mais de ne pas faire l'effort soi même dans l'autre sens.
[^] # Re: go 2.0
Posté par Renault (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Deux choses. Encore une fois, tu oublies significativement le contexte ou tu le rends négligeable. Pourtant ils sont fondamentaux.
Linux était un projet jouet pour Torvalds, pour apprendre l'x86. Le monolithique était juste le moyen le plus simple pour aboutir à un résultat rapidement. Ce sont ensuite les autres qui ont porté Linux au delà du projet jouet, car Linux était à ce moment là, le seul noyau libre convenable. *BSD avait l'épée de Damoclès du procès (et est de toute façon monolithique aussi), Minix n'était pas libre et Hurd on l'attend toujours.
Torvalds n'aurait jamais lancé un tel projet si un micro-noyau libre existait et fonctionnait, Linux n'aurait jamais été un micro-noyau car ce n'était pas l'objectif de Torvalds avec le contexte de l'époque.
Et l'avenir lui a donné raison, il n'existe aucun micro-noyau pur avec une utilisation très large. Windows et macOS (qui ne sont pas codés par des ignorants non plus) n'ont jamais franchi le pas de tout mettre en espace utilisateur faute de performances acceptables.
Et on peut largement sécuriser encore le noyau Linux sans aller dans le micro-noyau fondamentalement. Mais là encore, la sécurité absolue au niveau noyau, c'est contre les performances aussi. Il faut faire des compromis. Et le compromis, ce n'est pas un micro-noyau pur.
Tu as pourtant reproché des choses à Go qui demanderaient de changer l'architecture de Go. et qui est difficile à faire aujourd'hui car ce n'est pas cohérent avec l'architecture choisie. Que c'est trop tard.
Mais pourtant on te l'a expliqué que les développeurs de Go, sur cet aspect, connaissait ce que tu énonçais mais l'ont ignoré pour certaines raisons. Tu peux dire ce que tu veux, mais ils ont fait un choix, un compromis et c'est nécessaire d'en faire sur certains sujets. Honnêtement, je ne suis toujours pas convaincu que c'est un manque aussi important que tu l'énonces.
Tu oublies le code passé et la formation des gens. Il y a bien plus de gens, surtout dans le milieu où Go évolue, où le C (voire C++ et Python) est la référence qu'OCaml ou Rust. Go était destiné quand même à ces gens là, une évolution en douceur. Cela ne me paraît pas débile de garder un langage simple et assez proche d'un autre langage pour attirer les développeurs sans leur faire peur.
De la même façon que développeurs COBOL n'est pas parti sur OCaml non plus pour refaire les systèmes bancaires alors que les avantages du langage sont évidents. Mais voilà, pareil, les gens efficaces en Java tu en as suffisamment et les développeurs de COBOL trouvent sans doute la transition plus douce aussi.
Tu es toujours dans l'histoire du théorie -> pratique, mais au vue de tes déclarations où tu sembles (volontairement ou non) ignorer ce qu'est la vraie vie d'un projet informatique en entreprise, du savoir des développeurs. Je dirais que l'inverse devrait aussi se faire, que les théoriciens ne s'offusquent pas car ils n'ont pas été entendus par eux. Peut être qu'ils l'ont été mais qu'ils ont arbitré différemment avec leur justification (ce que Go notamment a explicité sur certains choix). Je trouve facile de toujours réclamer à être entendu mais de ne pas faire l'effort soi même dans l'autre sens.