TL;DR — Fitz es un lenguaje de programación nuevo, escrito en Rust, con compilador de tipado gradual. La premisa: en lugar de apilar FastAPI + SQLAlchemy + python-jose + Celery + Pydantic + uvicorn + Alembic + typer sobre Python, lo que cada una resuelve vive adentro del lenguaje: ruteo HTTP, generación de OpenAPI/AsyncAPI, async/await, autenticación con JWT, hashing de passwords, un ORM con driver Postgres escrito en Rust puro, migraciones de schema, WebSockets, cron, jobs en background, un CLI builder, healthchecks, observability con OpenTelemetry, secrets como tipos opacos, y un orquestador fitz deploy. Un solo binario. Cero deps externas para el stack core. Repo: github.com/Thegreekman76/fitz · Docs: thegreekman76.github.io/fitz

Hace años que vengo escribiendo APIs en Python — FastAPI más el elenco habitual: SQLAlchemy, python-jose para JWT, passlib para Argon2, Celery + Redis para jobs, Pydantic para validación, uvicorn para servir, alembic para migraciones. Cada API que entrego necesita más o menos las mismas nueve librerías, cada una con sus convenciones, sus breaking changes, su forma de integrarse con el resto.

En algún momento me hice la pregunta obvia: ¿por qué no es esto el lenguaje y listo?

Esa pregunta es Fitz.

Cómo se ve Fitz

Empecemos por la foto, después caminamos las piezas.

@server(43928)
fn main() => 0

type User { id: Int, email: Str, name: Str, role: Str }
type Credentials { email: Str, password: Str }
type LoginResponse { token: Str }

let SECRET = "demo-secret-cambiame-en-prod"
let ADA_HASH = hash.password("secret-ada-123")

@auth_provider
fn check_token(headers: Map<Str, Str>) -> Result<User> {
    let auth: Str = match headers.get("authorization") {
        Ok(v) => v,
        Err(_) => return Err("falta header Authorization"),
    }
    let parts = auth.split(" ")
    if (parts.len() != 2 or parts[0] != "Bearer") {
        return Err("se esperaba 'Bearer <token>'")
    }
    let claims = jwt.decode(parts[1], SECRET)?
    return find_user(claims["email"])
}

@post("/login")
fn login(creds: Credentials) -> LoginResponse {
    let user: User = match find_user(creds.email) {
        Ok(u) => u,
        Err(_) => return 401 { "error": "credenciales inválidas" },
    }
    if (not hash.verify(creds.password, ADA_HASH)) {
        return 401 { "error": "credenciales inválidas" }
    }
    let claims = { "email": user.email, "role": user.role }
    return LoginResponse { token: jwt.encode(claims, SECRET) }
}

@authenticated
@get("/me")
fn me(user: User) -> User => user

@admin
@get("/admin/users")
fn admin_list(user: User) -> List<User> { ... }

Lo que hace este código, sin un solo import ni una dependencia externa:

• Levanta un servidor HTTP en el puerto 43928.

• Genera OpenAPI 3.1 automático en /openapi.json.

• Sirve la UI de Scalar en /docs con botón "Authorize" funcional.

• Firma y verifica JWT (HS256/384/512).

• Hashea passwords con Argon2id (recomendación de OWASP, no bcrypt).

• Valida estáticamente que cada @authenticated/@admin tenga un @auth_provider declarado, que el provider devuelva el tipo User correcto, y que los handlers @admin tengan un campo role: Str en el User.

• Compila a un binario nativo con fitz build, con paridad bit-a-bit contra fitz run.

La auth, el hashing, el JWT, el OpenAPI con el security scheme bearerAuth, las respuestas 401/403 — todo eso vive adentro del binario fitz. No hay requirements.txt, no hay package.json, no hay Cargo.toml del lado del usuario.

Por qué "ciudadano de primera" importa

"Ciudadano de primera clase" es una de esas frases que se gastan rápido. Lo digo concreto.

En FastAPI, @app.get("/users") es un método sobre una instancia. El framework es una librería de la cual hacés opt-in. El router es una estructura de datos Python. La autenticación es un Depends(...). Nada de eso es visible para el type checker como algo especial — son simplemente llamadas a funciones y decoradores que producen metadata.

En Fitz, @get("/users") es un decorador que el compilador entiende. El checker valida el template del path, los tipos de los parámetros contra los path params, el tipo del body, el tipo de retorno. El generador de OpenAPI inspecciona el AST directamente — no introspeciona objetos de runtime, no necesita decoradores que se "registren" a sí mismos. El User que devolvés en tu handler es el mismo User que aparece en el schema generado y en la UI de Scalar.

Suena chico hasta que lo vivís una semana. Después dejás de pelear con "por qué Pydantic discrepa con SQLAlchemy sobre si este campo es opcional" y empezás a escribir endpoints.

Las piezas

HTTP + OpenAPI + UI Scalar, todo automático

type Post { id: Int, title: Str, body: Str, tags: List<Str> }

@get("/posts")
fn list_posts() -> List<Post> { ... }

@post("/posts")
fn create_post(post: Post) -> Post { ... }

Eso es todo lo que necesitás. /openapi.json y /docs (Scalar) aparecen solos. Path params (/posts/{id}) son tipados y coercionados. La deserialización del JSON del body chequea required, aplica defaults, valida nullables, rechaza campos extra. Podés desactivar con @server(docs=false).

