Merci pour cet article et projet ambitieux et très intéressant.
J'ai moi même utiliser Nix à l’échelle pour de gros déploiement de stack en entreprise.
Je partage votre avis sur Nix qui a besoin d'un remplaçant.
Nix a trop de problème pour être sauvé:
Le langage a été baclé et a une montagne de problème (hello no typing). Il est maintenant dans 100k packages et inchangeable. Le système de Hook et le compiler wrapper en bash qui cache la misère en est un autre.
La qualité du code du software lui même est franchement douteuse et le projet est contrôlé par une petite élite qui refuse la plupart des changements (ceci depuis le début du projet).
Les CLIs sont une purge à utiliser, les options n'ont aucun sens et se contredisent entre les trois command line tools principaux. Le nouveau CLI unifié "nix" a les mème problème en plus d'etre marqué en 'experimental' depuis des années.
Les flakes sont un hack et une usine à Gaz illisible. En plus de poser des problèmes de tracabilités, ils posent de sérieux problème de performance.
J'ai à vrai dire moi même longtemps hésiter à forker le projet mais au vu du travail nécessaire et de mon temps libre, j'ai vite oublié l'idée.
L'idée d'une re-implémentation est bonne.
Et pourquoi pas en Rust pour un tool système.
Par contre: pourquoi OCaml pour le scripting ?
La critique récurrente que j'entends sur Guix (qui a un bien meilleur design) est justement l'utilisation de Guile.
Guix a choisi Guile car GNU, ce qui peut se comprendre au vu des ambitions du projets.
Mais essayer de convaincre une communauté de faire du Guile se traduit souvent pas un "No thx. Ce truc est illisible et encore pire que Nix. J'ai (aucune (envie (de (ca))))".
Et c'est une des raisons principales derrière le fait que Guix n'ait qu'une faible nombre de paquets comparé à Nixpkgs.
Il y a fort à parier que la même chose se produise pour OCaml, même si c'est objectivement plus facile à maintenir que du Scheme.
Ca reste un langage fonctionnel de niche qui n'a jamais été désigné pour du scripting.
# Pourquoi OCaml ?
Posté par Firwen (site web personnel) . En réponse à la dépêche Elpe, un compromis entre NixOS et Ubuntu. Évalué à 4.
Merci pour cet article et projet ambitieux et très intéressant.
J'ai moi même utiliser Nix à l’échelle pour de gros déploiement de stack en entreprise.
Je partage votre avis sur Nix qui a besoin d'un remplaçant.
Nix a trop de problème pour être sauvé:
Le langage a été baclé et a une montagne de problème (hello no typing). Il est maintenant dans 100k packages et inchangeable. Le système de Hook et le compiler wrapper en bash qui cache la misère en est un autre.
La qualité du code du software lui même est franchement douteuse et le projet est contrôlé par une petite élite qui refuse la plupart des changements (ceci depuis le début du projet).
Les CLIs sont une purge à utiliser, les options n'ont aucun sens et se contredisent entre les trois command line tools principaux. Le nouveau CLI unifié "nix" a les mème problème en plus d'etre marqué en 'experimental' depuis des années.
Les flakes sont un hack et une usine à Gaz illisible. En plus de poser des problèmes de tracabilités, ils posent de sérieux problème de performance.
J'ai à vrai dire moi même longtemps hésiter à forker le projet mais au vu du travail nécessaire et de mon temps libre, j'ai vite oublié l'idée.
L'idée d'une re-implémentation est bonne.
Et pourquoi pas en Rust pour un tool système.
Par contre: pourquoi OCaml pour le scripting ?
La critique récurrente que j'entends sur Guix (qui a un bien meilleur design) est justement l'utilisation de Guile.
Guix a choisi Guile car GNU, ce qui peut se comprendre au vu des ambitions du projets.
Mais essayer de convaincre une communauté de faire du Guile se traduit souvent pas un "No thx. Ce truc est illisible et encore pire que Nix. J'ai (aucune (envie (de (ca))))".
Et c'est une des raisons principales derrière le fait que Guix n'ait qu'une faible nombre de paquets comparé à Nixpkgs.
Il y a fort à parier que la même chose se produise pour OCaml, même si c'est objectivement plus facile à maintenir que du Scheme.
Ca reste un langage fonctionnel de niche qui n'a jamais été désigné pour du scripting.