Cela signifie que gSuneido fonctionne de manière "autonome", c'est-à-dire qu'il utilise sa propre base de données, au lieu de se connecter en tant que client à une base de données jSuneido. Bien que la différence de surface soit minime, il s'agit d'un énorme saut en interne.

J'ai travaillé sur la base de données gSuneido au cours de l'année dernière, en même temps que nous déboguions, puis déployions le client gSuneido.

Si je venais de porter l'implémentation de la base de données jSuneido, cela aurait été beaucoup plus facile, mais quel serait le plaisir à cela? J'ai conservé l'implémentation de la requête, mais j'ai repensé le moteur de stockage et la gestion des transactions. Je l'appellerais le deuxième effet système, mais c'est plutôt un troisième système puisque j'ai également repensé cela pour jSuneido.

J'ai encore beaucoup à faire. Bien que l'EDI démarre, il est assez fragile et se plante facilement. De nombreux tests échouent. Mais même pour arriver à ce point, un grand nombre de pièces doivent fonctionner correctement ensemble. C'est un peu comme construire une horloge mécanique et atteindre le point où elle commence à tourner.»

Clap de fin pour cSuneido après 20 ans de bons et loyaux services, qui cède sa place à gSuneido

Le 15/03/2021, Andrew McKinlay, créateur et développeur de Suneido, annonce sur son blog https://thesoftwarelife.blogspot.com/2021/03/twenty-years-of-csuneido.html, l'arrêt de la maintenance de cSuneido, la version d'origine en C++, dont la dernière version remonte au 17/01/2018.

«La semaine dernière a été une étape importante. Nous (mon entreprise) avons terminé la conversion de tous nos clients de cSuneido (l'implémentation C ++ d'origine) à gSuneido (l'implémentation la plus récente, dans Go).

Cela signifie que je n'ai plus besoin de maintenir cSuneido et que je n'ai plus à faire face à C++ (soupir de soulagement).
cSuneido a fait son temps. Nous l'avons déployé pour la première fois chez le premier client en 2000, il est donc utilisé en production en continu depuis plus de 20 ans. Il nous a bien rendu service.

Quand j'ai commencé à développer Suneido, à la fin des années 1990, C++ était relativement nouveau sur PC. J'ai commencé avec Zortech C++ de Walter Bright qui est devenu Symantec C++ (et plus tard Digital Mars C++). Plus tard, je suis passé à Microsoft C++ et MinGW.

Suneido, comme la plupart des langages dynamiques, utilise un ramasse-miettes. Mais pas C++. J'ai implémenté une série de mes propres ramasse-miettes conservateurs de plus en plus sophistiqués. Mais finalement, j'ai admis que mon temps serait mieux consacré à d'autres choses et je suis passé à l'utilisation du ramasse-miettes conservateur Boehm-Demers-Weiser. Dans des conditions normales d'utilisation, le ramasse-miettes conservateur fonctionne bien. Mais il y a des cas où la mémoire n'est pas recyclée et vous finissez par en manquer. C'était quelque peu tolérable du côté client, mais ce n'était pas si bon du côté serveur. (C'était l'un des facteurs qui ont incité le développement de jSuneido, la version Java que nous utilisons côté serveur. Un autre facteur était le manque de prise en charge de la concurrence en C++ à cette époque). Il a semblé pendant un moment que la balance penchait vers le ramasse-miettes. Mais Rust a donné une nouvelle vie à la gestion manuelle de la mémoire.

Honnêtement, je ne serais pas désolé de laisser C++ derrière moi. Il est devenu extrêmement complexe et, même si vous pouvez éviter une grande partie de cette complexité, il est difficile de ne pas en être affecté. J'ai aussi eu ma dose de langages dangereux. Même après 20 ans de correction de bogues, il y a très probablement encore des choses comme des débordements potentiels de mémoire tampon dans cSuneido. (Ironiquement, l'une des choses qui a ajouté beaucoup de complexité au C++, était les génériques de modèles. Pendant ce temps, j'attends avec impatience l'ajout prochain de génériques dans Go. Cependant, les génériques de Go seront beaucoup plus simples que la programmation complète de modèles de Turing en C++).

Bien qu'il puisse sembler fou de réimplémenter le même programme (Suneido) trois fois, cela a été un exercice intéressant. J'ai appris des choses à chaque fois et j'ai apporté des améliorations à chaque fois. Cela a demandé un travail supplémentaire de maintenir plusieurs versions, mais a également mis en évidence des bogues qui auraient été manqués si je n'avais eu qu'une seule implémentation. Le faire dans trois langages assez différents, C++, Java et Go, a également été instructif. Et avoir la contrainte de devoir exécuter parfaitement une grande base de code existante (environ un million de lignes de code Suneido) signifie que j'ai évité la plupart des dangers des effets de «second système».

Jusqu'à présent, je n'ai implémenté que le côté client de gSuneido. Nous utilisons toujours jSuneido (la version Java) pour le côté serveur. Je travaille actuellement sur l'implémentation de la base de données/serveur pour gSuneido (dans Go). Une fois que ce sera terminé, j'ai l'intention de retirer jSuneido également et de revenir à une seule implémentation à maintenir, comme au bon vieux temps :-). Et étant donné où j'en suis dans ma carrière, gSuneido sera presque certainement la dernière implémentation que je ferai. Je me demande si cela durera aussi longtemps que cSuneido?»

Sur Github, suivez l'évolution de gSuneido et également sa conception dans A l'intérieur de Suneido