FLIN is in alpha. Version 1.0.0-alpha.2, to be precise. 3,452 tests pass with zero failures. 409 built-in functions work -- from cryptography and Stripe payments to image processing and PDF generation. The compiler handles lexing, parsing, type checking, and code generation. The virtual machine executes bytecode. FlinDB stores, queries, and time-travels through data. The HTTP server handles requests, WebSockets, Server-Sent Events, file uploads, and graceful shutdown.
And it is not done.
This article is a transparent accounting of where FLIN stands today, what has been built, what remains, and what the path to a stable v1.0 release looks like. No vaporware. No hand-waving about "future capabilities." Concrete features, concrete status, concrete timelines.
What Already Exists
Before listing what is missing, it is important to establish what works. The core engine is remarkably complete for an alpha-stage language.
The Runtime (Rust, Permanent)
The FLIN runtime -- written in Rust and intended to remain in Rust permanently -- handles the low-level operations that every FLIN application depends on.
Component Status Details
--------- ------ -------
Virtual Machine Done Bytecode execution, stack-based,
garbage collection
FlinDB (ZEROCORE) Done Embedded database, temporal queries,
semantic search, vector embeddings
HTTP Server Done Routes, middleware, static files,
WebSocket (RFC 6455), SSE
File Upload Done 4 storage backends (Local, S3, R2, GCS)
Graceful Shutdown Done SIGTERM/SIGINT, connection draining,
WAL flush
Security Headers Done OWASP headers auto-injected,
configurable via flin.configThe Compiler (Rust, Transitional)
The compiler -- currently in Rust but eventually to be rewritten in FLIN for self-hosting -- processes .flin source files through four phases:
pub 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)
}The lexer handles 42 keywords and 60+ token types, including FLIN-specific constructs like the @ temporal operator, entity declarations, and inline HTML-like view syntax. The parser produces a complete AST covering expressions, statements, entity definitions, view elements, route declarations, and match expressions. The type checker performs inference, validation, and coercion. The code generator emits bytecode for the VM.
Native Functions (409 and Counting)
FLIN ships with 409 built-in functions that cover the most common operations a web application needs. These are implemented in Rust for performance and reliability, and they are available in every FLIN program without imports.
Category Count Examples
-------- ----- --------
String operations 45+ split, join, trim, replace, pad, format
Math 30+ abs, ceil, floor, round, random, clamp
Crypto 20+ hash_sha256, hmac, bcrypt, jwt_sign, jwt_verify
HTTP client 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
Image processing 8 image_resize, image_thumbnail, image_crop,
image_convert, image_watermark
AI gateway 8+ ai_complete (8 providers: OpenAI, Anthropic,
Google, Mistral, Groq, Ollama, xAI, Perplexity)
OAuth 8 oauth_url, oauth_callback (Google, GitHub,
Discord, Apple)
Caching 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_cancelEmbedded UI Components (180)
FLIN includes 180 pre-built UI components accessible without installation -- buttons, forms, tables, modals, navigation, charts, and more. These are stored as a PHF (Perfect Hash Function) map compiled into the binary, so component lookup is O(1).
Testing Infrastructure
The 3,452 tests that pass are compiler-level tests written in Rust -- they verify that the lexer tokenizes correctly, the parser builds valid ASTs, the type checker catches errors, the code generator emits correct bytecode, and the VM executes instructions properly. These tests run in Rust's standard test framework via cargo test.
Phase 1: Alpha 2 (Completed)
Phase 1 addressed the most visible developer-facing gaps. All six items are complete.
Markdown rendering. markdown_to_html(text) converts Markdown to HTML using the pulldown-cmark crate. Every blog, documentation site, and content-driven application needs this. Usage: {@html markdown_to_html(article.content)}.
CSV export and import. to_csv(list) and parse_csv(text) convert between entity data and CSV format. response.csv(data, filename) serves CSV as a download. Business applications live and die by their ability to export to spreadsheets.
Configurable CORS. The flin.config file now supports a cors block with origins, methods, headers, credentials, and max-age settings. The hardcoded Access-Control-Allow-Origin: * that shipped in alpha 1 was a security issue for any production deployment.
cors {
origins: ["https://myapp.com", "https://admin.myapp.com"]
methods: ["GET", "POST", "PUT", "DELETE"]
headers: ["Content-Type", "Authorization"]
credentials: true
max_age: 86400
}Client-side form validation. Entity decorators like @required, @email, and @minLength now generate corresponding HTML5 validation attributes. A user sees instant feedback when filling a form, without a server round-trip.
Cursor-based pagination. Query::after(cursor) and Query::before(cursor) enable efficient pagination for large datasets. Offset pagination (which scans N rows to skip them) is replaced by cursor pagination (which starts after a known record), reducing page-load time from O(N) to O(1) for deep pages.
Production deployment. A Dockerfile, docker-compose.yml, systemd service file, Nginx and Caddy reverse proxy configurations, and a flin start command for production mode (no hot reload, optimized compilation).
Phase 2: Beta (In Progress)
Phase 2 addresses production readiness -- the features that a developer building a real, revenue-generating application would eventually hit a wall without.
Testing Framework for .flin Apps (Completed)
The 3,452 existing tests verify the compiler. But a developer building a todo app could not write:
test "creating a todo saves to database" {
todo = Todo { title: "Test task" }
save todo
assert todo.id != none
assert Todo.count > 0
}test "completed todos are filterable" { t1 = Todo { title: "Done", done: true } save t1 t2 = Todo { title: "Not done", done: false } save t2 completed = Todo.where(done == true) assert completed.count == 1 } ```
Now they can. The test keyword defines a test block with a name and a body. assert verifies conditions. flin test myapp/ runs all test files with an isolated database per test, parallel execution, and colored output. This closes the biggest gap for professional adoption.
Database Migrations (Completed)
When a developer adds a field to an entity, renames a field, or changes a type, existing data in FlinDB must be transformed safely. The migration system detects schema changes automatically:
$ flin migrate myapp/ --status
Pending migrations:
- Add field "email" (text) to User
- Rename field "name" -> "full_name" in User
- Change type of "age" from text to int in User$ flin migrate myapp/ Applied 3 migrations successfully. ```
The schema diff engine compares the current entity definitions with the persisted schema, generates migration steps, and applies them with value coercion (int-to-float, text-to-bool, etc.). Rollback support is included via flin migrate --rollback.
Additional Completed Items
- Caching layer. Two-level cache: automatic entity query caching with TTL-based invalidation, plus 5 native functions for manual cache control.
- Email templates. HTML email rendering with layouts, variables, and CSS inlining.
send_email_template(to, template, data)replaces manually constructed HTML emails. - Webhook support. Outgoing HTTP calls triggered by entity lifecycle events. Configurable in
flin.configwith HMAC-SHA256 signatures, exponential backoff retry, and a delivery log. - Stripe integration. 8 native functions for checkout sessions, customer management, subscriptions, invoices, and webhook verification.
- Image processing. 8 native functions for resize, crop, rotate, flip, thumbnail, convert, watermark, and info extraction.
- Structured logging. Log levels, JSON output, file rotation, and per-request logging. Production operators get structured, queryable logs instead of
console.lognoise. - Graceful shutdown. SIGTERM/SIGINT handlers with configurable connection draining timeout and WAL flush.
- Security headers. OWASP-recommended headers auto-injected in production mode, configurable via
flin.config.
Phase 3: Release Candidate (Planned)
Phase 3 is where FLIN moves from "works for early adopters" to "ready for production teams." The items are larger in scope and require deeper architectural work.
Plugin / Extension System
As the community grows, developers will build reusable components, entity patterns, middleware, and utilities. Without a package system, everyone reinvents the wheel.
The planned approach is deliberately minimal: a flin.modules directory convention where shared FLIN files are discovered automatically. No package registry, no version resolution algorithm, no dependency tree. The philosophy is that FLIN applications should be self-contained, and "packages" should be files you copy into your project.
Multi-File Projects and Imports
Today, each .flin file is independent. A large application needs to share entity definitions, utility functions, and components across files. The import system will be minimal -- no npm-style package resolution, no barrel files, no circular dependency resolution. A simple use "path/to/file" that brings names into scope.
Performance Optimization
The VM's bytecode interpreter is correct but not yet optimized. Planned work includes:
- Instruction fusion. Combining common instruction sequences (load + add + store) into single super-instructions.
- Inline caching. Memoizing property lookups on entities for repeated access patterns.
- Ahead-of-time compilation. Optional compilation to native code via LLVM or Cranelift for compute-intensive applications.
Self-Hosting
The ultimate milestone for any programming language: FLIN compiles itself. The compiler (currently 5,000+ lines of Rust) will be rewritten in FLIN, with only the ~5,000-line Rust runtime remaining. This is not a vanity goal -- self-hosting means that FLIN contributors can improve the compiler using FLIN, which dramatically lowers the contribution barrier.
The Numbers
A snapshot of FLIN's current state in numbers:
Metric Value
------ -----
Tests passing 3,452
Test failures 0
Built-in functions 409
Embedded UI components 180
Embedded icons (Lucide) 1,675
Keywords 42
Token types 60+
Compilation modes 5 (dev, check, build, emit-ast, emit-bytecode)
AI gateway providers 8
Storage backends 4 (Local, S3, R2, GCS)
OAuth providers 4 (Google, GitHub, Discord, Apple)
Stripe functions 8
Image processing functions 8
Sessions of development 336+
Lines of Rust (estimate) 50,000+The Timeline
We do not publish fixed dates because FLIN is developed by two people -- one human, one AI -- without external funding pressure or investor deadlines. What we publish is the sequence and the gating criteria.
Alpha 2 (current). Stable enough for developers to build and test applications locally. All Phase 1 and most Phase 2 features complete.
Beta. When the remaining Phase 2 items are complete and the testing framework is battle-tested by real applications. Estimated: Q2 2026.
Release Candidate. When the plugin system, multi-file imports, and performance optimizations are in place. Estimated: Q3 2026.
v1.0. When self-hosting is achieved and the language has been used to build at least three production applications (including internal ZeroSuite products). Estimated: Q4 2026.
The gating criterion for v1.0 is not a feature list. It is confidence. When a developer can build a real application, test it thoroughly, deploy it to production, and maintain it over months without hitting a wall that requires dropping down to another language -- that is v1.0.
What Developers Can Do Today
FLIN alpha 2 is usable today for:
- Personal projects and prototypes. The developer experience is polished enough for rapid experimentation.
- Internal tools. Business dashboards, admin panels, and CRUD applications where the controlled environment mitigates alpha-stage risks.
- Learning and exploration. Understanding FLIN's programming model and providing feedback that shapes the language before v1.0 solidifies the API.
FLIN alpha 2 is not yet recommended for:
- Production applications serving external users. The API surface may change between alpha and v1.0.
- Applications requiring JavaScript library interop. The ecosystem is self-contained; escape hatches to npm do not exist.
- High-scale applications. Performance optimization is Phase 3 work.
Contributing
FLIN's Rust runtime is open for contributions. The codebase is structured for readability: each module owns one domain, tests live next to implementation, and the compilation pipeline is linear (lexer feeds parser feeds type checker feeds code generator).
git clone https://github.com/flin-lang/flin
cd flin
cargo build --release
cargo test3,452 tests. Zero failures. If your contribution adds a feature, add tests. If your contribution fixes a bug, add a test that would have caught it. The bar for merging is: cargo test passes, cargo clippy -D warnings is clean, and the code is clear enough that the next contributor can understand it without comments.
---
Next in the series: Building a Programming Language From Abidjan, Cote d'Ivoire -- The most ambitious programming language project of 2026 did not come from San Francisco. It came from a desk in Abidjan with a $200/month budget.