Cela étant, au début de Rust il y avait un GC qu'ils ont abandonné
Alors quelques précisions:
- le GC qu'il y avait au début de Rust n'étant pas un vrai GC, mais du comptage de références (parce que le travail n'était pas terminé).
- l'utilisation du GC a toujours pensée comme optionnelle : en gros on déclarait une référence comme étant "garbage collectable" (le langage a bien changé mais c'était dfans mon journal sur Rust 0.7 ).
- même quand le GC était partie intégrante du langage, le but était de s'en servir le moins possible, et par exemple la bibliothèque standard a vite atteint l'objectif de 0 GC.
- avec le temps l'équipe s'est aperçu qu'elle pouvait aller plus loin que ce qu'ils pensaient au début, et que le système de typage permettait de sortir le GC et de le penser comme une dépendance externe, sans besoin d'une syntaxe dédiée.
mais l'idée de remettre de la gestion automatique est toujours présente, cela semble être néanmoins compliqué
La gestion est déjà automatique, via le système de référence que j'ai (mal) expliqué, mais un GC optionnel serait un confort pour certaines partie de code. Ce qui complique la tâche ce sont les prérogatives assez élevées qu'imposent les buts du langage ('You pay for what you use' entre autres), quand Haskell/Ocaml/Java/Python... n'ont pas à se soucier de tels problèmes (mais ils en ont d'autres évidemment).
Sinon quelle différence fais-tu entre un langage qui peut faire de la programmation système et un langage système ?
La différence peut être mince, comme tu le soulignes avec les unikernels, mais je dirais qu'un langage système permet de maîtriser suffisamment parfaitement le comportement du code pour pouvoir écrire du code temps-réel (au sens temps réel dur, pas au sens globalement performant).
c'est pas si mal et bien mieux que le 25.82 s du meilleur code OCaml du test. D'autant que, n'étant pas moi même programmeur (je suis mathématicien et logicien, pas informaticien), il est fort probable qu'un spécialiste du langage puisse encore améliorer cela.
C'est très gentil de t'être donné la peine d'écrire un commentaire aussi argumenté, mais tu prêches un convaincu :) . Je sais très bien que Haskell ou OCaml ont de très bonnes performances dans la majorité des cas. Mais justement le lien que j'ai donné explique bien que Haskell va donner de très bon débit, mais va avoir des problèmes de latences ; ton benchmarck au final est équivalent à tester un débit moyen, mais ne va pas du tout tester les problèmes de latences, parce que 1) c'est pénible à tester 2) ce n'est pas ton problème.
[^] # Re: On s'en bat le steak
Posté par GuieA_7 (site web personnel) . En réponse au journal Typage statique pour Python. Évalué à 3.
Alors quelques précisions:
- le GC qu'il y avait au début de Rust n'étant pas un vrai GC, mais du comptage de références (parce que le travail n'était pas terminé).
- l'utilisation du GC a toujours pensée comme optionnelle : en gros on déclarait une référence comme étant "garbage collectable" (le langage a bien changé mais c'était dfans mon journal sur Rust 0.7 ).
- même quand le GC était partie intégrante du langage, le but était de s'en servir le moins possible, et par exemple la bibliothèque standard a vite atteint l'objectif de 0 GC.
- avec le temps l'équipe s'est aperçu qu'elle pouvait aller plus loin que ce qu'ils pensaient au début, et que le système de typage permettait de sortir le GC et de le penser comme une dépendance externe, sans besoin d'une syntaxe dédiée.
La gestion est déjà automatique, via le système de référence que j'ai (mal) expliqué, mais un GC optionnel serait un confort pour certaines partie de code. Ce qui complique la tâche ce sont les prérogatives assez élevées qu'imposent les buts du langage ('You pay for what you use' entre autres), quand Haskell/Ocaml/Java/Python... n'ont pas à se soucier de tels problèmes (mais ils en ont d'autres évidemment).
La différence peut être mince, comme tu le soulignes avec les unikernels, mais je dirais qu'un langage système permet de maîtriser suffisamment parfaitement le comportement du code pour pouvoir écrire du code temps-réel (au sens temps réel dur, pas au sens globalement performant).
C'est très gentil de t'être donné la peine d'écrire un commentaire aussi argumenté, mais tu prêches un convaincu :) . Je sais très bien que Haskell ou OCaml ont de très bonnes performances dans la majorité des cas. Mais justement le lien que j'ai donné explique bien que Haskell va donner de très bon débit, mais va avoir des problèmes de latences ; ton benchmarck au final est équivalent à tester un débit moyen, mais ne va pas du tout tester les problèmes de latences, parce que 1) c'est pénible à tester 2) ce n'est pas ton problème.