FLIN est en alpha. Version 1.0.0-alpha.2, pour être précis. 3 452 tests passent avec zéro échec. 409 fonctions intégrées fonctionnent -- de la cryptographie et des paiements Stripe au traitement d'images et à la génération de PDF. Le compilateur gère le lexing, le parsing, la vérification de types et la génération de code. La machine virtuelle exécute du bytecode. FlinDB stocke, interroge et voyage dans le temps à travers les données. Le serveur HTTP gère les requêtes, les WebSockets, les Server-Sent Events, l'upload de fichiers et l'arrêt gracieux.
Et ce n'est pas terminé.
Cet article est un bilan transparent de où en est FLIN aujourd'hui, de ce qui a été construit, de ce qui reste et de ce à quoi ressemble le chemin vers une version stable v1.0. Pas de vaporware. Pas de flou sur les "capacités futures". Des fonctionnalités concrètes, des statuts concrets, des calendriers concrets.
Ce qui existe déjà
Avant de lister ce qui manque, il est important d'établir ce qui fonctionne. Le moteur fondamental est remarquablement complet pour un langage au stade alpha.
Le runtime (Rust, permanent)
Le runtime FLIN -- écrit en Rust et destiné à rester en Rust de manière permanente -- gère les opérations de bas niveau dont chaque application FLIN dépend.
Composant Statut Détails
--------- ------ -------
Machine virtuelle Fait Exécution bytecode, basée sur pile,
ramasse-miettes
FlinDB (ZEROCORE) Fait Base de données embarquée, requêtes temporelles,
recherche sémantique, embeddings vectoriels
Serveur HTTP Fait Routes, middleware, fichiers statiques,
WebSocket (RFC 6455), SSE
Upload de fichiers Fait 4 backends de stockage (Local, S3, R2, GCS)
Arrêt gracieux Fait SIGTERM/SIGINT, drainage de connexions,
flush du WAL
En-têtes de sécurité Fait En-têtes OWASP auto-injectés,
configurables via flin.configLe compilateur (Rust, transitionnel)
Le compilateur -- actuellement en Rust mais destiné à être réécrit en FLIN pour l'auto-hébergement -- traite les fichiers source .flin à travers quatre phases :
rustpub fn compile(source: &str) -> Result<Bytecode, CompileError> {
let tokens = Lexer::new(source).tokenize()?;
let ast = Parser::new(tokens).parse()?;
let typed_ast = TypeChecker::new().check(ast)?;
let bytecode = CodeGenerator::new().generate(typed_ast)?;
Ok(bytecode)
}Le lexer gère 42 mots-clés et plus de 60 types de tokens, incluant des constructions spécifiques à FLIN comme l'opérateur temporel @, les déclarations entity et la syntaxe de vue inline de type HTML. Le parser produit un AST complet couvrant les expressions, les instructions, les définitions d'entités, les éléments de vue, les déclarations de routes et les expressions match. Le vérificateur de types effectue l'inférence, la validation et la coercition. Le générateur de code émet du bytecode pour la VM.
Fonctions natives (409 et ça continue)
FLIN est livré avec 409 fonctions intégrées qui couvrent les opérations les plus courantes dont une application web a besoin. Elles sont implémentées en Rust pour la performance et la fiabilité, et sont disponibles dans chaque programme FLIN sans imports.
Catégorie Nombre Exemples
-------- ----- --------
Opérations sur chaînes 45+ split, join, trim, replace, pad, format
Mathématiques 30+ abs, ceil, floor, round, random, clamp
Crypto 20+ hash_sha256, hmac, bcrypt, jwt_sign, jwt_verify
Client HTTP 10+ http_get, http_post, http_put, http_delete
Email 5+ send_email, send_email_template
Stripe 8 stripe_checkout, stripe_customer_create,
stripe_subscription_create, stripe_verify_webhook
Traitement d'images 8 image_resize, image_thumbnail, image_crop,
image_convert, image_watermark
Passerelle IA 8+ ai_complete (8 fournisseurs : OpenAI, Anthropic,
Google, Mistral, Groq, Ollama, xAI, Perplexity)
OAuth 8 oauth_url, oauth_callback (Google, GitHub,
Discord, Apple)
Cache 5 cache_set, cache_get, cache_delete,
cache_clear, cache_has
Rate limiting 8 rate_limit, rate_limit_check, rate_limit_reset
PDF 5+ pdf_create, pdf_add_text, pdf_add_table
Jobs/Cron 5+ job_schedule, job_recurring, job_cancelComposants d'interface embarqués (180)
FLIN inclut 180 composants d'interface pré-construits accessibles sans installation -- boutons, formulaires, tableaux, modales, navigation, graphiques et plus encore. Ils sont stockés sous forme de map PHF (Perfect Hash Function) compilée dans le binaire, de sorte que la recherche de composants est O(1).
Infrastructure de test
Les 3 452 tests qui passent sont des tests au niveau du compilateur écrits en Rust -- ils vérifient que le lexer tokenise correctement, que le parser construit des AST valides, que le vérificateur de types détecte les erreurs, que le générateur de code émet du bytecode correct et que la VM exécute les instructions correctement. Ces tests s'exécutent dans le framework de test standard de Rust via cargo test.
Phase 1 : Alpha 2 (terminée)
La Phase 1 a comblé les lacunes les plus visibles côté développeur. Les six éléments sont terminés.
Rendu Markdown. markdown_to_html(text) convertit le Markdown en HTML en utilisant le crate pulldown-cmark. Chaque blog, site de documentation et application orientée contenu en a besoin. Utilisation : {@html markdown_to_html(article.content)}.
Export et import CSV. to_csv(list) et parse_csv(text) convertissent entre les données d'entité et le format CSV. response.csv(data, filename) sert un CSV en téléchargement. Les applications métier vivent et meurent par leur capacité à exporter vers des tableurs.
CORS configurable. Le fichier flin.config supporte maintenant un bloc cors avec origines, méthodes, en-têtes, identifiants et paramètres de max-age. Le Access-Control-Allow-Origin: * codé en dur livré en alpha 1 était un problème de sécurité pour tout déploiement en production.
cors {
origins: ["https://myapp.com", "https://admin.myapp.com"]
methods: ["GET", "POST", "PUT", "DELETE"]
headers: ["Content-Type", "Authorization"]
credentials: true
max_age: 86400
}Validation de formulaire côté client. Les décorateurs d'entité comme @required, @email et @minLength génèrent maintenant les attributs de validation HTML5 correspondants. L'utilisateur voit un retour instantané en remplissant un formulaire, sans aller-retour serveur.
Pagination par curseur. Query::after(cursor) et Query::before(cursor) permettent une pagination efficace pour les grands ensembles de données. La pagination par offset (qui scanne N lignes pour les sauter) est remplacée par la pagination par curseur (qui commence après un enregistrement connu), réduisant le temps de chargement de page de O(N) à O(1) pour les pages profondes.
Déploiement en production. Un Dockerfile, docker-compose.yml, fichier de service systemd, configurations de reverse proxy Nginx et Caddy, et une commande flin start pour le mode production (pas de rechargement à chaud, compilation optimisée).
Phase 2 : Beta (en cours)
La Phase 2 traite de la préparation à la production -- les fonctionnalités sans lesquelles un développeur construisant une vraie application génératrice de revenus finirait par buter.
Framework de test pour les applications .flin (terminé)
Les 3 452 tests existants vérifient le compilateur. Mais un développeur construisant une application todo ne pouvait pas écrire :
flintest "la création d'un todo sauvegarde en base" {
todo = Todo { title: "Tâche de test" }
save todo
assert todo.id != none
assert Todo.count > 0
}
test "les todos terminés sont filtrables" {
t1 = Todo { title: "Fait", done: true }
save t1
t2 = Todo { title: "Pas fait", done: false }
save t2
completed = Todo.where(done == true)
assert completed.count == 1
}Maintenant ils le peuvent. Le mot-clé test définit un bloc de test avec un nom et un corps. assert vérifie des conditions. flin test myapp/ exécute tous les fichiers de test avec une base de données isolée par test, exécution parallèle et sortie colorée. Cela comble la plus grande lacune pour l'adoption professionnelle.
Migrations de base de données (terminé)
Quand un développeur ajoute un champ à une entité, renomme un champ ou change un type, les données existantes dans FlinDB doivent être transformées en toute sécurité. Le système de migration détecte automatiquement les changements de schéma :
bash$ flin migrate myapp/ --status
Migrations en attente :
- Ajouter le champ "email" (text) à User
- Renommer le champ "name" -> "full_name" dans User
- Changer le type de "age" de text à int dans User
$ flin migrate myapp/
3 migrations appliquées avec succès.Le moteur de diff de schéma compare les définitions d'entités actuelles avec le schéma persisté, génère les étapes de migration et les applique avec coercition de valeurs (int vers float, text vers bool, etc.). Le support de rollback est inclus via flin migrate --rollback.
Éléments terminés supplémentaires
- Couche de cache. Cache à deux niveaux : cache automatique des requêtes d'entités avec invalidation basée sur le TTL, plus 5 fonctions natives pour le contrôle manuel du cache.
- Templates d'email. Rendu d'emails HTML avec layouts, variables et inlining CSS.
send_email_template(to, template, data)remplace les emails HTML construits manuellement. - Support des webhooks. Appels HTTP sortants déclenchés par les événements de cycle de vie des entités. Configurable dans
flin.configavec signatures HMAC-SHA256, backoff exponentiel pour les retries et journal de livraison. - Intégration Stripe. 8 fonctions natives pour les sessions de checkout, la gestion des clients, les abonnements, les factures et la vérification de webhooks.
- Traitement d'images. 8 fonctions natives pour redimensionner, rogner, pivoter, retourner, miniature, convertir, filigrane et extraction d'informations.
- Journalisation structurée. Niveaux de log, sortie JSON, rotation de fichiers et journalisation par requête. Les opérateurs de production obtiennent des logs structurés et interrogeables au lieu du bruit de
console.log. - Arrêt gracieux. Gestionnaires SIGTERM/SIGINT avec timeout de drainage de connexions configurable et flush du WAL.
- En-têtes de sécurité. En-têtes recommandés par l'OWASP auto-injectés en mode production, configurables via
flin.config.
Phase 3 : Release Candidate (planifiée)
La Phase 3 est là où FLIN passe de "fonctionne pour les early adopters" à "prêt pour les équipes de production". Les éléments sont plus grands en portée et nécessitent un travail architectural plus profond.
Système de plugins/extensions
Au fur et à mesure que la communauté grandit, les développeurs construiront des composants réutilisables, des patterns d'entités, du middleware et des utilitaires. Sans système de paquets, tout le monde réinvente la roue.
L'approche prévue est délibérément minimale : une convention de répertoire flin.modules où les fichiers FLIN partagés sont découverts automatiquement. Pas de registre de paquets, pas d'algorithme de résolution de versions, pas d'arbre de dépendances. La philosophie est que les applications FLIN doivent être autonomes, et les "paquets" doivent être des fichiers que vous copiez dans votre projet.
Projets multi-fichiers et imports
Aujourd'hui, chaque fichier .flin est indépendant. Une grande application a besoin de partager des définitions d'entités, des fonctions utilitaires et des composants entre fichiers. Le système d'import sera minimal -- pas de résolution de paquets de style npm, pas de fichiers barrel, pas de résolution de dépendances circulaires. Un simple use "path/to/file" qui amène les noms dans la portée.
Optimisation des performances
L'interpréteur bytecode de la VM est correct mais pas encore optimisé. Le travail prévu inclut :
- Fusion d'instructions. Combiner les séquences d'instructions courantes (load + add + store) en super-instructions uniques.
- Cache en ligne. Mémoriser les recherches de propriétés sur les entités pour les patterns d'accès répétés.
- Compilation anticipée. Compilation optionnelle en code natif via LLVM ou Cranelift pour les applications à forte intensité de calcul.
Auto-hébergement
L'étape ultime pour tout langage de programmation : FLIN se compile lui-même. Le compilateur (actuellement plus de 5 000 lignes de Rust) sera réécrit en FLIN, avec seulement les ~5 000 lignes du runtime Rust restantes. Ce n'est pas un objectif de vanité -- l'auto-hébergement signifie que les contributeurs de FLIN peuvent améliorer le compilateur en utilisant FLIN, ce qui abaisse dramatiquement la barrière de contribution.
Les chiffres
Un instantané de l'état actuel de FLIN en chiffres :
Métrique Valeur
------ ------
Tests qui passent 3 452
Échecs de tests 0
Fonctions intégrées 409
Composants d'interface embarqués 180
Icônes embarquées (Lucide) 1 675
Mots-clés 42
Types de tokens 60+
Modes de compilation 5 (dev, check, build, emit-ast, emit-bytecode)
Fournisseurs passerelle IA 8
Backends de stockage 4 (Local, S3, R2, GCS)
Fournisseurs OAuth 4 (Google, GitHub, Discord, Apple)
Fonctions Stripe 8
Fonctions de traitement d'images 8
Sessions de développement 336+
Lignes de Rust (estimation) 50 000+Le calendrier
Nous ne publions pas de dates fixes parce que FLIN est développé par deux personnes -- un humain et une IA -- sans pression de financement externe ni deadlines d'investisseurs. Ce que nous publions, c'est la séquence et les critères de passage.
Alpha 2 (actuelle). Assez stable pour que les développeurs construisent et testent des applications localement. Toutes les fonctionnalités de Phase 1 et la plupart de Phase 2 sont terminées.
Beta. Quand les éléments restants de Phase 2 seront terminés et que le framework de test aura été éprouvé par de vraies applications. Estimation : T2 2026.
Release Candidate. Quand le système de plugins, les imports multi-fichiers et les optimisations de performance seront en place. Estimation : T3 2026.
v1.0. Quand l'auto-hébergement sera atteint et que le langage aura été utilisé pour construire au moins trois applications de production (incluant des produits internes ZeroSuite). Estimation : T4 2026.
Le critère de passage pour la v1.0 n'est pas une liste de fonctionnalités. C'est la confiance. Quand un développeur peut construire une vraie application, la tester en profondeur, la déployer en production et la maintenir pendant des mois sans buter sur un mur qui nécessite de descendre à un autre langage -- c'est la v1.0.
Ce que les développeurs peuvent faire aujourd'hui
FLIN alpha 2 est utilisable aujourd'hui pour :
- Projets personnels et prototypes. L'expérience développeur est assez polie pour l'expérimentation rapide.
- Outils internes. Tableaux de bord métier, panneaux d'administration et applications CRUD où l'environnement contrôlé atténue les risques du stade alpha.
- Apprentissage et exploration. Comprendre le modèle de programmation de FLIN et fournir des retours qui façonnent le langage avant que la v1.0 ne solidifie l'API.
FLIN alpha 2 n'est pas encore recommandé pour :
- Applications de production servant des utilisateurs externes. La surface d'API peut changer entre alpha et v1.0.
- Applications nécessitant l'interopérabilité avec des bibliothèques JavaScript. L'écosystème est autonome ; les échappatoires vers npm n'existent pas.
- Applications à haute échelle. L'optimisation des performances est un travail de Phase 3.
Contribuer
Le runtime Rust de FLIN est ouvert aux contributions. La base de code est structurée pour la lisibilité : chaque module possède un domaine, les tests vivent à côté de l'implémentation et le pipeline de compilation est linéaire (le lexer alimente le parser qui alimente le vérificateur de types qui alimente le générateur de code).
bashgit clone https://github.com/flin-lang/flin
cd flin
cargo build --release
cargo test3 452 tests. Zéro échec. Si votre contribution ajoute une fonctionnalité, ajoutez des tests. Si votre contribution corrige un bug, ajoutez un test qui l'aurait détecté. La barre pour le merge est : cargo test passe, cargo clippy -D warnings est propre, et le code est assez clair pour que le prochain contributeur puisse le comprendre sans commentaires.
Prochain dans la série : Construire un langage de programmation depuis Abidjan, Côte d'Ivoire -- Le projet de langage de programmation le plus ambitieux de 2026 ne vient pas de San Francisco. Il vient d'un bureau à Abidjan avec un budget de 200 $/mois.