Pourquoi j’ai tout arrêté pour recommencer à écrire en C

• Après 20 ans comme freelance Ruby on Rails, l’expérience a débouché sur des projets en Common Lisp, mais l’accumulation de limites en performance, portabilité et environnement d’exécution a conduit à revenir vers le C
• cl-facts disposait d’un triple store rapide et de transactions atomiques imbriquables, mais le temps de développement trop long a aussi entraîné la perte de clients
• Les frustrations liées aux machines virtuelles, aux conteneurs basés sur les cgroups Linux et au garbage collector ont mené à la conclusion que le C reste une base pragmatique pour les logiciels système
• Le travail entamé avec libc3 s’est étendu à la conception du langage C3, de l’interpréteur ic3 et du compilateur c3c, avant d’être renommé KC3 à cause d’un conflit de nom
• Aujourd’hui, KC3 inclut un graphe de base de données porté en C89, le REPL ikc3, le serveur web MVC kc3_httpd, ainsi qu’un site de documentation basé sur une implémentation C de Markdown vers HTML

---

Comment le travail en Common Lisp a mené à une réécriture en C

• Après 5 années d’études dans une école d’informatique en France et 20 ans de travail comme développeur freelance Ruby on Rails, ce qui devait être un court apprentissage de Common Lisp est devenu un projet de plus en plus vaste
• Du code C a été généré depuis Common Lisp pour créer un parseur ASN.1 et un système de requêtes, puis ce travail a évolué vers un serveur SNMP sur mesure en Common Lisp-vers-C
• Plusieurs paquets Common Lisp ont ensuite été écrits
  • cl-unix-cybernetics est devenu le dépôt GitHub le plus étoilé
  • cl-streams et cffi-posix ont aussi été développés
  • cl-facts est un triple store utilisable comme base de données graphe en Common Lisp
• cl-facts offrait de hautes performances, des transactions atomiques, des transactions imbriquables, une compatibilité avec unwind-protect et une utilisation qui ne demandait d’apprendre que 3 macros
• cl-facts a été présenté en lightning talk à l’European Lisp Symposium en Belgique, et les slides sont disponibles dans facts.pdf
• Le développement de paquets Common Lisp prenait beaucoup de temps et a fait perdre des clients, mais Common Lisp est considéré comme un outil pour les générations futures

C, KC3 et la configuration actuelle

• L’expérience selon laquelle les machines virtuelles gaspillent CPU et bande passante en émulation, et que les conteneurs basés sur les cgroups Linux continuent de révéler des problèmes de RCE et d’élévation de privilèges, a conduit à un choix centré sur OpenBSD
• Les outils DevOps comme Terraform et Ansible ont été évités, et l’auteur a aussi vu des personnes mécontentes non seulement des VM et des conteneurs, mais aussi des langages de programmation eux-mêmes
• Un cas de jeu de stratégie en Clojure, avec des milliers d’unités ayant chacune leur propre perception du monde, a échoué à cause du garbage collector
• Les projets en Common Lisp aussi voyaient leur champ d’application limité par le garbage collector, tandis que celui de la JVM est jugé performant mais coûteux à bien concevoir, ce qui en fait un avantage commercial
• En tenant compte des performances et de la portabilité, le choix jugé raisonnable en l’absence d’outils supplémentaires est le C
  • Linux est écrit en C
  • OpenBSD est écrit en C
  • GTK+ est écrit en pur C orienté objet
  • GNOME est écrit en C
  • De nombreuses applications desktop Linux sont aussi écrites dans un ancien C
• Parti de la bibliothèque utilitaire libc3, le projet a évolué vers le langage C3, l’interpréteur ic3 et le compilateur c3c
• Des buffers UTF-8 et des structures de données ont été conçus pour circuler rapidement, avec l’acceptation d’un coût mémoire afin d’appliquer des bounds checks
• L’orientation a été résolument celle de la programmation défensive, avec l’objectif de réduire les bugs à zéro dès le départ, et il est affirmé que le code KC3 s’exécute sans implication de sécurité
• L’interpréteur initial a été construit autour du traitement dans le REPL de tags, une union taguée par enum contenant tous les types de données du langage
• Trois ans plus tard, un refactoring en 5 couches a été achevé, tous les tests repassent, et le serveur web ne casse plus
• Le nom du langage a été changé en KC3, car C3 était déjà utilisé
• L’ancienne base de données graphe en Common Lisp cl-facts a été portée en C89
  • La majeure partie a été écrite durant les confinements liés au Covid-19 en 2020
  • Elle inclut l’ajout et la suppression de triplets, un système de requêtes récursif, les transactions, la journalisation et la persistance
  • La conception d’origine en Common Lisp a été reproduite presque telle quelle en C89
• KC3 inclut aussi un parseur et un générateur pour traiter la sémantique formelle de plusieurs types de données algorithmiques
  • Structs, Linked lists, Maps, Hash tables, Time, Complex, Rationals, Tuples, Code blocks, Quotes, Unquotes, Copy on write, Skip lists, Sets, entre autres
  • Des macros sont présentes, et des exemples seront abordés dans un article suivant
  • Le travail de José Valim et d’Elixir a été une grande source d’inspiration
• Le REPL ikc3 parse les entrées clavier ou fichier et envoie les résultats d’évaluation KC3 vers la sortie standard, et sert à la majeure partie de la phase 2 des tests unitaires KC3
• kc3_httpd est un serveur web doté d’un framework MVC, et génère actuellement les pages web
• Un article sur Common Lisp a atteint 700 vues, et le site de documentation est réalisé avec kc3_httpd et une implémentation C étendue de Markdown vers HTML