WebSockets tipados, con AsyncAPI auto-generado

type ChatMessage { from: Str, text: Str }

@server(43929, ws_heartbeat_secs=30)
fn main() => 0

@authenticated
@ws("/chat")
async fn chat(conn: WsConn<ChatMessage>, user: User) {
    loop {
        let msg = match conn.recv() {
            Ok(m) => m,
            Err(_) => break,
        }
        conn.broadcast(ChatMessage { from: user.name, text: msg.text })
    }
}

Cada frame se marshallea automáticamente desde y hacia el tipo declarado. La auth corre antes del upgrade WebSocket — token inválido devuelve 401 sin abrir el socket. El heartbeat con ping/pong mantiene la conexión viva más allá de los 60s default de Nginx. /asyncapi.json se genera solo (la spec hermana de OpenAPI para APIs event-driven). No conozco otro lenguaje que auto-genere AsyncAPI desde el código fuente tipado.

Jobs en background y cron, sin Redis

@cron("*/5 * * * *")
async fn cleanup_old_sessions() {
    db.exec("DELETE FROM sessions WHERE expires_at < now()")
}

@background
async fn send_welcome_email(email: Str) {
    // cosa cara
}

@post("/signup")
fn signup(creds: Credentials) -> User {
    let user = create_user(creds)
    spawn(send_welcome_email(user.email))  // fire-and-forget, Future<Null> tipado
    return user
}

Sin Celery. Sin Redis. Sin celery worker -A app corriendo al lado del uvicorn. El scheduler está en tu binario. Suficiente para el 90% de servicios — cuando lo superás, lo superás por una razón concreta, y eso es problema de Fase 11+.

Un ORM nativo con driver Postgres en Rust puro

Esta es la pieza de la que más orgulloso estoy, y la que más tiempo me llevó. Fitz tiene su propio driver de Postgres escrito en Rust — sin libpq, sin tokio-postgres, sin sqlx. El protocolo wire (v3.0), auth SCRAM-SHA-256, prepared statements, formato binario para 11 tipos OID — todo implementado desde el RFC.

@table("users")
type User {
    @primary id: Int,
    email: Str,
    name: Str,
    @has_many("Post", "user_id") posts: List<Post>,
}

@table("posts")
type Post {
    @primary id: Int,
    user_id: Int,
    title: Str,
    body: Str,
    @belongs_to user: User?,
}

@get("/users")
async fn list_users(db: DbConn) -> List<User> {
    return User.all(db).preload("posts").await
}

@get("/users/{id}")
async fn get_user(db: DbConn, id: Int) -> Result<User> {
    return User.where(fn(u) => u.id == id).first(db).await
}

@post("/users")
async fn create_user(db: DbConn, user: User) -> User {
    return User.insert(db, user).await
}

La closure adentro de .where(...) se traduce a SQL parametrizado en tiempo de compilación — fn(u) => u.id == id se convierte en WHERE id = $1. Operadores como .is_in([...]), .like(...), .ilike(...), .contains(...), más operadores JSONB como .has_key(...), .contains_json(...) mapean a operadores nativos de Postgres. El eager loading con .preload("posts") dispara una sola query batched. Agregados (.sum/.avg/.min/.max/.count) y GROUP BY están soportados a través de un tipo separado Aggregated<Row>.

Esto compila a código nativo vía fitz build. El binario generado hace exactamente las mismas calls a Postgres. Cero overhead de runtime para el SQL — ya es constante en build-time, comparable en performance con Diesel o sqlx.

¿Cuán rápido es de verdad? — cabeza-a-cabeza contra SQLAlchemy

La promesa "cero overhead" es fácil de decir y fácil de inflar, así que el repo trae un bench reproducible entre dos boilerplates equivalentes (api-postgres-fitz vs api-postgres-python) — mismo Postgres, mismos endpoints, mismo shape de respuesta, mismo docker compose. Números headline en v0.10.13 (Intel Core Ultra 7 155H, Docker 29.2.1, 30s sostenidos, concurrencia 10):

Eso es 8× el throughput con ~5× menos memoria, en la misma máquina, sobre la misma red Docker, contra el mismo Postgres. Reproducí los números con bash benchmarks/orm-vs-sqlalchemy/run.sh (5–8 min con cache Docker caliente; requiere oha + jq). Metodología completa, output crudo y las partes donde la comparación es injusta para Fitz están en el README del bench.

Interop con Python cuando lo necesitás

from python import math, json

let radius = 5.0
let area: Float = math.pi * radius * radius

let parsed: Result<Map<Str, Any>> = match json.loads("{\"name\": \"ada\"}") {
    Ok(d) => Ok(d),
    Err(e) => Err("JSON malformado: {e}"),
}

SQLAlchemy, NumPy, pandas, lo que esté en PyPI — accesible desde Fitz con from python import .... El runtime embebe CPython vía PyO3. Las excepciones Python se vuelven Result::Err automáticamente. Async Python (asyncpg, SQLAlchemy 2.x async) se bridgea al .await de Fitz transparente. Incluso podés hacer fitz build --bundle-python para entregar un binario con CPython embebido — no se necesita Python en la máquina destino.

Esto es intencional. Fitz no quiere reemplazar el ecosistema de Python — quiere darte un lenguaje mejor para la capa web mientras dejás abierta la puerta a todo lo que Python ya construyó.

