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

• Études pendant 5 ans dans une école d’informatique en France, puis 20 ans d’activité comme développeur freelance
• Travail principalement sur des projets clients en Ruby on Rails
• Début de l’apprentissage de Common Lisp, avec l’écriture d’un protocole d’administration de serveur générant un parseur ASN.1
  • Développement d’un serveur SNMP en générant du code C depuis Common Lisp
• Ensuite, création de plusieurs projets basés sur Common Lisp :
  • cl-unix-cybernetics – le projet le plus étoilé sur GitHub
  • Développement de cl-streams et cffi-posix
  • cl-facts – un triple store jouant le rôle de base de données graphe en Common Lisp
    • Rapide, avec transactions atomiques et transactions imbriquées
    • Compatible avec unwind-protect
    • Utilisable après avoir appris seulement 3 macros
    • Présenté à l’European Lisp Symposium (ELS)
• En se concentrant sur le développement en Common Lisp, perte des clients, mais conviction très forte dans le potentiel de Lisp

Limites des machines virtuelles (VM) et des conteneurs

• Des experts pointent les problèmes des VM et des conteneurs :
  • Les VM gaspillent inutilement du CPU et de la bande passante
  • Les conteneurs Linux basés sur les cgroups présentent des vulnérabilités d’exécution de code à distance (RCE) et d’élévation de privilèges
  • De nouvelles failles de sécurité sont découvertes chaque année
• Préférence pour OpenBSD, ce qui permet d’éviter les problèmes d’outils DevOps comme Terraform et Ansible

Limites de Common Lisp et problèmes de performances

• Des problèmes de performances apparaissent dans Clojure et d’autres environnements à cause du GC (garbage collector) :
  • Cas d’échec lors du développement d’un jeu de stratégie traitant des milliers d’unités
  • Le GC de la JVM entraîne des problèmes de performance et de coût

Décision de revenir au C

• Prise de conscience des limites de Common Lisp en matière de performances et de portabilité :
  • Linux, OpenBSD, GTK+ et GNOME sont tous écrits en C
  • Retour final au C pour résoudre les problèmes de performances et de portabilité

Développement du nouveau langage KC3

• Développement de la bibliothèque utilitaire libc3 → langage C3 → renommé ensuite en KC3
• Caractéristiques de KC3 :
  • Présence d’un interpréteur (ic3) et d’un compilateur (c3c)
  • Création de structures de données depuis des buffers UTF-8 et conversion inverse
  • Programmation défensive → minimisation des bugs dès le départ
  • Aucun problème de sécurité
  • Système de types basé sur des unions taguées par enum

Résultats obtenus avec KC3

• Portage de cl-facts en C89 :
  • Développement terminé pendant la période du Covid-19
  • Implémentation de l’ajout de triplets, de la suppression, d’un système de requêtes récursives, des transactions, de la journalisation, de la persistance, etc.
• Écriture de parseurs et de générateurs pour les types algorithmiques :
  • Incluant structures, listes chaînées, maps, tables de hachage, nombres complexes, tuples, blocs de code, etc.
  • Forte inspiration reçue de José Valim (créateur d’Elixir)
• ikc3 – un REPL affichant les résultats d’évaluation de KC3
• kc3_httpd – développement d’un serveur web basé sur un framework MVC
  • La page de blog actuelle est elle aussi servie par kc3_httpd
• Création d’un site de documentation → utilisation du convertisseur Markdown vers HTML de KC3

Conclusion

• Retour au C sur la base de l’expérience acquise avec Common Lisp
• KC3 obtient d’excellents résultats en performances, sécurité et portabilité
• D’autres macros et exemples liés à KC3 seront publiés à l’avenir

[GN⁺]

Commentaires Hacker News

• Je suis d’un avis contraire. J’ai beaucoup utilisé VB quand j’étais jeune, puis j’ai appris Java, C et C++ à l’université, en utilisant surtout C. Je suis devenu développeur principal de Xfce et j’y ai travaillé pendant 5 ans

  • Ensuite, je me suis reconverti dans le développement backend et j’ai utilisé Java, Scala et Python. Ces langages apportent d’autres problèmes, mais j’aimais leur bibliothèque standard et leurs systèmes de gestion des dépendances
  • Je suis revenu à Xfce 12 ans plus tard, et C reste toujours difficile. Il y a beaucoup de problèmes comme les fuites mémoire, les déréférencements de pointeurs NULL et les conditions de concurrence
  • En utilisant Rust, je suis devenu plus productif qu’avec C

• Je comprends totalement ce sentiment. Pendant des années, j’ai ressenti une forte envie de développer quelque chose en C pur

  • Mon langage principal est le C++, mais j’aime vraiment utiliser d’anciennes bibliothèques C. Leurs interfaces sont simples et fondamentales
  • Quand je développe des méthodes en C pur, j’aime pouvoir me concentrer à 100 % sur l’algorithme
  • C m’oblige à faire le travail moi-même. Il ne cache ni la magie ni la complexité
  • Les gens autour de moi veulent utiliser les fonctionnalités modernes de C++, alors que moi, j’essaie de supprimer de plus en plus de fonctionnalités C++

• J’ai commencé à programmer en C il y a longtemps, et il m’arrive encore parfois de vouloir revenir à cette époque

  • Mais dès qu’on essaie réellement d’écrire une application de niveau production en C, on comprend pourquoi on a arrêté
  • Il y a trop de choses qu’il faut faire soi-même, sans l’aide de l’ordinateur
  • Si je devais choisir aujourd’hui un langage bas niveau, je prendrais probablement Ada. C’est similaire au C, mais avec davantage d’assistance du compilateur

• Après avoir lu le billet de blog, j’étais confus sur ce que l’auteur voulait transmettre

  • Je me demandais si la raison pour laquelle son programme n’est pas utilisé venait vraiment du langage
  • Il peut y avoir des problèmes liés à la consommation mémoire
  • L’auteur n’a mentionné ni les leçons apprises ni des statistiques d’usage
  • Aucune nouvelle fonctionnalité n’a été ajoutée, on dirait simplement une réécriture pour s’exercer

• Un exemple de code kc3 a été fourni

• C a été mon premier langage, et j’ai créé des applications console simples et de petits jeux

  • Mais je n’ai pas envie d’y revenir. Les outils de build et la gestion des dépendances sont dépassés
  • Zig est mon nouveau C. Il inclut un compilateur C et permet d’utiliser des en-têtes C sans wrapper
  • J’utilise Go quand j’ai besoin d’un langage simple, et Rust quand j’ai besoin de performance et de sécurité

• Il m’arrive de coder en C comme loisir. Mais il y a trop de travail répétitif, et cela devient ennuyeux

  • Écrire un compilateur en C revient à manipuler des unions taguées
  • J’ai pensé à écrire un générateur pour réduire le travail répétitif, mais je ne l’ai pas encore fait
  • Quand je développe un projet en C, j’ai envisagé d’utiliser un langage embarqué pour le prototypage

• C a eu du succès parce qu’il est pratique

  • Ce n’est pas sûr, mais il permet de faire ce qu’on veut

• Je ne comprends rien du tout

  • Je me demande ce qu’est la killer app, quels sont les problèmes liés à CL, et si C est vraiment la seule option
  • Je me demande s’il est vraiment certain qu’il n’y a aucun problème de sécurité dans l’exécution du code KC3

• Ce billet ressemble à un récit d’avertissement sans happy end