En dehors de projets éducatifs je ne comprends pas l’intérêt étant donné la masse de documentations et projets existants en anglais.
En rapport avec le choix de la langue, pour moi c’est un frein à l’adoption : on privilégie sa localité au détriment des autres. Ça me rappelle tous ces projets en Chinois dont on ne peut pratiquement rien faire car il n’existe aucune documentation en anglais.
Ça donne aussi un mélange très étrange entre anglais et français, vu que le langage et la lib standard sont en anglais. Ça fait encore plus de gymnastique pour passer de l’un à l’autre.
De plus, au niveau du code, ça n’a amha que peu d’importance : les utilisateurs utilisent un binaire, pas du code source.
Certes. L'anglais est une convention. Une convention est par nature, une convention : ce qui est convenu dans un groupe donné. Aucune langue n'est éternelle, sans évolution. Je ne crois pas que l'anglais le soit pour l'informatique car, comme tu le soulignes, l'indien ou le chinois ont un poil plus d'utilisateurs (surtout réunis) dans les informaticiens que ceux du bloc classique occidental dans un proche avenir (si ce n'est pas déjà le cas).
Le débat sur ce point, fait de ma position une position ultra-minoritaire j'en suis conscient. Mais je crois qu'il faut des projets qui ne soit pas nécessairement en anglais "parce que c'est comme ça". Pour moi, fondamentalement, c'est un rapport d'abord à la communauté que l'on créée, où l'on est, où l'on agit.
Pour la lib standard, justement. Combien - je m'inclue dedans - ont passé parfois des heures à comprendre tel ou tel point, en anglais ? Si la réponse est "Google Translate" alors soit, c'est "Google Translate" - mais ce qui est valable anglais -> français est donc valable français -> anglais.
Pour l'utilisateur lambda, la doc et le code en français peut avoir un sens car le français ne se limite pas à la France et est une communauté parmi les plus nombreuses au monde.
Par contre on est d'accord : en soi du code en français, on s'en fiche, d'autant que ce qui compte c'est que la machine comprenne les instructions...
Pour ce qui est de la traduction des « crate » Rust, je ne pense pas que cela rende les choses plus claires :)
Non, et Rust est limité en pouvoir descriptif dans ses concepts. Juste le terme "module" reprend parfois des choses différentes, entre une "caisse", un fichier du projet..
Selon les objectifs, tout refaire sois-même peut-être autant sinon plus de code à maintenir, sans parler des problèmes de sécurité/performance résolus par d’autres projets.
Choisir consciencieusement ses dépendances est à mon avis plus intéressant. Tu prends l’exemple de Regex, je pensais aussi à ce genre de chose, mais pas que. Il existe des bibliothèques permettant d’atteindre des performances bien meilleures que les dictionnaires (hashmap/hashset) de la lib standard par exemple.
Tu as tout à faire raison, c'est un risque. Mais comme c'est sous-entendu, le risque était soit de faire un rassemblement de projets extérieurs avec des dépendances qui, sérieusement, ne seraient relues (et potentiellement seraient abandonnées), soit le refaire et avoir un projet homogène dans sa maturation. J'ai fait le choix de l’homogénéité.
Sur Hashmap, j'ai pris le choix d'aller vers la simplicité conceptuelle : une paire clé/valeur pour chaque entrée, qui sont rassemblées ensemble. Hashset aurait impliqué de faire un travail supplémentaire, car le hash est sur l'objet stocké et non sur la clé. Hashmap a une gestion des clés par hash.
En terme de code (j’ai largement survolé, de très très haut), je vois que tu te sers de HashMap provenant de la lib standard. Les performances de ce type sont vraiment mauvaises : les implémentations de Python et Go font largement mieux par exemple. S’il y a une volonté d’être performant, il faut absolument s’orienter vers d’autres implémentations en attendant.
De fait si l'on prend toutes les attendus du projet (intégrité de l'outil ; support natif ; performance ; simplicité conceptuelle et de maintenance), je trouve que c'est un choix raisonnable.
J'entends parfaitement ce que c'est pas le choix le plus performant (encore que), mais c'est un choix qui ne prend pas que la performance.
Pour la comparaison avec Python, compte tenu que Rust est compilé avec des performances très proches du C, j'ai un doute que l'implémentation soit moins bonne. Pour Go, je sais pas trop.
Tu me mets le doute, je vais regarder et tester ça.
Si je comprends bien c’est à la fois un "pub/sub" et une "base" comme on pourrait en avoir dans redis ?
Oui je crois.
Quel est l’intérêt par rapport à une modélisation "à plat" clef-valeur toute simple ?
En terme de performance, cela veut dire qu’à chaque fois que l’on veut traverser des objets, il faut charger en cascade des espaces mémoire aléatoirement dans la RAM.
En terme d’usage, je ne vois pas d’avantage à simplement avoir une clef correspondant au chemin complet, et une valeur au bout. Sauf peut-être pour l’expiration d’un groupe de valeurs, éventuellement.
Peux-tu m’éclairer à ce sujet ?
Bien sûr. L'actualité n'est sûrement pas clair. Le canal dispose d'une hashmap qui est une valeur comme une autre, de type "objet" (qui contient donc d'autres valeurs). Le chemin correspond à tous les objets à traverser pour atteindre la valeur finale (qui est un des 5 types).
Ce n'est donc pas du tout une base "à plat" mais un arbre de hashmap, dont l'origine est le canal lui-même (j'espère que c'est plus clair ?).
Sur la partie scripting, j’ai pas compris le choix d’un caractère "difficile" à taper, limitant encore plus l’accessibilité : ø. Si c’était pour désambiguïser l’usage du "o" et du "0", ok, mais alors choisir un caractère facilement accessible me semble judicieux.
Ce n'est pas pour l’ambiguïté, mais au contraire pour être sûr que le scripteur veux bien l'inconditionnalité (c'est-à-dire que la commande sera toujours exécutée).
Voilà mon petit retour :) Personnellement je ne vois pas d’intérêt de ce projet par rapport à Redis, ou même memcached si ce n’est l’utilisation d’un langage théoriquement exempt de problèmes de pointeurs null et autres overflows.
Ce qui est déjà pas mal tu ne crois pas ? Beaucoup de choses dans la surface d'attaque ou de problématiques portent sur la question des pointeurs et des débordements.
Après peu importe, c’est toujours une bonne expérience de faire quelque chose de concret, et j’espère que mon commentaire pourra t’apporter quelque chose.
Je te remercie de ton commentaire, qui me permet d'être, j'espère, plus clair et précis, comme d'argumenter sur le projet.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 10.
Merci !
Certes. L'anglais est une convention. Une convention est par nature, une convention : ce qui est convenu dans un groupe donné. Aucune langue n'est éternelle, sans évolution. Je ne crois pas que l'anglais le soit pour l'informatique car, comme tu le soulignes, l'indien ou le chinois ont un poil plus d'utilisateurs (surtout réunis) dans les informaticiens que ceux du bloc classique occidental dans un proche avenir (si ce n'est pas déjà le cas).
Le débat sur ce point, fait de ma position une position ultra-minoritaire j'en suis conscient. Mais je crois qu'il faut des projets qui ne soit pas nécessairement en anglais "parce que c'est comme ça". Pour moi, fondamentalement, c'est un rapport d'abord à la communauté que l'on créée, où l'on est, où l'on agit.
Pour la lib standard, justement. Combien - je m'inclue dedans - ont passé parfois des heures à comprendre tel ou tel point, en anglais ? Si la réponse est "Google Translate" alors soit, c'est "Google Translate" - mais ce qui est valable anglais -> français est donc valable français -> anglais.
Pour l'utilisateur lambda, la doc et le code en français peut avoir un sens car le français ne se limite pas à la France et est une communauté parmi les plus nombreuses au monde.
Par contre on est d'accord : en soi du code en français, on s'en fiche, d'autant que ce qui compte c'est que la machine comprenne les instructions...
Non, et Rust est limité en pouvoir descriptif dans ses concepts. Juste le terme "module" reprend parfois des choses différentes, entre une "caisse", un fichier du projet..
Tu as tout à faire raison, c'est un risque. Mais comme c'est sous-entendu, le risque était soit de faire un rassemblement de projets extérieurs avec des dépendances qui, sérieusement, ne seraient relues (et potentiellement seraient abandonnées), soit le refaire et avoir un projet homogène dans sa maturation. J'ai fait le choix de l’homogénéité.
Sur Hashmap, j'ai pris le choix d'aller vers la simplicité conceptuelle : une paire clé/valeur pour chaque entrée, qui sont rassemblées ensemble. Hashset aurait impliqué de faire un travail supplémentaire, car le hash est sur l'objet stocké et non sur la clé. Hashmap a une gestion des clés par hash.
De fait si l'on prend toutes les attendus du projet (intégrité de l'outil ; support natif ; performance ; simplicité conceptuelle et de maintenance), je trouve que c'est un choix raisonnable.
J'entends parfaitement ce que c'est pas le choix le plus performant (encore que), mais c'est un choix qui ne prend pas que la performance.
Pour la comparaison avec Python, compte tenu que Rust est compilé avec des performances très proches du C, j'ai un doute que l'implémentation soit moins bonne. Pour Go, je sais pas trop.
Tu me mets le doute, je vais regarder et tester ça.
Oui je crois.
Bien sûr. L'actualité n'est sûrement pas clair. Le canal dispose d'une hashmap qui est une valeur comme une autre, de type "objet" (qui contient donc d'autres valeurs). Le chemin correspond à tous les objets à traverser pour atteindre la valeur finale (qui est un des 5 types).
Ce n'est donc pas du tout une base "à plat" mais un arbre de hashmap, dont l'origine est le canal lui-même (j'espère que c'est plus clair ?).
Ce n'est pas pour l’ambiguïté, mais au contraire pour être sûr que le scripteur veux bien l'inconditionnalité (c'est-à-dire que la commande sera toujours exécutée).
Ce qui est déjà pas mal tu ne crois pas ? Beaucoup de choses dans la surface d'attaque ou de problématiques portent sur la question des pointeurs et des débordements.
Je te remercie de ton commentaire, qui me permet d'être, j'espère, plus clair et précis, comme d'argumenter sur le projet.