Async, finalmente sin color

async fn fetch_user(id: Int) -> Result<User> { ... }

async fn main() {
    let user = fetch_user(42).await?
    print("llegó {user.name}")
}

async/await en el core, sobre runtime tokio. El operador ? funciona a través de Result<T>. El type checker exige que ? solo aparezca adentro de funciones que retornan Result<...>. Compila a async fn + .await en Rust — mismo modelo de ejecución, mismo executor multi-thread.

CLI builder — el mismo lenguaje, herramientas de línea de comandos

Fitz no es solo para servicios HTTP. El mismo compilador trae un CLI builder built-in, sin librerías:

@command("greet", desc="Saludar a una persona")
fn greet(name: Str, loud: Bool = false, count: Int = 1) -> Int {
    let n = count
    while n > 0 {
        if loud { print("HOLA, {name}!") } else { print("hola, {name}") }
        n = n - 1
    }
    return 0
}

@command("add", desc="Sumar dos números")
fn add(a: Int, b: Int) -> Int {
    print("{a + b}")
    return 0
}

$ ./mybin greet Ada --loud --count 3
HOLA, Ada!
HOLA, Ada!
HOLA, Ada!

$ ./mybin --help
USAGE: mybin <command> [ARGS] [OPTIONS]
COMMANDS:
    greet    Saludar a una persona
    add      Sumar dos números

Convención sobre decoración: params sin default son positional args, params con default son flags. Bool con default = false se vuelve --flag, otros tipos --flag <value>. Short flags auto-derivados (--loud → -l) con detección de conflictos. Help auto-generado, exit codes POSIX estándar. Paridad bit-a-bit entre fitz run (desarrollo) y fitz build (binario self-contained que dropeás en /usr/local/bin).

Es el mismo lenguaje. Mismo type checker. Mismo async/await. Mismo Result<T> para errores. Si tu herramienta necesita pegar a la DB, el ORM está ahí. Si necesita HTTP, @get/@post están ahí. La línea entre "servicio web" y "CLI tool" deja de ser una decisión de stack.

Stack production-ready — del repo a producción

Esto es lo que separa a Fitz de los lenguajes "prototipo interesante". Los servicios reales necesitan health checks, secrets, observability, y una forma de shippear. Todo eso es parte del lenguaje:

@server(43928)
fn main() => 0

// Auto-montados en GET /healthz y /readyz — Kubernetes-friendly.
@healthz
fn liveness() -> Bool => true

@readyz
async fn readiness(db: DbConn) -> Bool {
    return match db.exec("SELECT 1").await {
        Ok(_) => true,
        Err(_) => false,
    }
}

// Secret<T> nunca leakea a logs, imprime "***" en Display.
let db_url: Secret<Str> = secret("DATABASE_URL")
let log_level: Str = config("LOG_LEVEL", "info")

// Tracing + métricas con un decorador cada uno.
@trace(name="process_order")
@metric(name="orders")
async fn process(order: Order) -> Result<Receipt> {
    // process_order_duration_seconds (histogram) y orders_calls_total
    // (counter) se populan automático al hacer drop del scope.
}

// Feature flags con dos fuentes: fitz.toml [flags] + env vars FITZ_FLAG_<NAME>.
@flag("new-checkout")
@post("/v2/checkout")
fn v2_checkout(body: Cart) -> Receipt { ... }

Atrás de bambalinas:

• HTTP access logs auto-emitidos con trace_id/span_id propagado a cada log.info(...) adentro del handler.

• Export OpenTelemetry OTLP con un solo env var: OTEL_EXPORTER_OTLP_ENDPOINT. Los spans fluyen a Jaeger/Tempo/Honeycomb. Sin el env var, cero overhead, cero llamadas de red.

• Endpoint /metrics Prometheus expone counters y histogramas — @server(prometheus=true) lo activa.

• @flag sobre handlers HTTP/WS retorna 404 cuando la flag está off — gate del hot path ANTES de middleware/auth.

Deployando:

# Genera Dockerfile + docker-compose.yml a partir del shape del programa.
fitz docker init

# Build del binario, build de imagen Docker, push al registry.
fitz deploy docker --tag mycorp/api:v1

# O levantá local con compose.
fitz deploy compose

fitz docker init lee tu AST. Si hay db.connect(...), agrega Postgres al compose. Si hay @server(N), setea EXPOSE N. Si hay @cron, agrega restart: unless-stopped. Si hay from python import ..., elige python:3.12-slim-bookworm en lugar de distroless. Genera lo que vos escribirías a mano, lo commiteás, lo editás cuando lo necesites.

No conozco otro lenguaje donde deployment sea una feature del lenguaje. Acá lo es porque cada proyecto que entregué en Python terminaba con dos días debuggeando gotchas del Dockerfile.

Las herramientas

Esta es la parte que subestimé cuando arranqué. Un lenguaje sin buenas herramientas nace muerto. Acá lo que hay hoy:

• fitz run — interpreta el archivo directo. El ciclo de feedback más rápido.

• fitz build — compila a binario nativo vía un proyecto Rust generado. La paridad bit-a-bit con fitz run es un requisito duro.

• fitz check — solo type checker, sin ejecución.

• fitz test — test runner built-in con decorador @test y assert, assert_eq, assert_throws. Output estilo cargo.

