Il y a un moment dans la vie de chaque langage de programmation où il cesse d'être un jouet et commence à être réel. Pour FLIN, ce moment est venu le 3 janvier 2026, dans la Session 026, quand un fichier .flin a compilé en bytecode, exécuté dans la VM, produit du HTML, été servi via HTTP et rendu interactivement dans Google Chrome.
Un bouton compteur qui comptait vraiment. Une liaison réactive qui se mettait vraiment à jour. Un bloc de vue qui produisait vraiment une page web.
Il a fallu 26 sessions et des milliers de lignes de Rust pour atteindre ce point. Cet article parle de cette session -- ce qui a fonctionné, ce qui a cassé, comment nous l'avons corrigé et ce que ça a fait de voir FLIN rendre pour la première fois.
Bogue 1 : débordement de pile dans les expressions match
La première tentative de compiler et exécuter la page d'accueil a planté avec une erreur de débordement de pile. La trace de pile pointait vers le gestionnaire d'expressions match dans le générateur de code.
La cause était subtile : la fonction emit_match dans src/codegen/emitter.rs supposait que l'instruction JumpIfFalse ne dépile pas la valeur de condition de la pile. En réalité, JumpIfFalse dépile toujours la condition.
La correction était de supprimer deux instructions Pop erronées :
rust// Avant (cassé) :
emit(JumpIfFalse, else_addr);
emit(Pop); // ERREUR : la condition déjà dépilée par JumpIfFalse
// Après (correct) :
emit(JumpIfFalse, else_addr);
// Pas de Pop nécessaire -- JumpIfFalse a consommé la conditionDeux lignes supprimées. Deux heures de débogage. C'est la nature des bogues de VM : le symptôme (débordement de pile) apparaît loin de la cause (un Pop supplémentaire dix instructions plus tôt), et la seule façon de le trouver est de tracer l'état de la pile instruction par instruction.
Bogue 2 : échec de comparaison de chaînes
Avec le débordement de pile corrigé, la page d'accueil compilait et la VM produisait du HTML. Mais le compteur réactif ne fonctionnait pas. Cliquer sur le bouton « Increment » ne faisait rien.
L'investigation a révélé que l'expression match pour le rendu de vues comparait les valeurs de chaîne par ObjectId plutôt que par contenu. Deux chaînes avec le même contenu mais des allocations de tas différentes n'étaient pas égales.
La correction était un helper values_equal dédié qui déréférence les objets et compare leur contenu :
rustfn values_equal(&self, a: &Value, b: &Value) -> bool {
match (a, b) {
(Value::None, Value::None) => true,
(Value::Bool(a), Value::Bool(b)) => a == b,
(Value::Int(a), Value::Int(b)) => a == b,
(Value::Float(a), Value::Float(b)) => a == b,
(Value::Int(a), Value::Float(b)) => (*a as f64) == *b,
(Value::Float(a), Value::Int(b)) => *a == (*b as f64),
(Value::Object(a_id), Value::Object(b_id)) => {
if a_id == b_id {
return true; // Même objet
}
// Déréférencer et comparer le contenu
match (self.get_object(*a_id), self.get_object(*b_id)) {
(Some(a_obj), Some(b_obj)) => match (&a_obj.data, &b_obj.data) {
(ObjectData::String(a), ObjectData::String(b)) => a == b,
(ObjectData::List(a), ObjectData::List(b)) => {
a.len() == b.len() &&
a.iter().zip(b.iter()).all(|(x, y)| self.values_equal(x, y))
}
_ => false,
},
_ => false,
}
}
_ => false,
}
}Le moment où ça a fonctionné
Avec les deux bogues corrigés, nous avons reconstruit le binaire FLIN et exécuté :
bash./target/release/flin dev examples/welcome.flinLe terminal a affiché :
[FLIN] Dev server running at http://localhost:3000
[FLIN] Watching examples/welcome.flin for changesOuvrir http://localhost:3000 dans Chrome a montré la page d'accueil. Le titre disait « Welcome to FLIN ». Le compteur affichait « Count: 0 ». Deux boutons : « Increment » et « Reset ».
Cliquer sur « Increment » a changé le comptage à 1. Cliquer encore : 2. Encore : 3. Cliquer sur « Reset » l'a remis à 0. Chaque clic, la liaison {count} se mettait à jour instantanément.
Ça fonctionnait.
Un fichier .flin, écrit dans un langage qui n'existait pas huit jours plus tôt, compilé en bytecode par un compilateur écrit à partir de zéro en Rust, exécuté par une machine virtuelle avec un ramasse-miettes, rendu en HTML par un moteur de vues avec des annotations réactives, servi via HTTP par un serveur web embarqué, et rendu interactif dans le navigateur par un runtime JavaScript de 50 lignes.
Vingt-six sessions. Pas de frameworks. Pas de dépendances au-delà de la bibliothèque standard de Rust et d'une poignée de crates. Pas d'ingénieurs humains en dehors de Thales. Un CTO IA (Claude) générant le code.
Ce que signifie le premier rendu dans le navigateur
Le premier rendu dans le navigateur est le point d'inflexion de toute technologie frontend. Avant, la technologie est académique -- intéressante mais non prouvée. Après, elle est pratique -- imparfaite mais réelle.
Pour FLIN, le premier rendu dans le navigateur a prouvé plusieurs choses simultanément :
- L'architecture fonctionne. Une VM basée sur la pile écrite en Rust peut produire du HTML assez vite pour des applications web interactives.
- Le modèle de réactivité fonctionne. Un proxy JavaScript avec des annotations
data-flin-bindest suffisant pour des mises à jour d'interface utilisateur réactives. - Le modèle mono-fichier fonctionne. Un développeur peut écrire un seul fichier
.flinet obtenir une page web fonctionnelle. - Le modèle CEO + CTO IA fonctionne. Thales et Claude, travaillant depuis Abidjan, ont construit un langage de programmation qui rend dans le navigateur. Pas d'équipe de dix. Pas de cycle de développement d'un an. Vingt-six sessions.
Les statistiques racontent l'histoire en chiffres : 617 tests réussis, 4 fichiers modifiés, 200 lignes ajoutées, 2 bogues critiques corrigés. Mais les chiffres ne capturent pas le changement psychologique. Avant la Session 026, chaque session construisait vers un objectif incertain. Après la Session 026, chaque session améliorait un produit fonctionnel.
Ceci est la partie 29 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont construit un langage de programmation à partir de zéro.
Prochain : [30] Agents parallèles dans le runtime FLIN -- comment nous avons utilisé l'exécution concurrente et le passage de messages pour construire des fonctionnalités en parallèle.