Ce n'est pas un clone de Redis, et ça n'a pas la vocation de faire exactement ses tâches (autant l'utiliser lui directement).
Il n'y a pas aujourd'hui dans Robert, la possibilité de faire des réseaux interprocessus, où chacun serait soit un maître, soit un esclave (même pourquoi pas à l'avenir avec les fonctions de souscription, j'y ai pensé).
Sur la gestion des valeurs stockées, une base avec des centaines voire des milliers de hashmap et des fonctions de souscription, ça représente vite un projet qui nécessite de se pencher très, très sérieusement sur la gestion des données périmées effectivement, au niveau logique et de l'implémentation précisément. Une fuite de mémoire peut être un catastrophe rapide et sans aller jusque là, c'est juste pénible à suivre en terme de programmation.
Rust a choisi dans son fonctionnement, de se pencher sur les durées de vie et c'est tout l'intérêt d'avoir un garbage collector statique, qui est par nature bien plus sûr que du C et équivalent (de mémoire Redis est en C), tout en offrant des performances plus intéressantes qu'un langage interprété.
Sur la définition d'un délai d'expiration, ce n'est pas propre à un outil ou le choix d'un langage pour moi, mais un attribut d'une implémentation ou d'un usage. Sur Robert, la mise en œuvre me paraît facile : une boucle qui parcourt à un rythme régulier le stockage et lors d'un accès à une valeur, confirmer que son délai est toujours actif. La gestion des accès concurrentiels est réglé via Arc+Mutex, pour tous les canaux.
J'espère avoir répondu à l'interrogation...
Au-delà, sur le choix de Rust, à la différence d'un projet qui aurait été en Java par exemple, il n'y a pas besoin d'avoir une plateforme logicielle sous-jacente lourde. L'emprise mémoire pour la gestion de Robert est très faible. De plus Rust a un niveau de finesse et robustesse natif (refus de compilation sinon), qui est un gage de qualité supplémentaire.
[^] # 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é à 3.
Ce n'est pas un clone de Redis, et ça n'a pas la vocation de faire exactement ses tâches (autant l'utiliser lui directement).
Il n'y a pas aujourd'hui dans Robert, la possibilité de faire des réseaux interprocessus, où chacun serait soit un maître, soit un esclave (même pourquoi pas à l'avenir avec les fonctions de souscription, j'y ai pensé).
Sur la gestion des valeurs stockées, une base avec des centaines voire des milliers de hashmap et des fonctions de souscription, ça représente vite un projet qui nécessite de se pencher très, très sérieusement sur la gestion des données périmées effectivement, au niveau logique et de l'implémentation précisément. Une fuite de mémoire peut être un catastrophe rapide et sans aller jusque là, c'est juste pénible à suivre en terme de programmation.
Rust a choisi dans son fonctionnement, de se pencher sur les durées de vie et c'est tout l'intérêt d'avoir un garbage collector statique, qui est par nature bien plus sûr que du C et équivalent (de mémoire Redis est en C), tout en offrant des performances plus intéressantes qu'un langage interprété.
Sur la définition d'un délai d'expiration, ce n'est pas propre à un outil ou le choix d'un langage pour moi, mais un attribut d'une implémentation ou d'un usage. Sur Robert, la mise en œuvre me paraît facile : une boucle qui parcourt à un rythme régulier le stockage et lors d'un accès à une valeur, confirmer que son délai est toujours actif. La gestion des accès concurrentiels est réglé via Arc+Mutex, pour tous les canaux.
J'espère avoir répondu à l'interrogation...
Au-delà, sur le choix de Rust, à la différence d'un projet qui aurait été en Java par exemple, il n'y a pas besoin d'avoir une plateforme logicielle sous-jacente lourde. L'emprise mémoire pour la gestion de Robert est très faible. De plus Rust a un niveau de finesse et robustesse natif (refus de compilation sinon), qui est un gage de qualité supplémentaire.