• fitz dev — hot reload. Watchea *.fitz y fitz.toml, mata y respawnea el child al cambio.

• fitz fmt — formatter opinionado, cero config. Preserva tus comentarios y líneas en blanco.

• fitz lint — 4 lints built-in con supresión // @allow(<nombre>). Output estilo cargo-clippy.

• fitz repl — REPL interactivo con soporte multi-línea, :type, :load, historial persistente.

• fitz openapi — emite el schema OpenAPI sin levantar el server.

• fitz db diff/migrate — tooling de migraciones de schema. Diff entre la DB viva y los types @table en tu código, genera migraciones idempotentes, las aplicás con fitz db migrate. Mismo modelo que Alembic pero con los types como fuente de verdad.

• fitz docker init/build — genera el Dockerfile + .dockerignore + docker-compose.yml a partir del shape del programa, después docker build wrappeado.

• fitz deploy docker/compose — wrapper fino para shippear la imagen o levantar local con un solo comando.

• Extensión VSCode — diagnostics + hover + go-to-definition + autocomplete + signature help + format on save + inferencia bidireccional para callbacks, distribución multi-platform.

• fitz new + fitz add + fitz remove + fitz update — package manager con fitz.toml, lockfile, path deps, git deps.

El LSP es real (tower-lsp adentro). El formatter es real (tu código hace round-trip por él). El test runner es real. Todo está dogfooded — escribo código Fitz con la misma extensión VSCode que entrego.

Siendo honesto sobre el estado

Esto es un proyecto de un solo desarrollador. Empecé aprendiendo Rust para construirlo. No voy a fingir que está listo para producción para cualquiera — esto es lo verdadero hoy (junio 2026, release v0.15.0):

Lo que funciona end-to-end, con paridad bit-a-bit fitz run ↔ fitz build:

• Server HTTP con @get/@post/@put/@delete, OpenAPI auto, UI Scalar.

• Chain de middleware con @middleware(fn) + CORS built-in.

• Auth con JWT con @auth_provider/@authenticated/@admin + @requires("role_custom") para RBAC. Hashing de passwords con Argon2id. Token blacklist sobre Postgres para logout/refresh.

• WebSockets con WsConn<T>, AsyncAPI auto, heartbeat, auth pre-upgrade.

• Cron jobs con @cron("expr") (con retry, timezone, persistencia, catch-up), jobs background con @background + spawn(...).

• ORM Postgres con @table/@primary/@column/@belongs_to/@has_many, closure-to-SQL, eager loading, transacciones (db.transaction(fn)), migraciones de schema (fitz db diff/migrate).

• TLS estricto para Postgres (sslmode=require).

• Async/await sobre tokio.

• Interop Python con from python import ..., incluyendo bridge automático para async.

• CLI builder con @command — mismo lenguaje para CLI tools.

• Stack production: @healthz/@readyz, Secret<T>, secret()/config(), @trace/@metric, @flag, export OpenTelemetry OTLP, endpoint Prometheus /metrics, fitz docker init/build, fitz deploy.

• Package manager con path deps y git deps.

• Tooling completo: LSP (con signature help, format on save, hover sobre params y bindings), fmt, test, dev, repl, lint.

Lo que todavía no está en la caja:

• Frontend en .fitz (single-file components, SSR). Roadmap (Fase 11) — la apuesta más ambiciosa del proyecto. Sin arrancar.

• Un registry público de paquetes. Path deps y git deps funcionan hoy; el registry está en pausa hasta que aparezca demanda real.

• Targets de fitz deploy más allá de docker/compose (todavía no hay wrapper de fly/railway/k8s — usá los CLIs nativos).

• Debugging interactivo en VSCode (Debug Adapter Protocol). Workarounds: print, REPL :type/:env, diagnostics LSP. Trackeado como V6 en el backlog.

Lo que es estable: ~3030 tests unit de Rust + 13 LSP E2E + 360 compile E2E (smoke sobre cada ejemplo de la guía) + ~140 más entre otras suites corriendo en CI en cada push. Clippy -D warnings limpio.

Cómo probarlo

# Instalación en Linux / macOS / WSL
curl -sSf https://thegreekman76.github.io/fitz/install.sh | sh

# Instalación en Windows (PowerShell)
irm https://thegreekman76.github.io/fitz/install.ps1 | iex

# O bajá un binario desde GitHub
# https://github.com/Thegreekman76/fitz/releases

# Reabrí la terminal para que el cambio de PATH aplique, después:
fitz --version

Extensión VSCode (recomendado — syntax highlighting, hover con tipos, autocomplete, signature help, format on save): bajá el .vsix de tu plataforma desde la misma página de releases (fitz-lang-<plataforma>.vsix) e instalala con code --install-extension fitz-lang-<plataforma>.vsix --force. El Language Server viene incluido — no hace falta instalarlo aparte. Recargá VSCode una vez.

Primer server:

fitz new mi-api --http
cd mi-api
fitz dev

Vienen ocho boilerplates en el repo bajo boilerplates/:

• api-simple — API HTTP mínima.

• api-middleware-cors — chain de middleware + config de CORS.

• api-postgres-fitz — ORM + Postgres, Dockerizado.

• api-postgres-python — Postgres vía interop Python/SQLAlchemy.

• api-websocket — chat WebSocket tipado.

