Il y a un moment dans chaque projet logiciel où la question passe de « est-ce que ça marche ? » à « est-ce que ça continue de marcher ? » Les fonctionnalités sont construites. Les tests passent. La démo est impressionnante. Mais l'écart entre une démo fonctionnelle et un système de production se mesure non pas en fonctionnalités mais en défaillances -- spécifiquement, dans la façon dont le système se comporte quand les choses tournent mal.
La phase 1 du durcissement de production de FLIN s'est concentrée sur l'élimination de chaque chemin de code qui pouvait causer un crash de processus. Cela signifiait convertir les panics en erreurs gérées, ajouter des limites de timeout aux opérations potentiellement bloquantes, et garantir que les entrées malformées des utilisateurs ne pouvaient jamais faire tomber le serveur.
Ceci est la partie 181 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [180] Fonctions fléchées et inférence lambda - [181] Durcissement pour la production, phase 1 : stabilité (vous êtes ici) - [182] Durcissement pour la production, phase 2 : fiabilité