Bitty è un progetto open source dedicato alla realizzazione di un moderno terminal workspace scritto interamente in Rust. Il progetto si trova ancora in una fase iniziale e non deve quindi essere considerato un terminale pronto per l’utilizzo quotidiano, ma la struttura tecnica già definita permette di capire abbastanza bene la direzione intrapresa dagli sviluppatori.
L’obiettivo è costruire una base modulare nella quale le diverse funzionalità del terminale siano suddivise in componenti indipendenti. Questa impostazione riguarda sia la gestione del terminale virtuale sia il supporto PTY, la configurazione, il rendering, l’interfaccia utente e il runtime.
Il repository principale contiene attualmente un workspace Cargo composto da 16 crate. La scelta di Rust 2024, insieme a un sistema di dipendenze controllate e a rigorosi controlli durante la compilazione, evidenzia l’attenzione riservata alla qualità del codice e alla manutenzione futura.
Bitty non dispone ancora di una API Rust pubblica stabile e il progetto stesso viene descritto come una base di sviluppo piuttosto che come una release definitiva. Questo aspetto è importante per comprendere correttamente il significato della versione 0.0.1: alcune componenti sono già pubblicate, mentre altre rimangono volutamente escluse dalla pubblicazione in attesa dell’approvazione delle relative specifiche.
Un’architettura modulare costruita attorno a Rust
La struttura di Bitty è probabilmente uno degli aspetti più interessanti del progetto. Il workspace comprende 16 membri, tra cui vt, pty, platform, config, package, lua, term-state, ui, render, plugin-host, rich, ipc, agent, runtime, app e core.
La suddivisione permette di separare responsabilità differenti. Il crate vt gestisce la parte relativa al terminale virtuale, mentre pty si occupa dell’interazione con lo pseudoterminale. term-state conserva lo stato del terminale e altri componenti gestiscono configurazione, piattaforma, rendering e interfaccia.
Per il rendering sono state scelte tecnologie moderne del mondo Rust, mentre il progetto utilizza anche componenti come winit, wgpu, crossfont, portable-pty e vte. Le versioni delle dipendenze sono bloccate all’interno del workspace, una scelta utile per mantenere prevedibile l’ambiente di compilazione.
Tra gli elementi tecnici dichiarati dal progetto troviamo:
- Rust edition 2024 e
resolver = "3"; - MSRV fissata a Rust 1.85;
- toolchain di sviluppo bloccata alla versione 1.97.1;
- Clippy e rustfmt integrati nel processo di verifica;
- controllo CI anche per Windows x86_64;
- test headless per la prima fetta funzionale;
- policy che impone
unsafe_code = deny; - workflow
just checkper formattazione, Clippy, test e controlli aggiuntivi.
La prima implementazione segue una strategia chiamata Minimal Correct Terminal headless slice. Questa comprende principalmente vt, pty, term-state, platform, config, render, ui, runtime e app, mentre altri componenti rimangono in attesa delle decisioni progettuali necessarie.
Bitty 0.0.1 e lo stato attuale dello sviluppo
La versione 0.0.1 rappresenta soprattutto un primo punto di verifica del lavoro svolto. Nove crate sono già stati pubblicati su crates.io, tra cui vt, pty, platform, config, package, lua, term-state, ui e render.
Il componente bitty-app, invece, non è ancora pubblicato su crates.io e rimane disponibile esclusivamente come preview. È presente una build binaria Linux x64 attraverso le GitHub Releases, ma anche questa non deve essere interpretata come una release stabile destinata al grande pubblico.
Particolarmente interessante è il lavoro dedicato alla verifica del comportamento headless. Il progetto indica una prima slice v0.1 con funzionalità legate a shell echo, ridimensionamento e gestione della pressione dei dati, accompagnata da centinaia di test automatici. Si tratta però ancora di materiale sottoposto a revisione indipendente.
Gli sviluppatori hanno inoltre separato chiaramente ciò che è già definito da ciò che deve ancora essere deciso. Rimangono infatti aperti diversi aspetti, tra cui licenza, profili di release, automazione delle pubblicazioni, policy di distribuzione, livelli di supporto delle piattaforme e comportamento finale del prodotto.
Questa impostazione rende Bitty particolarmente interessante da seguire proprio perché il progetto sta costruendo le proprie fondamenta prima di arrivare a una release più completa. La documentazione tecnica viene mantenuta separatamente nel repository dedicato bitty-docs, mentre decisioni architetturali e procedure di sviluppo vengono formalizzate attraverso documenti specifici.
Per ora, quindi, Bitty va considerato come un progetto in costruzione e non come un’alternativa già pronta ai terminali Linux più maturi. La presenza di un’architettura Rust modulare, di una suite di test e di una precisa scaletta per le future pubblicazioni mostra però un approccio molto strutturato allo sviluppo. La roadmap prevista punta a far evolvere gradualmente i diversi crate, passando dalle fondamenta già verificate verso componenti più avanzati e, successivamente, verso una possibile release stabile.