• api-orm-full — el showcase completo: auth + ORM + WebSockets + cron + jobs.

• api-fullstack-postgres — backend + frontend mínimo en un binario.

• cli-tool — app CLI con @command (sin HTTP).

Cada uno corre con docker compose up o fitz dev. El README tiene la matriz completa.

Por qué construí esto

Vivo en El Chaltén, en la Patagonia argentina. El Fitz Roy es la torre de granito que define el horizonte acá. Borges escribió que vivimos en un país donde el pasado es incierto y solo el futuro es real. Creo que también vale para los lenguajes de programación: el pasado está lleno de workarounds acumulados por features que faltan en el lenguaje, y el futuro es lo que vos decidís construir.

Llevo diez años escribiendo código de APIs en Python. Amo FastAPI. Pero cada vez que arranco un proyecto nuevo, las primeras tres horas se van pegando librerías para hacer lo mismo que hice la semana pasada. En algún punto la pregunta se vuelve: ¿cómo sería un lenguaje que arrancara desde este conjunto de necesidades en 2026, en lugar de hacerlas crecer como parches sobre un lenguaje diseñado para scripting de shell en 1991?

Eso es Fitz.

No está terminado. Soy uno solo. Va a llegar.

Repo: github.com/Thegreekman76/fitz

Docs y curso: thegreekman76.github.io/fitz

Guía (34 capítulos): thegreekman76.github.io/fitz/guide/

Roadmap: docs/roadmap.md

CHANGELOG: CHANGELOG.md — cada release con detalle.

Issues: github.com/Thegreekman76/fitz/issues

Si lo probás, quiero saber qué se rompió. Abrí un issue o una discussion en GitHub.

I've been building web APIs in Python for years — FastAPI plus the usual cast: SQLAlchemy, python-jose for JWT, passlib for Argon2, Celery + Redis for background jobs, Pydantic for validation, uvicorn for serving, alembic for migrations. Every API I ship needs roughly the same nine libraries, each with its own conventions, its own breaking changes, its own way to integrate with the others.

At some point I asked myself the obvious question: why isn't this just the language?

That question is Fitz.

What Fitz looks like

Let's start with the picture, then walk through the pieces.

@server(43928)
fn main() => 0

type User { id: Int, email: Str, name: Str, role: Str }
type Credentials { email: Str, password: Str }
type LoginResponse { token: Str }

let SECRET = "demo-secret-change-me-in-prod"
let ADA_HASH = hash.password("secret-ada-123")

@auth_provider
fn check_token(headers: Map<Str, Str>) -> Result<User> {
    let auth: Str = match headers.get("authorization") {
        Ok(v) => v,
        Err(_) => return Err("missing Authorization header"),
    }
    let parts = auth.split(" ")
    if (parts.len() != 2 or parts[0] != "Bearer") {
        return Err("expected 'Bearer <token>'")
    }
    let claims = jwt.decode(parts[1], SECRET)?
    return find_user(claims["email"])
}

@post("/login")
fn login(creds: Credentials) -> LoginResponse {
    let user: User = match find_user(creds.email) {
        Ok(u) => u,
        Err(_) => return 401 { "error": "invalid credentials" },
    }
    if (not hash.verify(creds.password, ADA_HASH)) {
        return 401 { "error": "invalid credentials" }
    }
    let claims = { "email": user.email, "role": user.role }
    return LoginResponse { token: jwt.encode(claims, SECRET) }
}

@authenticated
@get("/me")
fn me(user: User) -> User => user

@admin
@get("/admin/users")
fn admin_list(user: User) -> List<User> { ... }

What this code does, without a single import or external dependency:

• Starts an HTTP server on port 43928.

• Auto-generates OpenAPI 3.1 at /openapi.json.

• Auto-serves Scalar UI at /docs with a working "Authorize" button.

• Signs and verifies JWT tokens (HS256/384/512 supported).

• Hashes passwords with Argon2id (OWASP recommendation, not bcrypt).

• Statically validates that every @authenticated/@admin handler has an @auth_provider declared, that the provider returns the right User type, and that @admin handlers have a role: Str field on the User.

• Compiles to a single native binary with fitz build, with bit-for-bit parity against fitz run.

The auth, the hashing, the JWT, the OpenAPI with bearerAuth security scheme, the 401/403 responses — all of that is in the binary fitz itself. There's no requirements.txt, no package.json, no Cargo.toml for the user.

Why "first-class" matters

"First-class citizen" is one of those phrases that gets thrown around. Here's what I mean concretely.

In FastAPI, @app.get("/users") is a method on an object instance. The framework is a library you opt into. The router is a Python data structure. Authentication is a Depends(...). None of those things are visible to the type checker as anything special — they're just function calls and decorators that happen to produce metadata.

In Fitz, @get("/users") is a decorator the compiler understands. The checker validates the path template, the parameter types against the path params, the body type, the return type. The OpenAPI generator inspects the AST directly — it doesn't introspect runtime objects, it doesn't need decorators that "register" themselves. The User you return in your handler is the same User that appears in the generated schema and in the Scalar UI.

This sounds like a small distinction until you live it for a week. Then you stop fighting "why does Pydantic disagree with SQLAlchemy about whether this field is optional" and you start writing endpoints.

The pieces

HTTP + OpenAPI + Scalar UI, all auto

