Et c'est une des raisons principales derrière le fait que Guix n'ait qu'une faible nombre de paquets comparé à Nixpkgs.
Hum, et peut-être aussi que Guix est moitié plus jeune (Nix ~22 ans vs Guix ~12 ans). :-)
Je me permets de préciser un point : à part le démon, pour Guix tout est en Guile, de la définition de paquets à la configuration en passant par toutes les parties internes de Guix. Certes, quand on n'aime pas les parenthèses, c'est fâcheux. ;-) Cependant, le point est clé est une continuité entre tous les composants : ma distribution devient une bibliothèque Scheme que je peux manipuler.
Quelque part, Guix pourrait être vu comme une mise en application de The Emacs Thesis décrite par le manuel Guile.
À nouveau, le langage Guile/Scheme a des tas de faiblesses, oulà oui ! :-) Cependant, les propriétés de Lisp (macro, reader, S-exp, etc.) permettent d'implémenter des DSLs pour étendre le langage lui-même. Il est toujours possible de faire ce genre de trucs dans d'autres langages mais il faut dire que le Scheme est vraiment super adapté.
Tout ceci dit, Guile a des tas de faiblesses : 1. pas vraiment de debugger décent ÀMHA et 2. pas assez de typage à la compilation, dur dur la refactorisation, la vérification de la composition, etc.
Ce serait chouette s'il y avait un truc à la sauce Typed Racket avec du gradual typing.
Des exemples comme MirageOS montrent qu'OCaml serait peut-être un bon choix. :-) Mais bon, si on se plaint du nombre de paquets dans Guix après plus de 10 ans avec une communauté certes petite mais active, je serais curieux de voir une "réimplémentation" de toutes ces idées from scratch quelque soit le langage...
[^] # Re: Pourquoi OCaml ?
Posté par zimoun . En réponse à la dépêche Elpe, un compromis entre NixOS et Ubuntu. Évalué à 3.
Hum, et peut-être aussi que Guix est moitié plus jeune (Nix ~22 ans vs Guix ~12 ans). :-)
Je me permets de préciser un point : à part le démon, pour Guix tout est en Guile, de la définition de paquets à la configuration en passant par toutes les parties internes de Guix. Certes, quand on n'aime pas les parenthèses, c'est fâcheux. ;-) Cependant, le point est clé est une continuité entre tous les composants : ma distribution devient une bibliothèque Scheme que je peux manipuler.
Quelque part, Guix pourrait être vu comme une mise en application de The Emacs Thesis décrite par le manuel Guile.
À nouveau, le langage Guile/Scheme a des tas de faiblesses, oulà oui ! :-) Cependant, les propriétés de Lisp (macro, reader, S-exp, etc.) permettent d'implémenter des DSLs pour étendre le langage lui-même. Il est toujours possible de faire ce genre de trucs dans d'autres langages mais il faut dire que le Scheme est vraiment super adapté.
Tout ceci dit, Guile a des tas de faiblesses : 1. pas vraiment de debugger décent ÀMHA et 2. pas assez de typage à la compilation, dur dur la refactorisation, la vérification de la composition, etc.
Ce serait chouette s'il y avait un truc à la sauce Typed Racket avec du gradual typing.
Des exemples comme MirageOS montrent qu'OCaml serait peut-être un bon choix. :-) Mais bon, si on se plaint du nombre de paquets dans Guix après plus de 10 ans avec une communauté certes petite mais active, je serais curieux de voir une "réimplémentation" de toutes ces idées from scratch quelque soit le langage...