type Post { id: Int, title: Str, body: Str, tags: List<Str> }

@get("/posts")
fn list_posts() -> List<Post> { ... }

@post("/posts")
fn create_post(post: Post) -> Post { ... }

That's all you need. /openapi.json and /docs (Scalar UI) appear automatically. Path params (/posts/{id}) are typed and coerced. JSON body deserialization checks for missing required fields, applies defaults, validates nullables, rejects extras. You can opt out with @server(docs=false).

WebSockets, typed, with AsyncAPI auto-generated

type ChatMessage { from: Str, text: Str }

@server(43929, ws_heartbeat_secs=30)
fn main() => 0

@authenticated
@ws("/chat")
async fn chat(conn: WsConn<ChatMessage>, user: User) {
    loop {
        let msg = match conn.recv() {
            Ok(m) => m,
            Err(_) => break,
        }
        conn.broadcast(ChatMessage { from: user.name, text: msg.text })
    }
}

Every frame is auto-marshalled to and from the declared type. Auth runs before the WebSocket upgrade — invalid token gets a 401 without ever opening the socket. Ping/pong heartbeat keeps the connection alive past Nginx's 60s default. /asyncapi.json is generated automatically (the event-driven sibling of OpenAPI). I don't know of another language that auto-generates AsyncAPI from typed source.

Background jobs and cron, no Redis required

@cron("*/5 * * * *")
async fn cleanup_old_sessions() {
    db.exec("DELETE FROM sessions WHERE expires_at < now()")
}

@background
async fn send_welcome_email(email: Str) {
    // expensive thing
}

@post("/signup")
fn signup(creds: Credentials) -> User {
    let user = create_user(creds)
    spawn(send_welcome_email(user.email))  // fire-and-forget, typed Future<Null>
    return user
}

No Celery. No Redis. No celery worker -A app next to your uvicorn process. The scheduler is in your binary. Suitable for 90% of services — when you outgrow it, you outgrow it for a reason, and that's a Fase 11+ problem.

A native ORM with a pure-Rust Postgres driver

This is the piece I'm most proud of, and the one that took the longest. Fitz has its own Postgres driver written in Rust — no libpq, no tokio-postgres, no sqlx. The wire protocol (v3.0), SCRAM-SHA-256 auth, prepared statements, the binary format for 11 OID types — all implemented from the RFC.

@table("users")
type User {
    @primary id: Int,
    email: Str,
    name: Str,
    @has_many("Post", "user_id") posts: List<Post>,
}

@table("posts")
type Post {
    @primary id: Int,
    user_id: Int,
    title: Str,
    body: Str,
    @belongs_to user: User?,
}

@get("/users")
async fn list_users(db: DbConn) -> List<User> {
    return User.all(db).preload("posts").await
}

@get("/users/{id}")
async fn get_user(db: DbConn, id: Int) -> Result<User> {
    return User.where(fn(u) => u.id == id).first(db).await
}

@post("/users")
async fn create_user(db: DbConn, user: User) -> User {
    return User.insert(db, user).await
}

The closure inside .where(...) is translated to parametrized SQL at compile time — fn(u) => u.id == id becomes WHERE id = $1. Operators like .is_in([...]), .like(...), .ilike(...), .contains(...), plus JSONB operators like .has_key(...), .contains_json(...) all map to native Postgres operators. Eager loading with .preload("posts") issues a single batched query. Aggregates (.sum/.avg/.min/.max/.count) and GROUP BY are supported through a separate Aggregated<Row> type.

This compiles to native code via fitz build. The generated binary makes the same Postgres calls. Zero overhead at runtime for the SQL — it's already constant by the time the binary runs, comparable in performance to Diesel or sqlx.

How fast is it really? — head-to-head against SQLAlchemy

The "zero overhead" claim is easy to make and easy to fake, so the repo ships a reproducible bench between two equivalent boilerplates (api-postgres-fitz vs api-postgres-python) — same Postgres, same endpoints, same response shape, same docker compose. Headline numbers on v0.10.13 (Intel Core Ultra 7 155H, Docker 29.2.1, 30s sustained, concurrency 10):

That's 8× the throughput at ~5× less memory, on the same machine, in the same Docker network, against the same Postgres. Reproduce with bash benchmarks/orm-vs-sqlalchemy/run.sh (5–8 min with hot Docker cache; needs oha + jq). Full methodology, raw output, and the parts where the comparison is unfair to Fitz live in the bench README.

Python interop when you do need it

from python import math, json

let radius = 5.0
let area: Float = math.pi * radius * radius

let parsed: Result<Map<Str, Any>> = match json.loads("{\"name\": \"ada\"}") {
    Ok(d) => Ok(d),
    Err(e) => Err("malformed JSON: {e}"),
}

SQLAlchemy, NumPy, pandas, anything on PyPI — accessible from Fitz with from python import .... The runtime embeds CPython via PyO3. Python exceptions become Result::Err automatically. Async Python (asyncpg, SQLAlchemy 2.x async) bridges to Fitz's .await transparently. You can even do fitz build --bundle-python to ship a binary with CPython embedded — no Python required on the destination machine.

This is intentional. Fitz isn't trying to replace Python's ecosystem — it's trying to give you a better language for the web layer while keeping the door open to everything Python has already built.

Async, finally without color

async fn fetch_user(id: Int) -> Result<User> { ... }

async fn main() {
    let user = fetch_user(42).await?
    print("got {user.name}")
}

async/await is in the core, on a tokio runtime. The ? operator works through Result<T>. The type checker enforces that ? only appears inside functions that return Result<...>. Compiles to async fn + .await in Rust — same execution model as Rust async, same multi-threaded executor.

CLI builder — same language, command-line tools

Fitz isn't only for HTTP services. The same compiler ships a built-in CLI builder, no library needed:

@command("greet", desc="Greet a person")
fn greet(name: Str, loud: Bool = false, count: Int = 1) -> Int {
    let n = count
    while n > 0 {
        if loud { print("HELLO, {name}!") } else { print("hello, {name}") }
        n = n - 1
    }
    return 0
}

@command("add", desc="Sum two numbers")
fn add(a: Int, b: Int) -> Int {
    print("{a + b}")
    return 0
}

$ ./mybin greet Ada --loud --count 3
HELLO, Ada!
HELLO, Ada!
HELLO, Ada!

$ ./mybin --help
USAGE: mybin <command> [ARGS] [OPTIONS]
COMMANDS:
    greet    Greet a person
    add      Sum two numbers

Convention over decoration: params without defaults are positional args, params with defaults are flags. Bool with default = false becomes --flag, other types become --flag <value>. Short flags auto-derive (--loud → -l) with conflict detection. Help auto-generated, exit codes POSIX standard. Bit-for-bit parity between fitz run (development) and fitz build (a self-contained binary you can drop into /usr/local/bin).

This is the same language. Same type checker. Same async/await. Same Result<T> for errors. If your tool needs to hit the database, the ORM is there. If it needs HTTP, @get/@post are there. The line between "web service" and "CLI tool" stops being a stack decision.

Production-ready stack — from repo to production

This is what separates Fitz from "interesting prototype" languages. Real services need health checks, secrets, observability, and a way to ship. All of them are part of the language:

@server(43928)
fn main() => 0

// Auto-mounted at GET /healthz and /readyz — Kubernetes-friendly.
@healthz
fn liveness() -> Bool => true

@readyz
async fn readiness(db: DbConn) -> Bool {
    return match db.exec("SELECT 1").await {
        Ok(_) => true,
        Err(_) => false,
    }
}

// Secret<T> never leaks to logs, prints "***" on Display.
let db_url: Secret<Str> = secret("DATABASE_URL")
let log_level: Str = config("LOG_LEVEL", "info")

// Tracing + metrics with one decorator each.
@trace(name="process_order")
@metric(name="orders")
async fn process(order: Order) -> Result<Receipt> {
    // process_order_duration_seconds (histogram) and orders_calls_total
    // (counter) populate automatically on drop.
}

// Feature flags with two sources: fitz.toml [flags] + FITZ_FLAG_<NAME> env vars.
@flag("new-checkout")
@post("/v2/checkout")
fn v2_checkout(body: Cart) -> Receipt { ... }

Behind the scenes:

• HTTP access logs auto-emit with trace_id/span_id propagated to every log.info(...) inside the handler.

• OpenTelemetry OTLP export with one env var: OTEL_EXPORTER_OTLP_ENDPOINT. Spans flow to Jaeger/Tempo/Honeycomb. Without the env var, zero overhead, zero network calls.

• Prometheus /metrics endpoint exposes counters and histograms — @server(prometheus=true) enables.

• @flag on HTTP/WS handlers returns 404 when the flag is off — gate the hot path before middleware/auth.

Deploying:

# Generate the Dockerfile + docker-compose.yml from the program shape.
fitz docker init

# Build the binary, the Docker image, push to a registry.
fitz deploy docker --tag mycorp/api:v1

# Or bring up locally with compose.
fitz deploy compose

fitz docker init reads your AST. If there's a db.connect(...), it adds Postgres to the compose. If there's @server(N), it sets EXPOSE N. If there's @cron, it adds restart: unless-stopped. If there's from python import ..., it picks python:3.12-slim-bookworm instead of distroless. It generates what you'd write by hand, you commit it, edit when you need to.

I'm not aware of another language where deployment is a language feature. It is here because every project I shipped in Python ended with two days of debugging Dockerfile gotchas.

What's the tooling like?

This is the part I underestimated when I started. A language without good tools is dead on arrival. Here's the current state:

• fitz run — interpret the file directly. Fastest feedback loop.

• fitz build — compile to a native binary via a generated Rust project. Bit-for-bit parity with fitz run is a hard requirement.

• fitz check — type checker only, no execution.

• fitz test — built-in test runner with @test decorator and assert, assert_eq, assert_throws. Cargo-style output.

• fitz dev — hot reload. Watches *.fitz and fitz.toml, kills and respawns the child on change.

• fitz fmt — opinionated formatter, zero config. Preserves your comments and blank lines.

• fitz lint — 4 built-in lints with // @allow(<name>) suppression. Cargo-clippy-style output.

• fitz repl — interactive REPL with multi-line support, :type, :load, persistent history.

• fitz openapi — emit the OpenAPI schema without running the server.

• fitz db diff/migrate — schema migration tooling. Diff the live DB against the @table types in your code, generate idempotent migrations, apply them with fitz db migrate. Same model as Alembic but with the types as source of truth.

• fitz docker init/build — generate the Dockerfile + .dockerignore + docker-compose.yml from the program shape, then docker build wrapped.

• fitz deploy docker/compose — thin wrapper to ship the image or bring up locally with one command.

• VSCode extension — diagnostics + hover + go-to-definition + autocomplete + signature help + format on save + bidirectional type inference for callbacks, multi-platform distribution.

• fitz new + fitz add + fitz remove + fitz update — package manager with fitz.toml, lockfile, path deps, git deps.

The LSP is real (tower-lsp under the hood). The formatter is real (your code round-trips through it). The test runner is real. The whole thing is dogfooded — I write Fitz code with the same VSCode extension I ship.

Being honest about state

This is a one-developer project. I started learning Rust to build it. I'm not going to pretend it's production-ready for everyone — here's what's true today (June 2026, release v0.15.0):

What works end-to-end, with bit-for-bit fitz run ↔ fitz build parity:

• HTTP server with @get/@post/@put/@delete, OpenAPI auto, Scalar UI.

• Middleware chain with @middleware(fn) + CORS built-in.

• JWT auth with @auth_provider/@authenticated/@admin + @requires("custom_role") for RBAC. Argon2id password hashing. Token blacklist over Postgres for logout/refresh.

• WebSockets with WsConn<T>, AsyncAPI auto, heartbeat, auth pre-upgrade.

• Cron jobs with @cron("expr") (with retry, timezone, persistence, catch-up), background jobs with @background + spawn(...).

• Postgres ORM with @table/@primary/@column/@belongs_to/@has_many, closure-to-SQL, eager loading, transactions (db.transaction(fn)), schema migrations (fitz db diff/migrate).

• TLS strict for Postgres (sslmode=require).

• Async/await on tokio.

• Python interop with from python import ..., including auto-bridging async.

• CLI builder with @command — same language for CLI tools.

• Production stack: @healthz/@readyz, Secret<T>, secret()/config(), @trace/@metric, @flag, OpenTelemetry OTLP export, Prometheus /metrics, fitz docker init/build, fitz deploy.

• Package manager with path deps and git deps.

• Full tooling: LSP (with signature help, format on save, hover over params and bindings), fmt, test, dev, repl, lint.

What's not in the box yet:

• Frontend in .fitz (single-file components, SSR). Roadmap (Fase 11) — the most ambitious bet of the project. Not started.

• A public package registry. Path deps and git deps work today; the registry is on hold until there's real demand.

• fitz deploy targets beyond docker/compose (no fly/railway/k8s wrapper yet — use the native CLIs).

• Interactive debugging in VSCode (Debug Adapter Protocol). Workarounds: print, REPL :type/:env, LSP diagnostics. Tracked as V6 in the backlog.

What's stable: ~3030 Rust unit tests + 13 LSP E2E + 360 compile E2E (smoke over every example in the guide) + ~140 more across other suites running in CI on every push. Clippy -D warnings clean.

How to try it

# Install on Linux / macOS / WSL
curl -sSf https://thegreekman76.github.io/fitz/install.sh | sh

# Install on Windows (PowerShell)
irm https://thegreekman76.github.io/fitz/install.ps1 | iex

# Or grab a release binary from GitHub
# https://github.com/Thegreekman76/fitz/releases

# Reopen the terminal so the PATH change takes effect, then:
fitz --version

VSCode extension (recommended — syntax highlighting, hover with types, autocomplete, signature help, format on save): grab the .vsix for your platform from the same releases page (fitz-lang-<platform>.vsix) and install it with code --install-extension fitz-lang-<platform>.vsix --force. The Language Server is bundled inside — no separate install needed. Reload VSCode once.

First server:

fitz new my-api --http
cd my-api
fitz dev

Eight boilerplates ship in the repo under boilerplates/:

• api-simple — minimal HTTP API.

• api-middleware-cors — middleware chain + CORS configuration.

• api-postgres-fitz — ORM + Postgres, Dockerized.

• api-postgres-python — Postgres via Python/SQLAlchemy interop.

• api-websocket — typed WebSocket chat.

• api-orm-full — the full showcase: auth + ORM + WebSockets + cron + jobs.

• api-fullstack-postgres — backend + minimal frontend in one binary.

• cli-tool — CLI app with @command (no HTTP).

Each one runs with docker compose up or fitz dev. The README has the full matrix.

Why I built this

I live in El Chaltén, in Argentine Patagonia. The Fitz Roy is the granite tower that defines the skyline here. Borges wrote that we live in a country where the past is uncertain and only the future is real. I think that's true of programming languages too: the past is full of accumulated workarounds for missing language features, and the future is whatever you decide to build.

I've spent ten years writing API code in Python. I love FastAPI. But every time I start a new project, the first three hours are spent gluing libraries together to do the same thing I did last week. At some point the question becomes: what would a language look like that started from this set of needs in 2026, instead of growing them as patches on a language designed for shell scripting in 1991?

That's Fitz.

It's not done. I'm one person. It will get there.

Repo: github.com/Thegreekman76/fitz

Docs and course: thegreekman76.github.io/fitz

Guide (34 chapters): thegreekman76.github.io/fitz/guide/

Roadmap: docs/roadmap.md

CHANGELOG: CHANGELOG.md — every release with detail.

Issues: github.com/Thegreekman76/fitz/issues

If you try it, I want to hear what broke. Open an issue or a discussion on GitHub.