DEV Community: Marco Bollero

I wrote Ratiform to stop writing forms in Ratatui

Marco Bollero — Fri, 11 Sep 2026 09:19:07 +0000

The problem: two fields are fine, three start to hurt

Anyone who has written even a small TUI with Ratatui knows the progression. The first input is trivial: a String in the app's state, a match on keyboard events to handle typing and deletion, a Paragraph widget to draw it. Maybe five minutes of work.

The second field is basically a copy-paste of the first. It still works, but something starts to creak: now you also need to track which of the two fields has focus, and Tab has to move it from one to the other.

It's with the third field that the problem changes nature. It's no longer "a bit of repeated code" — it's state management that doesn't scale: three Strings synced by hand, an index or an enum for focus, a keyboard whose events need to be routed to the right field based on that index, plus — if you want to do it properly — validation, error messages, a disabled field here, a read-only one there. Every new field adds complexity, and it adds it combinatorially, because it touches focus, validation, and rendering for every other field...

At that point there are two ways forward: rewrite, for the umpteenth time, the same focus-and-validation infrastructure, or look for a widget that handles it for you.
It's exactly out of this friction that ratiform was born — a crate I wrote to move that infrastructure out of application code.

The idea: the field identifier is a real Rust type

ratiform makes one deliberate structural choice: a field's identifier isn't a &str, it's a generic type T — in practice, almost always your own enum, though even an integer works as an identifier!

#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
enum Field {
    Name,
    Email,
    Country,
    Terms,
}

FormBuilder, FormState<T> and Form<T> are all generic over this T. In practice, that means state.value(&Field::Email) is code the compiler checks for you: rename a variant of the enum, and every place that references it stops compiling until you update it. There's no "email" string hiding somewhere in the code that can silently drift out of sync with everything else.

"Typed", here, is about the field's identifier: Field::Email can never be confused with an arbitrary string. Values themselves remain strings, optionally convertible via value_as.

With that foundation in place, let's see ratiform in action — starting from the bare minimum and working up to theming.

1. The bare minimum: a single field

First, install it:

cargo add ratiform

And a form with a single text field:

use ratiform::{Form, builder::FormBuilder};

#[derive(Debug, Hash, Eq, PartialEq)]
enum Field {
    Name,
}

let mut state = FormBuilder::new()
    .single_line(Field::Name, "Name")
    .build();

state is a FormState<Field> — the object your application owns for as long as the form is active: no hidden global state, no callback registry. Rendering happens by passing Form::default() (a stateless StatefulWidget) and &mut state to render_stateful_widget, exactly as you would with a List or a Table from Ratatui.

Worth noting: every field is required by default. You don't need to call .required(...) to get that behavior — you need .optional() if you want to opt out, or .required("your custom message") if you just want to replace the built-in error message with your own.

2. More fields, one `Tab` to move between them

Adding fields means chaining more calls onto the same builder — this is where the difference from the "three hand-synced Strings" scenario shows up:

#[derive(Debug, Hash, Eq, PartialEq)]
enum Field {
    Username,
    Password,
}

let mut state = FormBuilder::new()
    .single_line(Field::Username, "Username")
    .required("Username is required".to_owned())
    .single_line(Field::Password, "Password")
    .masked()
    .required("Password is required".to_owned())
    .build();

Focus, navigation and validation are already handled: Tab/Shift+Tab move focus between fields, Ctrl+Enter (or plain Enter, if the focused field doesn't intercept it for something else) submits the form — but only if no field is invalid — and Esc cancels it. The event loop in your application shrinks down to a handful of lines:

if let Event::Key(key) = event::read()?
    && key.kind == event::KeyEventKind::Press
{
    state.handle_input(key);

    match state.result() {
        FormResult::Submitted | FormResult::Cancelled => break Ok(()),
        FormResult::Working => {}
    }
}

.masked() already hints at an important detail: masking is purely cosmetic. A password field shows dots on screen, but validation and value() still see exactly what the user typed.

3. Not just text: checkbox, select, text area

A form is rarely made only of single-line inputs. ratiform covers three other field kinds, with the same chained syntax.

A checkbox is a boolean, toggled with Space:

.checkbox(Field::Terms, "I accept the terms")
    .checked(false)
    .optional()

A select is a list of (value, label) pairs, navigated with the arrow keys, Home/End, PageUp/PageDown. A subtle point: value() returns the value, not the label shown on screen:

.select(Field::Country, "Country")
    .values_ref(&[("IT", "Italy"), ("FR", "France"), ("DE", "Germany")])
    .selected(1)
    .height(5)

A text area handles multi-line text, with scrolling and paging. There's one keyboard-ergonomics detail worth calling out: since Enter inserts a newline instead of submitting the form, the combination to confirm while a TextArea has focus becomes Ctrl+Enter:

.text_area(Field::Notes, "Notes")
    .placeholder("Write here...")
    .height(5)

4. Getting values back: still no magic strings

Once the form has been submitted, values() consumes the state and returns an iterator of (T, String) pairs — which you can collect directly into a HashMap typed on your own enum, as long as that enum implements Hash and Eq, of course:

let values: HashMap<Field, String> = state.values().collect();

And if you need to read a value while the form is still in progress — say, to reflect what's been typed elsewhere in your UI, like a live preview — you don't have to wait for submission: value(&Field::Email) and value_as::<u16>(&Field::Port) — the latter parsing directly into any FromStr type — both work at any point.

5. Validation: "required" and "well-formed" are two separate questions

ratiform conceptually separates two different questions: "can this field be empty?" and "if it isn't empty, does its content have the right shape?". The first question is handled by the required/optional mechanism above; the second by .validator(...), a function Fn(&str) -> Result<(), String>.

.single_line(Field::CodiceFiscale, "Codice fiscale")
    .validator(ratiform::validators::max_length(16, "Too long".to_owned()))

The library already ships a set of common validators under ratiform::validators: min_length/max_length (Unicode-aware), is_numeric, alphabetic/alphanumeric, no_whitespace, and parsable::<T>, which relies on T: FromStr — useful even with types that don't belong to ratiform, such as parsable::<chrono::NaiveDate>(...) for a correct, leap-year-aware date validator without ratiform itself depending on chrono.

One detail: a validator never sees an empty string. If the field is empty, the required check decides on its own — so none of the built-in validators (or your own) ever needs to special-case an empty string.

6. Normalizing, not just validating

Where validator judges an already-typed value, normalizer rewrites it into a canonical form before validation sees it:

.single_line(Field::CodiceFiscale, "Codice fiscale")
    .normalizer(|value: &str| value.to_uppercase())
    .validator(ratiform::validators::max_length(16, "Too long".to_owned()))

The normalizer runs on every keystroke, on set_value, and on the initial value: the field is never seen — not by the validator, not by is_dirty(), not by values() — in any form other than its normalized one. Paired with alphabet(...) on a single-line field, the split of responsibilities is clean: alphabet rejects a character outright, normalizer rewrites one that was allowed in but needs correcting.

7. Layout: horizontal or stacked, decided at runtime

By default, every field shows its label and value on the same row (FormLayout::Horizontal). If the terminal is narrow, FormLayout::Stacked puts the label above the value instead:

frame.render_stateful_widget(
    Form::default().with_layout(FormLayout::Stacked),
    area,
    &mut state,
);

Since Form is rebuilt fresh every frame, nothing stops you from picking the layout based on the available width at that moment — which is exactly what examples/layouts.rs does, switching to Stacked once the terminal gets too narrow, with no dedicated code needed to intercept the resize.

Horizontal and Stacked are enough as long as the form's shape is "one row per field". But a shipping address, say, has a natural geometry of its own: street on its own full row, then city/state/zip split across three columns of different widths. For cases like this there's a third variant, FormLayout::Custom, which describes the form as an explicit grid of rows and columns, cell by cell:

Email                   Password
_______________________ ____________________

Address
____________________________________________

City                  State          Zip
_____________________ ______________ _______

Each grid cell is a (Constraint, content) pair: the Constraint is the same Ratatui type you already use for ordinary layouts (Length, Fill, ...), and the content declares what to draw in that cell — a field's label (Label), its input widget (Value), its validation message (Error) — or nothing at all, for a spacer. The most readable way to write it is the custom_layout! macro, which mirrors the grid row by row:

use ratiform::{Form, FormLayout, builder::FormBuilder, custom_layout};

let grid_layout = custom_layout! {
    // Email | Password
    row [
        (Constraint::Fill(1), Label(Field::Email)),
        (Constraint::Fill(1), Label(Field::Password)),
    ],
    row [
        (Constraint::Fill(1), Value(Field::Email)),
        (Constraint::Fill(1), Value(Field::Password)),
    ],
    row [
        (Constraint::Length(15), Error(Field::Email)),
        (Constraint::Fill(1), Error(Field::Password)),
    ],

    // Address
    row [(Constraint::Fill(1), Label(Field::Address))],
    row [(Constraint::Fill(1), Value(Field::Address))],
    row [(Constraint::Fill(1), Error(Field::Address))],

    // City | State | Zip
    row [
        (Constraint::Fill(1), Label(Field::City)),
        (Constraint::Fill(1), Label(Field::State)),
        (Constraint::Length(9), Label(Field::Zip)),
    ],
    row [
        (Constraint::Fill(1), Value(Field::City)),
        (Constraint::Fill(1), Value(Field::State)),
        (Constraint::Length(9), Value(Field::Zip)),
    ],
    row [
        (Constraint::Fill(1), Error(Field::City)),
        (Constraint::Fill(1), Error(Field::State)),
        (Constraint::Length(9), Error(Field::Zip)),
    ],
};

let form = Form::default().with_layout(FormLayout::Custom(grid_layout));

Three things worth noting:

Label, value, and error are independent cells. This isn't a cosmetic detail: you can place Email's label above its value, yet aligned on the same row as Password's label — something no combination of Horizontal/Stacked allows, since there the three parts of a field always stay a single block.
A spacer is a cell with None content instead of one of the three identifiers — handy for visually separating groups of fields without inventing a dummy field.
Focus still follows the order fields were declared in the builder, not their order on the grid. If the grid mirrors the Email → Password → Address → ... sequence used in single_line(...), Tab moves in the "natural" order you'd expect looking at the screen; if the two sequences diverge, Tab still works, but jumps from one point on screen to another in an order the eye doesn't anticipate. The reverse also holds: a field left out of the grid still receives focus when its turn comes — just with no visible cursor, and nowhere to show a validation error.

If you'd rather assemble the grid programmatically — rows generated in a loop, for instance — CustomLayout::builder() is the fluent equivalent of the same macro:

let grid_layout = CustomLayout::builder()
    .row()
    .label(Constraint::Fill(1), Field::Email)
    .label(Constraint::Fill(1), Field::Password)
    .row()
    .value(Constraint::Fill(1), Field::Email)
    .value(Constraint::Fill(1), Field::Password)
    .build();

Finally, .with_column_gap(n) on CustomLayout sets the horizontal gap between adjacent columns in the same row (1 by default) — the first column of every row is naturally never preceded by any spacing.

8. Theming: when the default gray isn't enough

By default, Form::default() renders with a gray/bold/reversed scheme. To customize it, you build a FormStyle and pass it to Form::with_style(...) — nothing surprising so far. What makes the difference is how you describe that FormStyle: a small rule engine, where each rule declares who it applies to, across three independent axes:

Widgets — which kind of field: SINGLE_LINE, TEXT_AREA, CHECK_BOX, SELECT, MULTI_SELECT, or ANY for all of them.
Parts — which visual part of that field: LABEL (the caption), AREA (the box's background), TEXT (the typed text), PLACEHOLDER, MARKER (a checkbox's [x] glyph, or a multi-select's marker), ITEM/ACTIVE/SELECTED (a select's rows, and which of them has the cursor or is chosen), ERROR, or ANY.
States — the field's current state: NORMAL, FOCUSED, DISABLED, READ_ONLY, or ANY.

Each of the three is a bitmask combined with | — Widgets::SINGLE_LINE | Widgets::TEXT_AREA is just as valid a rule as a single constant. A rule is written with FormStyleBuilder::add(widgets, parts, states, style), and you declare as many as you need:

use ratatui::style::{Color, Style};
use ratiform::style::{FormStyle, Parts, States, Widgets};

let label = Style::default().fg(Color::Cyan);
let value = Style::default().fg(Color::White);

let my_style = FormStyle::builder()
    .add(Widgets::ANY, Parts::LABEL, States::NORMAL, label)
    .add(Widgets::ANY, Parts::LABEL, States::FOCUSED, label.bold())
    .add(
        Widgets::ANY,
        Parts::TEXT | Parts::ITEM | Parts::MARKER,
        States::NORMAL,
        value,
    )
    .add(
        Widgets::ANY,
        Parts::TEXT | Parts::ITEM | Parts::MARKER,
        States::FOCUSED,
        value.bold(),
    )
    .add(
        Widgets::ANY,
        Parts::AREA | Parts::ACTIVE,
        States::FOCUSED,
        value.bg(Color::Blue),
    )
    .add(
        Widgets::ANY,
        Parts::ERROR,
        States::ANY,
        Style::default().bg(Color::Red).fg(Color::White).bold(),
    )
    .build();

frame.render_stateful_widget(Form::default().with_style(my_style), area, &mut state);

This example (taken from examples/theming.rs) shows two concrete advantages over five fixed slots: TEXT, ITEM and MARKER — that is, "the actual content", whether it's typed text, a select's row, or a checkbox's marker — share the same rule in one shot, instead of being three separate properties you'd have to keep in sync by hand; and AREA | ACTIVE does the same for highlighting, whether that's a focused SingleLine's background or a Select's active row.

Rules can be declared in any order. FormStyleBuilder::build() sorts them by specificity on its own before resolving any overlaps: a rule naming a single widget beats one naming all five with ANY, even if the latter was written afterward; the same cascades through Parts and then States. Declaration order only matters as the final tie-break, when two rules are equally specific — in that case the last one written wins. In practice: you can start with a broad rule (Widgets::ANY, Parts::ANY, States::ANY, normal) as the baseline for the whole form, then refine it with progressively more targeted rules, without worrying about which line comes first in the code.

The default theme itself is built with the exact same mechanism — it isn't a special case, just a FormStyle::builder() with a particular set of rules already written for you: a dark background for the AREA of SingleLine/TextArea, bold for the label and content when a field has focus, reversed colors for a select's active row, red and bold for errors, italic gray for placeholders, and a uniform strikethrough — across every part, with a single Parts::ANY rule — for disabled fields.

Closing the loop

The thread running through everything, from the first field to full theming, stays the same: ratiform owns input, focus, validation and navigation — exactly the part that becomes painful to write by hand past the second field — but it never owns your data model. The identifier stays your own type from beginning to end, the value always comes back as a String tied to that identifier, and no step in between forces you to invent an interchange format for data the compiler already knew about from the start.

Having said what it does, it's worth being just as clear about what ratiform doesn't do:

it isn't an application framework: it owns focus, input and validation for individual fields, not domain logic, screen routing, or data persistence;
it doesn't manage the event loop: you're the one reading events from crossterm and passing each KeyEvent to handle_input(...);
it doesn't automatically turn the form into your own struct: values() returns (T, String) pairs, and mapping them to a typed struct is left to you;
it doesn't handle the mouse: handle_input only accepts keyboard events.

ratiform is still at version 0.x: its public API can therefore still evolve, even though the core ideas — typed identifiers, the builder/state/widget split, validation and normalization — are by now fairly settled.

The code, the full examples, and the changelog are on the GitHub repository; the crate is published on crates.io.

This article was originally written in Italian and translated into English with the help of AI.

Ho scritto Ratiform per smettere di scrivere i form in Ratatui

Marco Bollero — Fri, 11 Sep 2026 09:06:37 +0000

Il problema: due campi vanno bene, tre iniziano a far male

Chi ha scritto anche solo una TUI con Ratatui conosce la progressione. Il primo input è banale: uno String nello stato dell'app, un match sugli eventi tastiera per gestire inserimento e cancellazione, un widget Paragraph per disegnarlo. Forse solo cinque minuti di lavoro.

Il secondo campo si scrive praticamente per copia-incolla del primo. Funziona ancora, ma qualcosa inizia a scricchiolare: ora serve anche capire quale dei due campi ha il focus, e Tab deve spostarlo dall'uno all'altro.

È con il terzo campo che il problema cambia natura. Non è più "un po' di codice ripetuto", è gestione dello stato che non scala: tre pezzi di String sincronizzati a mano, un indice o un enum per il focus, una tastiera i cui eventi vanno smistati al campo giusto in base a quell'indice, più — se vuoi fare le cose per bene — validazione, messaggi di errore, un campo disabilitato qui e uno in sola lettura là. Ogni nuovo campo aggiunge complessità e la aggiunge in modo combinatorio, perché tocca il focus, la validazione e il rendering di tutti gli altri...

A questo punto le strade sono due: scrivere daccapo, per l'ennesima volta, la stessa infrastruttura di gestione-focus-e-validazione, oppure cercare un widget che se ne occupi al posto tuo.
È proprio da questa frizione che è nato ratiform, una crate che ho scritto per spostare questa infrastruttura fuori dal codice dell'applicazione.

L'idea: l'identificatore del campo è un tipo Rust vero

ratiform fa una scelta strutturale precisa: l'identificatore di un campo non è un &str, è un tipo generico T — nella pratica, quasi sempre un tuo enum, ma anche un intero può essere usato come identificatore!

#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
enum Field {
    Name,
    Email,
    Country,
    Terms,
}

FormBuilder, FormState<T> e Form<T> sono tutti generici su questo T. Il risultato pratico è che state.value(&Field::Email) è codice che il compilatore controlla per te: se rinomini una variante dell'enum, ogni punto che la referenzia smette di compilare finché non lo aggiorni. Non c'è nessuna stringa "email" nascosta in un punto qualunque del codice che può disallinearsi dal resto senza produrre un errore di compilazione.

“Tipizzato”, qui, riguarda l'identificatore del campo: Field::Email non può essere confuso con una stringa arbitraria. I valori rimangono invece stringhe, eventualmente convertibili tramite value_as.

Con questa base, vediamo ratiform in azione, partendo dal minimo indispensabile e arrivando fino al theming.

1. Il minimo indispensabile: un solo campo

Prima di tutto, l'installazione:

cargo add ratiform

E un form con un solo campo di testo:

use ratiform::{Form, builder::FormBuilder};

#[derive(Debug, Hash, Eq, PartialEq)]
enum Field {
    Name,
}

let mut state = FormBuilder::new()
    .single_line(Field::Name, "Name")
    .build();

state è un FormState<Field> — l'oggetto che la tua applicazione possiede per tutta la vita del form: niente stato globale nascosto, niente registro di callback. Il rendering avviene passando Form::default() (uno StatefulWidget stateless) e &mut state a render_stateful_widget, esattamente come faresti con una List o una Table di Ratatui.

Da notare: ogni campo è obbligatorio di default. Non serve chiamare .required(...) per ottenere questo comportamento — serve semmai .optional() per disattivarlo, o .required("messaggio personalizzato") se vuoi sostituire il messaggio d'errore predefinito con uno tuo.

2. Più campi, un solo `Tab` per spostarsi

Aggiungere campi significa incatenare altre chiamate sullo stesso builder — è qui che si vede la differenza rispetto allo scenario "tre String sincronizzate a mano":

#[derive(Debug, Hash, Eq, PartialEq)]
enum Field {
    Username,
    Password,
}

let mut state = FormBuilder::new()
    .single_line(Field::Username, "Username")
    .required("Username is required".to_owned())
    .single_line(Field::Password, "Password")
    .masked()
    .required("Password is required".to_owned())
    .build();

Focus, navigazione e validazione sono già gestiti: Tab/Shift+Tab spostano il focus tra i campi, Ctrl+Enter (o semplicemente Enter, se il campo attivo non lo intercetta per un altro scopo) invia il form — ma solo se nessun campo è invalido — ed Esc lo annulla. Il ciclo di eventi nella tua applicazione si riduce a una manciata di righe:

if let Event::Key(key) = event::read()?
    && key.kind == event::KeyEventKind::Press
{
    state.handle_input(key);

    match state.result() {
        FormResult::Submitted | FormResult::Cancelled => break Ok(()),
        FormResult::Working => {}
    }
}

Da .masked() si intuisce già un dettaglio importante: il mascheramento è solo cosmetico. Un campo password mostra puntini a schermo, ma validazione e value() continuano a vedere quello che l'utente ha effettivamente digitato.

3. Non solo testo: checkbox, select, area di testo

Un form raramente è fatto solo di input a riga singola. ratiform copre altri tre tipi di campo, con la stessa sintassi a catena.

Una checkbox è un booleano, attivato con Space:

.checkbox(Field::Terms, "I accept the terms")
    .checked(false)
    .optional()

Una select è una lista di coppie (valore, etichetta), navigabile con le frecce, Home/End, PageUp/PageDown. Punto sottile: value() restituisce il valore, non l'etichetta visualizzata:

.select(Field::Country, "Country")
    .values_ref(&[("IT", "Italy"), ("FR", "France"), ("DE", "Germany")])
    .selected(1)
    .height(5)

Una text area gestisce testo multilinea, con scrolling e paginazione. Qui c'è un dettaglio di ergonomia della tastiera che vale la pena notare: dato che Enter inserisce un a-capo invece di invia il form, la combinazione per confermare mentre il focus è su una TextArea diventa Ctrl+Enter:

.text_area(Field::Notes, "Notes")
    .placeholder("Write here...")
    .height(5)

4. Recuperare i valori: ancora niente stringhe magiche

Una volta che il form è stato sottomesso, values() consuma lo stato e restituisce un iteratore di coppie (T, String) — che puoi raccogliere direttamente in una HashMap tipizzata sul tuo enum, se na enum implementa Hash ed Eq ovviamente:

let values: HashMap<Field, String> = state.values().collect();

E se ti serve leggere un valore mentre il form è ancora in corso — per esempio per riflettere quanto digitato altrove nella tua UI, tipo un'anteprima live — non devi aspettare la sottomissione: value(&Field::Email) e value_as::<u16>(&Field::Port) — quest'ultimo per parsare direttamente in un tipo FromStr — funzionano in ogni momento.

5. Validazione: obbligatorietà e regole di forma sono due cose distinte

ratiform separa concettualmente due domande diverse: "questo campo può essere vuoto?" e "se non è vuoto, il suo contenuto rispetta una certa forma?". La prima domanda è gestita dal meccanismo required/optional visto sopra; la seconda da .validator(...), una funzione Fn(&str) -> Result<(), String>.

.single_line(Field::CodiceFiscale, "Codice fiscale")
    .validator(ratiform::validators::max_length(16, "Troppo lungo".to_owned()))

La libreria include già un pacchetto di validatori comuni in ratiform::validators: min_length/max_length (Unicode-aware), is_numeric, alphabetic/alphanumeric, no_whitespace, e parsable::<T>, che sfrutta T: FromStr — utile anche con tipi che non appartengono a ratiform, come parsable::<chrono::NaiveDate>(...) per una validazione di data corretta (bisestili inclusi) senza che ratiform debba dipendere da chrono.

Un dettaglio: un validatore non vede mai una stringa vuota. Se il campo è vuoto, decide il controllo di obbligatorietà, non il validatore — quindi nessuno dei validatori built-in (né i tuoi) deve gestire il caso speciale della stringa vuota.

6. Normalizzare, non solo validare

Dove validator giudica un valore già digitato, normalizer lo riscrive in una forma canonica prima che la validazione lo veda:

.single_line(Field::CodiceFiscale, "Codice fiscale")
    .normalizer(|value: &str| value.to_uppercase())
    .validator(ratiform::validators::max_length(16, "Troppo lungo".to_owned()))

Il normalizer gira a ogni tasto premuto, su set_value e sul valore iniziale: il campo non viene mai visto — né dal validatore, né da is_dirty(), né da values() — in una forma diversa da quella normalizzata. Abbinato ad alphabet(...) su un campo a riga singola, la divisione dei compiti è pulita: alphabet rifiuta un carattere non ammesso, normalizer riscrive uno che era ammesso ma va corretto.

7. Layout: orizzontale o impilato, deciso a runtime

Di default ogni campo mostra etichetta e valore sulla stessa riga (FormLayout::Horizontal). Se il terminale è stretto, FormLayout::Stacked mette l'etichetta sopra il valore:

frame.render_stateful_widget(
    Form::default().with_layout(FormLayout::Stacked),
    area,
    &mut state,
);

Dato che Form viene ricostruito a ogni frame, nulla impedisce di scegliere il layout in base alla larghezza disponibile in quel momento — è esattamente quello che fa examples/layouts.rs, passando a Stacked quando il terminale si stringe, senza bisogno di codice dedicato per intercettare il resize.

Horizontal e Stacked bastano finché la forma del form è "una riga per campo". Ma un indirizzo di spedizione, per dire, ha una sua geometria naturale: via su una riga intera, poi città/provincia/CAP spartiti su tre colonne di larghezza diversa. Per questi casi c'è una terza variante, FormLayout::Custom, che descrive il form come una griglia esplicita di righe e colonne, cella per cella:

Email                   Password
_______________________ ____________________

Address
____________________________________________

City                  State          Zip
_____________________ ______________ _______

Ogni cella della griglia è una coppia (Constraint, contenuto): il Constraint è lo stesso tipo di Ratatui che già usi per i layout normali (Length, Fill, ...), il contenuto dichiara cosa disegnare in quella cella — l'etichetta di un campo (Label), il suo widget di input (Value), il suo messaggio di errore (Error) — oppure niente, per uno spaziatore. Il modo più leggibile per scriverla è la macro custom_layout!, che rispecchia la griglia riga per riga:

use ratiform::{Form, FormLayout, builder::FormBuilder, custom_layout};

let grid_layout = custom_layout! {
    // Email | Password
    row [
        (Constraint::Fill(1), Label(Field::Email)),
        (Constraint::Fill(1), Label(Field::Password)),
    ],
    row [
        (Constraint::Fill(1), Value(Field::Email)),
        (Constraint::Fill(1), Value(Field::Password)),
    ],
    row [
        (Constraint::Length(15), Error(Field::Email)),
        (Constraint::Fill(1), Error(Field::Password)),
    ],

    // Address
    row [(Constraint::Fill(1), Label(Field::Address))],
    row [(Constraint::Fill(1), Value(Field::Address))],
    row [(Constraint::Fill(1), Error(Field::Address))],

    // City | State | Zip
    row [
        (Constraint::Fill(1), Label(Field::City)),
        (Constraint::Fill(1), Label(Field::State)),
        (Constraint::Length(9), Label(Field::Zip)),
    ],
    row [
        (Constraint::Fill(1), Value(Field::City)),
        (Constraint::Fill(1), Value(Field::State)),
        (Constraint::Length(9), Value(Field::Zip)),
    ],
    row [
        (Constraint::Fill(1), Error(Field::City)),
        (Constraint::Fill(1), Error(Field::State)),
        (Constraint::Length(9), Error(Field::Zip)),
    ],
};

let form = Form::default().with_layout(FormLayout::Custom(grid_layout));

Da notare tre cose:

Etichetta, valore ed errore sono celle indipendenti. Non è un dettaglio decorativo: puoi mettere l'etichetta di Email sopra il suo valore, ma allineata sulla stessa riga dell'etichetta di Password — cosa che nessuna combinazione di Horizontal/Stacked permette, perché lì le tre parti di un campo restano sempre un blocco unico.
Uno spaziatore è una cella con contenuto None invece di uno dei tre identificatori — utile per separare visivamente gruppi di campi senza inventarsi un campo fittizio.
Il focus segue comunque l'ordine di dichiarazione dei campi nel builder, non l'ordine sulla griglia. Se la griglia rispecchia la sequenza Email → Password → Address → ... usata in single_line(...), Tab si muove nell'ordine "naturale" che ci si aspetta guardando lo schermo; se le due sequenze divergono, Tab continua a funzionare, ma salta da un punto all'altro dello schermo in un ordine che l'occhio non prevede. Vale anche l'inverso: un campo dimenticato nella griglia riceve comunque il focus quando gli tocca — semplicemente senza un cursore visibile e senza un posto dove mostrare un eventuale errore.

Chi preferisce assemblare la griglia in modo programmatico — righe generate da un ciclo, per esempio — ha a disposizione CustomLayout::builder(), l'equivalente fluente della stessa macro:

let grid_layout = CustomLayout::builder()
    .row()
    .label(Constraint::Fill(1), Field::Email)
    .label(Constraint::Fill(1), Field::Password)
    .row()
    .value(Constraint::Fill(1), Field::Email)
    .value(Constraint::Fill(1), Field::Password)
    .build();

Infine, .with_column_gap(n) su CustomLayout regola lo spazio orizzontale tra colonne adiacenti della stessa riga (di default 1) — la prima colonna di ogni riga non viene mai preceduta da spaziatura ovviamente.

8. Theming: quando il grigio di default non basta

Di default, Form::default() disegna con uno schema grigio/grassetto/invertito. Per personalizzarlo si costruisce un FormStyle e lo si passa a Form::with_style(...) — fin qui nulla di sorprendente. Quello che fa la differenza è come si descrive quel FormStyle: un piccolo motore di regole dove ogni regola dichiara a chi si applica, su tre assi indipendenti:

Widgets — quale tipo di campo: SINGLE_LINE, TEXT_AREA, CHECK_BOX, SELECT, MULTI_SELECT, o ANY per tutti.
Parts — quale parte visiva di quel campo: LABEL (l'etichetta), AREA (lo sfondo del riquadro), TEXT (il testo digitato), PLACEHOLDER, MARKER (il simbolo [x] di una checkbox, o il pallino di una multi-select), ITEM/ACTIVE/SELECTED (le righe di una select e quale di esse ha il cursore o è scelta), ERROR, o ANY.
States — lo stato del campo in quel momento: NORMAL, FOCUSED, DISABLED, READ_ONLY, o ANY.

Ognuna delle tre è una maschera di bit che si combina con | — Widgets::SINGLE_LINE | Widgets::TEXT_AREA è una regola valida quanto una singola costante. Una regola si scrive con FormStyleBuilder::add(widgets, parts, states, style), e se ne dichiarano quante servono:

use ratatui::style::{Color, Style};
use ratiform::style::{FormStyle, Parts, States, Widgets};

let label = Style::default().fg(Color::Cyan);
let value = Style::default().fg(Color::White);

let my_style = FormStyle::builder()
    .add(Widgets::ANY, Parts::LABEL, States::NORMAL, label)
    .add(Widgets::ANY, Parts::LABEL, States::FOCUSED, label.bold())
    .add(
        Widgets::ANY,
        Parts::TEXT | Parts::ITEM | Parts::MARKER,
        States::NORMAL,
        value,
    )
    .add(
        Widgets::ANY,
        Parts::TEXT | Parts::ITEM | Parts::MARKER,
        States::FOCUSED,
        value.bold(),
    )
    .add(
        Widgets::ANY,
        Parts::AREA | Parts::ACTIVE,
        States::FOCUSED,
        value.bg(Color::Blue),
    )
    .add(
        Widgets::ANY,
        Parts::ERROR,
        States::ANY,
        Style::default().bg(Color::Red).fg(Color::White).bold(),
    )
    .build();

frame.render_stateful_widget(Form::default().with_style(my_style), area, &mut state);

Da questo esempio (ripreso da examples/theming.rs) si vedono i due vantaggi concreti rispetto alle cinque caselle fisse: TEXT, ITEM e MARKER — cioè "il contenuto vero e proprio", che sia testo digitato, riga di una select o marker di una checkbox — condividono la stessa regola in un colpo solo, invece di essere tre proprietà separate da tenere sincronizzate a mano; e AREA | ACTIVE fa lo stesso per l'evidenziazione, che si tratti dello sfondo di un SingleLine a fuoco o della riga attiva di una Select.

Le regole si dichiarano in qualunque ordine. FormStyleBuilder::build() le ordina da sé per specificità prima di risolvere eventuali sovrapposizioni: una regola che nomina un solo widget batte una che ne nomina cinque con ANY, anche se quest'ultima è stata scritta dopo; lo stesso vale, in cascata, per Parts e poi per States. L'ordine di dichiarazione conta solo come spareggio finale, quando due regole sono ugualmente specifiche — in quel caso vince l'ultima scritta. In pratica: puoi partire da una regola larga (Widgets::ANY, Parts::ANY, States::ANY, normal) come base di tutto il form, e poi affinarla con regole via via più mirate, senza doverti preoccupare di che riga viene prima nel codice.

Il tema di default stesso è costruito con lo stesso identico meccanismo — non è un caso speciale, è solo un FormStyle::builder() con un certo insieme di regole già scritto per te: sfondo scuro per l'area di SingleLine/TextArea, grassetto per etichetta e contenuto quando il campo ha il focus, colori invertiti per la riga attiva di una select, rosso e grassetto per gli errori, corsivo grigio per i placeholder, e barrato uniforme — su ogni parte, con un'unica regola Parts::ANY — per i campi disabilitati.

Chiudendo il cerchio

Il filo conduttore, dal primo campo al theming completo, è sempre lo stesso: ratiform possiede input, focus, validazione e navigazione — cioè esattamente la parte che diventa dolorosa da scrivere a mano oltre il secondo campo — ma non possiede mai il tuo modello dati. L'identificatore resta un tuo tipo dall'inizio alla fine, il valore torna sempre come String legata a quell'identificatore, e nessun passaggio nel mezzo ti obbliga a inventarti un formato di interscambio per dati che il compilatore conosceva già in partenza.

Detto cosa fa, vale la pena essere altrettanto chiari su cosa ratiform non fa:

non è un framework applicativo: possiede focus, input e validazione dei singoli campi, non la logica di dominio, il routing tra schermate o la persistenza dei dati;
non gestisce l'event loop: sei tu a leggere gli eventi da crossterm e a passare ogni KeyEvent a handle_input(...);
non converte automaticamente il form in una tua struct: values() restituisce coppie (T, String), il passaggio a un tipo tipizzato resta a tuo carico;
non gestisce il mouse: handle_input accetta solo eventi da tastiera.

ratiform è ancora in versione 0.x: l'API pubblica può quindi evolvere, anche se le idee centrali — identificatori tipizzati, separazione tra builder, stato e widget, validazione e normalizzazione — sono ormai abbastanza stabili.

Il codice, gli esempi completi e il changelog sono sul repository GitHub; la crate è pubblicata su crates.io.

Ratatui passo dopo passo - Introduzione

Marco Bollero — Sun, 06 Sep 2026 14:32:32 +0000

Una nota personale

Nel 2000 lavoravo principalmente su Windows NT — stavo pure prendendo una certificazione — quando mi hanno assegnato a un nuovo progetto che doveva collegarsi a server Unix. Il mio collega, in affiancamento, mi dice: "apri il terminale, PuTTY". Io, tranquillo, doppio click sull'icona. Poi: "seleziona questo server". Doppio click. Poi: "metti la finestra a tutto schermo". Doppio click, tutto contento, sapevo esattamente cosa fare.

E poi lui: "ora quel mouse non ti serve più, puoi anche staccarlo".

Panico. Avevo iniziato col Commodore 64, altro che Windows, poi MS-DOS — la tastiera non mi era certo estranea. Ma erano passati anni, e ritrovarmi lì, su un sistema Unix, senza più il mouse a cui appoggiarmi, mi ha fatto pensare per un attimo: ora mi cacciano.

Non mi hanno cacciato. È stata semplicemente la fine del mio attaccamento al mouse. Oggi lavoro quasi esclusivamente da tastiera — Sway come window manager, tmux, nvim — e quando devo aprire Firefox mi scoccia quasi cercarlo. Questa serie nasce anche da lì: dal fatto che il terminale, una volta che smetti di temerlo, diventa lo strumento più diretto che hai.

Cos'è Ratatui

Ratatui è una libreria Rust per costruire interfacce interattive che vivono interamente nel terminale: niente finestre, niente mouse (a meno che tu non lo voglia), solo caratteri, colori e un layout che tu controlli riga per riga. Se hai mai usato htop o lazygit, hai già usato il tipo di applicazione che Ratatui ti mette in condizione di costruire: quelle hanno una TUI, terminal user interface (o qualcuno preferisce text user interface), e sono l'equivalente testuale di una GUI — pannelli, liste selezionabili, barre di stato, il tutto renderizzato con caratteri invece che con pixel.

Non è un framework che nasconde il terminale dietro un'astrazione: è una libreria pensata per dare controllo diretto su cosa appare a schermo.

Oggi trovi TUI scritte in Rust ovunque: client Git, monitor di sistema, gestori di database, dashboard di infrastruttura. Ratatui è uno dei nomi che incontrerai più spesso nell’ecosistema Rust quando si parla di TUI.

A chi si rivolge questa serie

Questa serie parte dal presupposto che tu conosca già Rust — ownership, trait, match, closure — ma non abbia mai toccato Ratatui. Non troverai spiegazioni di sintassi di base del linguaggio, ma nemmeno voli pindarici sull'architettura interna della libreria: l'obiettivo di ogni articolo è farti scrivere codice che produce qualcosa di visibile sul terminale, un tassello alla volta, riusando sempre quello scritto nella puntata precedente.

Serve solo Rust installato e un terminale. Nient'altro.

Come è strutturata la serie

Si parte dal minimo indispensabile — una schermata vuota con una riga di testo — e si arriva, passo dopo passo, a un'applicazione con stato, più widget ed eventi che arrivano anche da un thread in background. Ogni tappa aggiunge un solo concetto nuovo rispetto alla precedente.

Questa è la traccia che ho in mente al momento: potrebbe cambiare strada facendo, soprattutto se qualche argomento si rivelerà abbastanza interessante da meritarsi una puntata tutta sua.

Hello Ratatui — una schermata minima e un Paragraph.
Testo — Span, Line, Text e Paragraph, dal componente più piccolo al più capace.
Layout base — dividere lo schermo in aree con Layout e Constraint.
Block — bordi, titoli e padding.
Input da tastiera — leggere tasti specifici con KeyCode, non solo "un tasto qualsiasi".
Gestire lo stato dell'app — una struct App e il ciclo evento → aggiornamento → ridisegno.
Un text input basilare — costruirsi da soli un campo di testo, cursore compreso.
Un widget alla volta: List e Table — la selezione come stato, con ListState e TableState.
Organizzare il progetto su più file — moduli separati e un enum per generalizzare gli eventi.
Aggiornamenti in background con i thread — un thread separato che produce dati e li invia con std::sync::mpsc.
Async e aggiornamenti in background — la stessa idea, ma con un runtime asincrono.

E probabilmente non finirà qui.

Detto questo: perdersi in chiacchiere ogni tanto fa bene, ma direi che per oggi abbiamo esagerato. Si comincia dal primo passo: una schermata vuota, e la prima riga di testo che ci scriviamo dentro.

Questo articolo è stato pubblicato originariamente sul mio blog personale.

Switching from C/C++ to Rust: the invisible checklist

Marco Bollero — Mon, 02 Feb 2026 14:00:00 +0000

After years of writing code in C and C++, switching to Rust forced me into a reflection I wasn't expecting. It's not about syntax, performance, or language features. It's about something more subtle: where I spend my mental energy while programming.

The invisible checklist

When you write in C or C++, there's a checklist you have to keep running in your head at all times. It's not written anywhere, it doesn't show up in any warning, but it's there:

Could this pointer be null?
Did I free this memory? Did I free it twice?
Will this reference still be valid when I use it?
Is this cast safe?
Am I invoking undefined behavior without knowing it?

It's an invisible burden. You don't perceive it as an obstacle because it's become the norm. It's the constant background noise of every line of code you write. And the most insidious problem is that feedback, when it comes, comes late: a crash in production, a bug report weeks later, a sanitizer telling you that the code that "worked" didn't actually work at all.

Or worse: it never comes. The code runs, seems to work, but it's invoking undefined behavior that just happens not to manifest. Until it does.

The "no" that comes immediately

I'll admit my early days with Rust weren't exactly smooth. The borrow checker kept stopping me. Things I would have written in thirty seconds in C++ required rethinking, restructuring, sometimes complete rewrites of my approach.

But then I realized something: that "no" coming immediately was a gift.

When the compiler stops you, something important happens:

You're still in the mental context of the problem. You don't have to reconstruct weeks later what you were thinking when you wrote that code.
You can fix it while you're still reasoning. The solution is still fresh, the alternatives are still visible.
You learn why that thing is problematic. The error message (often surprisingly helpful) explains what's wrong and why.

It's the difference between a teacher who corrects you while you speak and one who gives you a grade three months later without explaining where you went wrong.

Two types of muscle memory

There's another difference I noticed, more subtle.

In C++, the muscle memory you develop over time is avoidant. You learn not to do certain things. It's a negative memory, not in a pejorative sense, but in the sense that you have to remember what not to do rather than what to do: a list of patterns to avoid, of traps to dodge. And this list keeps growing, because the language doesn't prevent you from falling into the traps, you just have to remember they exist.

In Rust, muscle memory is constructive. You learn patterns that are inherently correct. You don't have to remember what to avoid because the compiler won't let you do it. Instead of thinking "I must remember not to leave the door open", you learn to build a door that closes by itself.

This frees up mental space. Space I can use to think about domain logic, architecture, the problem I'm actually trying to solve, instead of tripping over my own mistakes.

It's not about "better" or "worse"

I'm not saying C or C++ are wrong languages, or that people who use them are making a mistake. They have their legitimate use cases, mature ecosystems, decades of existing code that works.

The question I asked myself is different: where do I prefer to spend my cognitive energy?

Some programmers prefer total freedom and accept the responsibility that comes with it. That's a legitimate choice. Others, and I count myself among them, prefer tighter constraints that free up mental bandwidth to focus on other things.

The cost exists in both cases. In C++ it's distributed over time, invisible, perpetual. In Rust it's concentrated at the beginning, explicit, and decreases as you internalize the patterns.

For me, the second trade-off is more favorable. Not because it's objectively better, but because it fits better with how my head works, and with the kind of mistakes I tend to make.

A final thought

What surprised me most about Rust wasn't the speed, or the language features, or the ecosystem. It was the feeling of programming.

That invisible checklist I'd been carrying in my head for years? It's gone. Or rather: it's been externalized. The compiler holds it for me.

And this, in the end, made me realize how heavy it was to carry.

This post was originally written in Italian and is available here. Translated to English with the help of AI.

Passare da C/C++ a Rust: la checklist invisibile

Marco Bollero — Mon, 02 Feb 2026 08:57:03 +0000

Dopo anni passati a scrivere codice in C e C++, il passaggio a Rust mi ha costretto a una riflessione che non mi aspettavo. Non riguarda la sintassi, le performance, o le feature del linguaggio. Riguarda qualcosa di più sottile: dove spendo le mie energie mentali mentre programmo.

La checklist invisibile

Quando scrivi in C o C++, c'è una checklist che devi tenere sempre attiva nella testa. Non è scritta da nessuna parte, non appare in nessun warning, ma è lì:

Questo puntatore potrebbe essere null?
Ho liberato questa memoria? L'ho liberata due volte?
Questa reference sarà ancora valida quando la userò?
Questo cast è sicuro?
Sto invocando undefined behavior senza saperlo?

È una fatica invisibile. Non la percepisci come ostacolo perché è diventata la normalità. È il sottofondo costante di ogni riga di codice che scrivi. E il problema più insidioso è che il feedback, quando arriva, arriva tardi: un crash in produzione, un bug report settimane dopo, un sanitizer che ti dice che quel codice che "funzionava" in realtà non funzionava affatto.

O peggio: non arriva mai. Il codice gira, sembra funzionare, ma sta invocando undefined behavior che per puro caso non si manifesta. Fino a quando non lo fa.

Il "no" che arriva subito

Ammetto che i primi tempi con Rust non sono stati semplicissimi. Il borrow checker mi bloccava in continuazione. Cose che in C++ avrei scritto in trenta secondi richiedevano ripensamenti, ristrutturazioni, a volte riscritture complete dell'approccio.

Ma poi ho realizzato una cosa: quel "no" che arrivava subito era un regalo.

Quando il compilatore ti ferma, succede qualcosa di importante:

Sei ancora nel contesto mentale del problema. Non devi ricostruire settimane dopo cosa stavi pensando quando hai scritto quel codice.
Puoi correggere mentre ragioni. La soluzione è ancora fresca, le alternative sono ancora visibili.
Impari perché quella cosa è problematica. Il messaggio di errore (spesso sorprendentemente utile) ti spiega cosa non va e perché.

È la differenza tra un insegnante che ti corregge mentre parli e uno che ti dà un voto tre mesi dopo senza spiegarti dove hai sbagliato.

Due tipi di "muscle memory"

C'è un'altra differenza che ho notato, più sottile.

In C++, la "muscle memory" che sviluppi nel tempo è di tipo evitativo. Impari a non fare certe cose. È una memoria negativa, non in senso dispregiativo, ma nel senso che devi ricordare cosa non fare invece di cosa fare: una lista di pattern da evitare, di trappole da schivare. E questa lista cresce continuamente, perché il linguaggio non ti impedisce di cadere nelle trappole, devi solo ricordarti che esistono.

In Rust, la muscle memory è di tipo costruttivo. Impari pattern che sono intrinsecamente corretti. Non devi ricordare cosa evitare perché il compilatore non ti permette di farlo. Invece di pensare "devo ricordarmi di non lasciare la porta aperta", impari a costruire una porta che si chiude da sola.

Questo libera spazio mentale. Spazio che posso usare per pensare alla logica del dominio, all'architettura, al problema che sto effettivamente cercando di risolvere, invece che a non inciampare nei miei stessi errori.

Non è una questione di "meglio" o "peggio"

Non sto dicendo che C o C++ siano linguaggi sbagliati, o che chi li usa stia facendo un errore. Hanno i loro contesti d'uso legittimi, ecosistemi maturi, decenni di codice esistente che funziona.

La domanda che mi sono posto è diversa: dove preferisco spendere le mie energie cognitive?

Alcuni programmatori preferiscono la libertà totale e accettano la responsabilità che ne deriva. È una scelta legittima. Altri, e mi ci metto dentro, preferiscono vincoli più stretti che liberano bandwidth mentale per concentrarsi su altro.

Il costo c'è in entrambi i casi. In C++ è distribuito nel tempo, invisibile, perpetuo. In Rust è concentrato all'inizio, esplicito, e diminuisce man mano che interiorizzi i pattern.

Per me, il secondo trade-off è più favorevole. Non perché sia oggettivamente migliore, ma perché si adatta meglio al modo in cui funziona la mia testa, e al tipo di errori che tendo a fare.

Una riflessione finale

La cosa che più mi ha sorpreso di Rust non è stata la velocità, o le feature del linguaggio, o l'ecosistema. È stata la sensazione di programmare.

Quella checklist invisibile che portavo nella testa da anni? Non c'è più. O meglio: è stata esternalizzata. Il compilatore la tiene per me.

E questo, alla fine, mi ha fatto capire quanto fosse pesante portarla.

Il patto delle dipendenze: quando diventa un Contratto col Diavolo

Marco Bollero — Wed, 28 Jan 2026 08:44:21 +0000

Ogni volta che scrivo cargo add qualcosa, mi piace pensare che sto semplicemente aggiungendo una funzionalità al mio progetto. È comodo, è veloce, è moderno. Ma se sono onesto con me stesso, quello che sto davvero facendo è firmare un contratto trilaterale: tra me, una libreria scritta da uno sconosciuto su internet, e l'utente finale che si fida ciecamente del mio software.

E come tutti i contratti che firmiamo senza leggere, le clausole scritte in piccolo prima o poi vengono a bussare alla porta.

Il giorno in cui tutto va a puttane

Immaginati questa scena, che probabilmente hai già vissuto: sono le 3 del pomeriggio di venerdì. Il cliente ti chiama incazzato nero perché l'applicazione che hai deployato la settimana scorsa sta perdendo dati. Non pochi dati. Dati importanti. Dati che valgono soldi veri.

Tu apri il progetto, guardi il codice che hai scritto. È perfetto. Compila, i test passano, la logica è cristallina. Ma c'è un problema: il bug non è nel TUO codice. È in una delle quaranta dipendenze che hai nel Cargo.toml. O peggio ancora, in una delle centocinquanta dipendenze transitive che non sapevi nemmeno di avere.

Benvenuto nel vero costo delle dipendenze.

Le Due Vie dell'Inevitabilità (o: Perché Siamo Tutti Condannati)

Quando aggiungiamo una dipendenza, fondamentalmente lo facciamo per due ragioni. E nessuna delle due è particolarmente confortante se ci pensi bene.

Prima ragione: non so come fare quella cosa.

Va bene, lo ammetto. Non so scrivere un parser HTTP sicuro. Non so implementare un sistema crittografico che non sia vulnerabile a timing attacks. Non so gestire la compressione di file senza perdere pezzi per strada. E quindi uso reqwest, uso ring, uso flate2.

È una scelta saggia? Certo che sì. Solo un idiota cercherebbe di reinventare la crittografia. Ma ecco il punto: se non so come fare quella cosa, come faccio a debuggare quando quella cosa si rompe? Come faccio a capire se il problema è nel mio codice o nella dipendenza? Come faccio a valutare se quel panic che vedo è un bug loro o un uso scorretto mio?

La risposta è: posso, ma solo fino a un certo punto, e il costo mentale sale vertiginosamente. Certo, posso leggere stack trace, testare input diversi, aprire issue su GitHub sperando che qualcuno risponda. Ma se il problema è veramente dentro quella dipendenza, devo comunque tuffarmi nel codice sorgente e cercare di capire cosa diavolo sta succedendo. E indovina quando potrei dover fare tutto questo? Esatto: alle 3 del pomeriggio di venerdì, con il cliente che urla e una deadline che si avvicina.

Seconda ragione: potrei farlo, ma non ho voglia.

"Perché dovrei scrivere un generatore di UUID quando esiste già una crate per quello?"

"Perché dovrei implementare un serializzatore JSON quando serde fa tutto così bene?"

"Perché dovrei perdere tempo con un template engine quando posso usare tera?"

Risposta breve: perché forse quel tempo "perso" ora ti avrebbe risparmiato una settimana di inferno dopo.

Il paradosso è straordinario: eviti di scrivere qualcosa perché "ti ruberebbe troppo tempo", ma quando quella dipendenza si rompe, sei costretto a capirla lo stesso. Solo che ora lo devi fare:

Sotto pressione
Con il cliente che ti bombarda di email
Cercando di orientarti in un codice scritto da altri, con convenzioni diverse dalle tue
Con la concreta possibilità che dovrai comunque riscrivere tutto da zero perché la dipendenza è abandonware o il maintainer non risponde

Congratulazioni: hai risparmiato due giorni tre mesi fa per perderne sette adesso.

Il Vero Problema Non È la Dipendenza, Sei Tu

Lo so, sembra duro. Ma lasciami spiegare.

Il punto non è che usare dipendenze sia male. Il punto è che le trattiamo come soluzioni magiche invece che come quello che realmente sono: codice scritto da esseri umani fallibili che potrebbe esploderti in faccia in qualsiasi momento.

Quante volte hai aggiunto una dipendenza senza nemmeno aprire il repository per vedere com'è fatto il codice? Quante volte hai guardato solo il numero di download su crates.io pensando "vabbè, se lo usano in tanti sarà affidabile"? Quante volte hai pensato "tanto se c'è un problema faccio un issue su GitHub e qualcuno lo fixerà"?

Ecco, forse la vera incompetenza non è non sapere scrivere una libreria HTTP. Forse la vera incompetenza è delegare a sconosciuti su internet pezzi critici della nostra applicazione senza nemmeno sapere come funzionano.

Quando aggiungi una dipendenza, non stai solo aggiungendo funzionalità. Stai aggiungendo:

Un punto di failure che non controlli
Una superficie d'attacco per bug che non hai scritto tu
Un debito di comprensione che prima o poi dovrai pagare
Una catena di dipendenze transitive che potrebbero essere decine o centinaia
Una responsabilità verso il tuo utente finale che hai delegato a uno sconosciuto

E la cosa folle? Spesso non lo sappiamo nemmeno. Aggiungi una dipendenza pensando che sia "solo quella", ma in realtà stai portandoti dietro un intero ecosistema. Quel crate carino da 500 righe che hai aggiunto? Ha quindici dipendenze. Quelle quindici ne hanno altre trenta. E improvvisamente ti ritrovi con centinaia di migliaia di righe di codice di cui sei responsabile ma che non hai mai letto.

Supply Chain Attacks: Quando il Pericolo Viene da Dentro

Parliamoci chiaro: quando aggiungi una dipendenza, stai letteralmente eseguendo codice scritto da uno sconosciuto su internet. Nella tua macchina. Con i tuoi permessi. Durante la compilazione, durante il runtime, sempre.

E non sto parlando di scenari paranoici da film. Negli ultimi anni abbiamo visto di tutto: dipendenze microscopiche rimosse che hanno mandato in crash interi ecosistemi. Maintainer che, stufi di lavorare gratis per multinazionali miliardarie, hanno deliberatamente introdotto bug nei loro progetti come forma di protesta. Attaccanti che hanno preso il controllo di progetti legittimi e hanno iniettato malware per rubare credenziali o criptovalute.

"Ma quello succede in altri linguaggi", dirai tu. "Noi in Rust siamo diversi, abbiamo il borrow checker, abbiamo la safety!"

Certo. Il borrow checker ti protegge dai data race. Ma dimmi: ti protegge da un build.rs malevolo che, durante la compilazione, esfiltra le tue chiavi SSH? Ti protegge da una dipendenza che decide di mandare telemetria dei tuoi dati a un server sconosciuto? Ti protegge da un maintainer che, esausto dal lavoro non pagato, vende il controllo del progetto al miglior offerente senza dire niente a nessuno?

La risposta è no. Il compilatore non può aiutarti se il problema non è il codice unsafe, ma le intenzioni di chi l'ha scritto.

La supply chain del software è il Far West della sicurezza informatica. Ogni dipendenza è una porta aperta. E il bello (o il brutto, dipende dai punti di vista) è che spesso non ci pensiamo nemmeno. Aggiungiamo una crate perché "ha tante stelle su GitHub" o "tanti download su crates.io", come se la popolarità fosse garanzia di sicurezza o integrità.

Ma la popolarità non ti dice nulla su chi mantiene quel progetto, su quanto sia motivato a continuare, su quanto sia resistente alla corruzione o alla stanchezza. Ogni dipendenza che aggiungi è un potenziale cavallo di Troia. E la cosa più spaventosa? Probabilmente non te ne accorgeresti nemmeno finché non è troppo tardi.

L'Abbandono: La Tragedia Silenziosa

Poi c'è lo scenario più sottile e più comune: l'abbandono.

Trovi una crate perfetta. Fa esattamente quello che ti serve. Il codice è pulito, i test passano, la documentazione è buona. La aggiungi al progetto. Tutto funziona. Per sei mesi, un anno, due anni.

Poi un giorno apri una issue perché hai trovato un edge case. Nessuna risposta. Ne apri un'altra. Silenzio. Guardi la data dell'ultimo commit: tre anni fa. Guardi gli altri issue aperti: decine, tutti senza risposta.

Il maintainer è sparito. Forse ha cambiato lavoro, forse ha perso interesse, forse è semplicemente bruciato dal dover mantenere gratis un progetto che usano migliaia di aziende che non contribuiscono mai.

E ora? La community Rust ha iniziato a discutere di policy per le crate abbandonate, di come passare la manutenzione in modo più fluido, di come gestire questi casi. Ma sul campo, quando ti capita davvero, il risultato pratico è semplice: o forki il progetto e te lo mantieni da solo (con tutto il lavoro che comporta), o lo sostituisci (e buona fortuna a trovare qualcosa di compatibile), o lo riscrivi da zero (quello che avresti potuto fare dall'inizio, se solo non fossi stato "pigro").

In ogni caso, sei TU che ti ritrovi a gestire il problema.

Il Patto Faustiano

Mefistofele offre a Faust la conoscenza universale in cambio della sua anima. Le dipendenze ci offrono potenza immediata in cambio del nostro controllo futuro.

È un deal che facciamo costantemente, spesso inconsapevolmente. Cargo add e via, abbiamo appena barattato due ore di sviluppo oggi contro potenziali giorni o settimane di debugging domani.

Non sto dicendo che dovremmo smettere di usare dipendenze. Sarebbe stupido e controproducente. Ma sto dicendo che dovremmo smettere di trattarle come soluzioni gratuite e senza conseguenze.

Ogni dipendenza ha un costo. Il fatto che questo costo non si manifesti immediatamente non significa che non esista. È come il debito con gli interessi: più lo ignori, più crescono.

Quindi? Che Facciamo?

Non ho una soluzione magica. Se l'avessi, probabilmente la pacchettizzerei in una crate e la metterei su crates.io, creando una meta-dipendenza infinitamente ironica.

Ma ho qualche pensiero:

Primo: smetti di aggiungere dipendenze in automatico. Ogni volta che stai per scrivere cargo add, fermati e chiediti: "Ho davvero bisogno di questo? Potrei scriverlo io in tempo ragionevole? Se si rompe, sono almeno in grado di orientarmi nel codice per capire cosa sta succedendo?".

Attenzione: non sto dicendo che devi saper reimplementare tutto. Ci sono dipendenze critiche - crypto, TLS, database driver, HTTP stack - che nessuno dovrebbe mai provare a scrivere da zero, ma che sono mantenute da team solidi, con auditing costante e community ampie. Il punto non è "se non puoi fixarla non usarla", ma "se nessuno nel team è in grado neanche di orientarsi in quel codice in caso di emergenza, forse la stai usando in modo troppo fiducioso".

Secondo: se aggiungi una dipendenza, aprila e leggila. Non tutta, non sei pazzo. Ma almeno i file principali, le API pubbliche, le decisioni architetturali fondamentali. Impiega un pomeriggio a capire come funziona. Quel pomeriggio potrebbe risparmiarti una settimana di inferno in futuro.

Terzo: nel tuo team, ogni dipendenza dovrebbe avere un "owner mentale". Qualcuno che l'ha letta, che la capisce, che potrebbe forkare e patchare se necessario. Se nessuno vuole assumersi questa responsabilità, forse quella dipendenza è un problema.

Quarto: preferisci dipendenze piccole, focalizzate, leggibili a mostri monolitici. In Rust siamo fortunati: l'ecosistema tende verso crate piccole e composibili. Sfrutta questa filosofia. Una dipendenza di 500 righe è infinitamente più gestibile di una di 50.000.

Quinto: ricordati sempre che nel mondo Rust, dove il compilatore ci protegge da tanti errori, le dipendenze rimangono l'ultimo regno del caos. Il borrow checker non può aiutarti se il problema è in codice che non hai scritto tu e che non capisci.

La Vera Domanda

Alla fine, la domanda non è "Posso evitare questa dipendenza?", ma "Sono disposto a pagare il prezzo quando verrà il momento?".

Perché il momento arriverà. Forse tra un mese, forse tra un anno, forse tra cinque. Ma arriverà. E quando arriverà, sarai solo tu, il tuo codice, e un bug in mezzo a migliaia di righe scritte da qualcun altro.

In quel momento, capirai il vero costo delle dipendenze. Non sono i megabyte di disco che occupano o i millisecondi in più di compilazione. È la perdita di controllo. È la delega di responsabilità. È il debito tecnico travestito da comodità.

Ogni volta che aggiungi una dipendenza, stai facendo una scommessa: scommetti che il tempo che risparmi ora vale più del dolore potenziale futuro. A volte è una buona scommessa. Spesso no.

Il progetto zero-dipendenze è un estremismo inutile. Ma il progetto che tira dentro tutto Crates.io "perché tanto è gratis" è altrettanto folle.

La virtù sta nel mezzo consapevole. Nel riconoscere che ogni dipendenza è un patto faustiano, e nel decidere deliberatamente quali patti siamo disposti a fare.

Perché alla fine, quando il tuo software esploderà (e lo farà, è solo questione di tempo), la domanda non sarà "Di chi è la colpa?". La domanda sarà "Tu sapevi cosa stavi importando?".

E se la risposta è no, forse il problema non era la dipendenza.

Eri tu.

P.S.: Dopo aver scritto questo articolo, ho controllato le dipendenze del mio ultimo progetto. 6 dirette, 202 transitive. Non so nemmeno cosa facciano la metà di queste. Forse dovrei cominciare a praticare quello che predico. O forse no. Dopotutto, che potrebbe mai andare storto?

L'IA nella Programmazione: Strumento o Stampella?

Marco Bollero — Sun, 18 Jan 2026 08:53:28 +0000

Negli ultimi anni abbiamo assistito all'esplosione di strumenti di intelligenza artificiale per lo sviluppo software: GitHub Copilot, ChatGPT, Claude e tanti altri. Ma mentre questi strumenti diventano sempre più pervasivi, una domanda diventa urgente: li stiamo usando nel modo giusto? O stiamo crescendo una generazione di programmatori che sanno usare l'IA ma non sanno programmare?

In questo articolo voglio condividere la mia visione su dove l'IA può essere un alleato prezioso e dove invece rischia di trasformarsi in una stampella che impedisce la crescita professionale.

Il Problema: L'Outsourcing del Pensiero

Parliamoci chiaro: sempre più spesso osservo programmatori, soprattutto alle prime armi, che affrontano ogni problema copiando la richiesta in un'IA e incollando il codice risultante. Zero riflessione, zero comprensione, zero apprendimento. È come se stessimo assistendo a una sorta di "outsourcing del pensiero" – il problema non è più da risolvere, ma da delegare.

Un Problema Vecchio, ma Amplificato

Questo problema non è nato con l'IA. Chi non ha mai copiato codice da StackOverflow senza capirlo completamente? Chi non ha mai preso una soluzione funzionante e l'ha incollata nel proprio progetto senza davvero comprendere perché la propria versione non funzionava?

Il problema del "copia-incolla senza comprensione" esiste da quando esistono i forum di programmazione. La differenza cruciale è che allora c'erano dei "freni naturali" incorporati nel processo.

Quando cercavi su internet, dovevi:

Leggere thread di discussioni
Capire il contesto del problema di qualcun altro
Vedere la conversazione tra chi chiedeva e chi rispondeva
Adattare manualmente il codice alla tua situazione specifica

Anche se alla fine copiavi, c'era comunque un minimo di elaborazione cognitiva nel mezzo. Dovevi leggere, interpretare, adattare.

Con l'IA, questo processo si è compresso a: scrivo la domanda, ricevo il codice perfettamente formattato per il mio caso specifico, lo incollo. Fine. Il ciclo è così rapido e fluido che bypassa completamente qualsiasi forma di riflessione.

Inoltre, su StackOverflow trovavi non solo il codice, ma anche:

Spiegazioni del perché quella soluzione funzionava
Discussioni nei commenti sui pro e contro
Alternative proposte da altri utenti

Era un ambiente che, anche involontariamente, incoraggiava l'apprendimento attraverso il confronto di idee. L'IA ti dà la risposta diretta, pulita, senza esporti al dibattito e alla complessità del ragionamento. È tremendamente più efficiente, ma anche tremendamente più pericolosa per chi sta imparando.

L'Analogia della Calcolatrice

Immaginate un bambino alle elementari che deve imparare le addizioni. Se ogni volta che deve fare 7 + 5 prende la calcolatrice, cosa succede?

Non imparerà mai a fare i calcoli mentalmente. Non svilupperà il senso del numero. Non capirà il ragionamento matematico sottostante. E quando si troverà in una situazione dove la calcolatrice non c'è, sarà completamente perso.

La stessa cosa vale per la programmazione. Se ogni volta che devi implementare un algoritmo, risolvere un bug o strutturare un'applicazione chiedi all'IA, non stai sviluppando le competenze fondamentali del programmatore.

Copiare Senza Garanzie

C'è un altro parallelo interessante: copiare il compito a scuola. Quando copi da qualcuno, non hai garanzia che quella soluzione sia corretta. Potresti star copiando da chi ne sa quanto te, o anche meno.

Con l'IA è peggio: l'IA può generare codice che compila, che sembra funzionare, ma che nasconde bug sottili, vulnerabilità di sicurezza o inefficienze mostruose. Se non hai le competenze per capire quel codice, come fai a sapere se è buono o pessimo?

Cosa Perdiamo Veramente

Quando deleghiamo il ragionamento all'IA, perdiamo tre cose fondamentali:

La capacità di problem-solving: Programmare non è solo scrivere sintassi corretta, è saper analizzare un problema, scomporlo, trovare soluzioni creative. Se l'IA pensa al posto tuo, non sviluppi mai questa abilità.

L'originalità e la creatività: Il codice dell'IA è, per definizione, una ricombinazione di pattern esistenti. Non può essere veramente innovativo. Se vuoi inventare soluzioni nuove a problemi vecchi, devi coltivare il tuo modo di pensare, la tua prospettiva unica.

La capacità di debugging e manutenzione: Questo è cruciale. Se non hai scritto tu il codice, se non lo capisci profondamente, come fai a debuggarlo quando inevitabilmente si rompe? Come lo ottimizzi? Come lo adatti quando i requisiti cambiano?

Gli Usi Corretti dell'IA

Ora, attenzione: non sto dicendo che l'IA sia inutile o dannosa in assoluto. Anzi! Ci sono modi eccellenti di usare questi strumenti.

1. L'IA come Tutor Personale

L'IA può essere un tutor straordinario per l'apprendimento. Stai imparando un nuovo linguaggio? Chiedi all'IA di spiegarti i concetti, di mostrarti esempi, di chiarire le differenze tra approcci diversi.

Esempi pratici:

"Spiegami la differenza tra una lista e una tupla in Python"
"Come funziona il sistema dei trait in Rust?"
"Quali sono i vantaggi del pattern Observer rispetto al pattern Publisher-Subscriber?"

Qui l'IA non sta scrivendo codice per te, sta fungendo da insegnante. La differenza è sottile ma cruciale: stai usando l'IA per imparare a fare qualcosa, non per farlo al posto tuo.

2. Comprendere Algoritmi Classici

Vuoi capire come funziona il Quicksort? Chiedi all'IA di spiegartelo passo passo, magari con un esempio visivo. Questo è apprendimento attivo, non delega passiva.

3. Supporto nella Documentazione

Hai scritto tu un pezzo di codice complesso e vuoi documentarlo bene? L'IA può aiutarti a strutturare la documentazione, suggerire cosa includere, persino generare i commenti di base che poi tu rifinisci.

Qui il lavoro intellettuale l'hai fatto tu, l'IA ti sta solo aiutando nella parte "noiosa" del processo.

4. Generazione di Test

Hai implementato una funzione e vuoi testarla a fondo? Chiedi all'IA di generare casi di test, inclusi edge cases che potresti non aver considerato.

Anche qui: tu hai scritto il codice, capisci cosa fa, e stai usando l'IA per una verifica più completa. Il codice di produzione resta frutto del tuo ragionamento.

La Regola d'Oro

Usa l'IA per imparare, capire, verificare, documentare. Non usarla per sostituire il tuo pensiero critico e la tua capacità di risolvere problemi.

L'IA dovrebbe essere come un libro di testo avanzato, non come un compagno di classe a cui copiare i compiti.

Le Questioni Legali ed Etiche

C'è un aspetto che molti sottovalutano, ma che è fondamentale: le questioni legali e di licenze.

Il Problema delle Licenze

Le IA generative sono state addestrate su enormi quantità di codice disponibile su internet. Molto di questo codice è open source, con licenze specifiche come GPL, MIT, Apache e così via.

La domanda da un milione di dollari è: quando un'IA genera codice ispirandosi a codice con cui è stata addestrata, quel codice nuovo è da considerarsi "derivato" dal codice originale?

Se la risposta è sì, ci sono problemi. Le licenze copyleft come la GPL richiedono che il codice derivato mantenga la stessa licenza. Questo significa che se usi codice generato da un'IA addestrata su codice GPL, potresti essere obbligato a rilasciare il tuo intero progetto con licenza GPL.

Una Zona Grigia Normativa

Al momento, questa è una zona grigia. Ci sono cause legali in corso, e il quadro normativo è in evoluzione. Diverse aziende hanno già vietato l'uso di IA generative per il codice di produzione proprio per questi rischi.

Se lavorate per un'azienda e generate codice con un'IA, state potenzialmente introducendo rischi legali enormi. L'azienda potrebbe trovarsi esposta a contenziosi per violazione di copyright o licenze.

E non sto nemmeno parlando dei casi (rari ma documentati) in cui l'IA riproduce quasi letteralmente pezzi di codice del suo training set, magari inclusi commenti e nomi di variabili originali. In quei casi non c'è dubbio: è una copia diretta.

L'Etica della Formazione Professionale

C'è anche una questione etica più ampia: come comunità, abbiamo la responsabilità di formare programmatori competenti. Se normalizziamo l'uso dell'IA come sostituto del ragionamento, stiamo danneggiando la qualità complessiva della professione.

Verso una Visione Equilibrata

L'IA non sparirà. Anzi, diventerà sempre più pervasiva. E non è nemmeno desiderabile eliminarla completamente dagli strumenti di sviluppo. Il punto è trovare il giusto equilibrio.

Quattro Principi Guida

Ecco la mia proposta di linee guida per un uso responsabile dell'IA:

Primo principio – Impara prima le basi senza IA: Se stai iniziando, se stai imparando un nuovo linguaggio o paradigma, fallo senza assistenza AI. Sporca le mani, sbaglia, debugga, soffri un po'. È così che si impara davvero.

Secondo principio – Usa l'IA per accelerare, non per sostituire: Una volta che sai fare qualcosa, l'IA può aiutarti a farlo più velocemente. Ma la comprensione deve venire prima.

Terzo principio – Verifica sempre: Mai, e ripeto mai, copiare codice dall'IA senza capirlo completamente. Leggilo, analizzalo, testalo, verifica che faccia esattamente quello che deve fare.

Quarto principio – L'IA come amplificatore di competenza: Più sei bravo, più valore puoi estrarre dall'IA. Un programmatore esperto usa l'IA in modo chirurgico per compiti specifici. Un principiante che delega tutto all'IA resta un principiante per sempre.

Il Mio Workflow Personale

Vi racconto come uso io l'IA nel mio lavoro quotidiano:

Cosa faccio:

Lo uso per esplorare API o librerie nuove: "Come si usa questa funzione?" o "Mostrami un esempio di configurazione"
Lo uso per brainstorming architetturale: "Quali sono i pro e contro di questo approccio?" (ma la decisione finale è sempre mia)
Lo uso per generare test di base, che poi espando e raffino manualmente
Lo uso per la documentazione, ma solo dopo che il codice è scritto e funzionante
Se mi serve un algoritmo classico, chiedo lo pseudocodice o una descrizione del funzionamento, non l'implementazione completa. In questo modo la "trasformazione" in codice reale nel mio contesto specifico resta sotto il mio controllo

Cosa NON faccio:

Non uso l'IA per scrivere la logica core dell'applicazione
Non uso l'IA per risolvere bug complessi
Non uso l'IA per implementare algoritmi che dovrei conoscere

La Competenza è Insostituibile

Ricordate: l'IA è uno strumento potentissimo, ma è solo uno strumento. La competenza, la comprensione profonda, la capacità di pensare in modo critico e creativo – queste cose possono venire solo dall'esperienza, dallo studio, dall'errore e correzione.

Non c'è scorciatoia per diventare un bravo programmatore.

Conclusione

L'IA nella programmazione può essere un alleato prezioso se usata per imparare, approfondire, verificare e documentare. Diventa un problema quando sostituisce il tuo pensiero critico e ti impedisce di sviluppare competenze reali.

Il mio appello, soprattutto a chi sta iniziando: non abbiate fretta. La programmazione è un'abilità che si costruisce con il tempo, con la pratica deliberata, con gli errori. Ogni problema che risolvete da soli è un mattoncino che aggiungete alle vostre competenze.

L'IA sarà sempre lì, pronta ad aiutarvi. Ma prima dovete essere voi a sapere dove state andando.

Guida Completa: Neovim 0.11 IDE per Rust su Ubuntu/MacOS

Marco Bollero — Wed, 15 Oct 2025 13:37:04 +0000

Benvenuto in questa guida completa all'installazione e alla configurazione di Neovim 0.11 per lo sviluppo in Rust! 🦀

Se sei uno sviluppatore Rust alla ricerca di un editor di testo che sia allo stesso tempo leggero, veloce e incredibilmente personalizzabile, Neovim è la scelta perfetta. Dimentica i pesanti IDE tradizionali: con questa guida, trasformeremo Neovim in un ambiente di sviluppo Rust moderno e produttivo, su misura per le tue esigenze.

In questa guida vedremo come:

Installare l'ultima versione di Neovim (0.11).

Configurare da zero un ambiente di sviluppo minimale utilizzando Lua.

Integrare rust-analyzer tramite il Language Server Protocol (LSP) nativo di Neovim per ottenere funzionalità da IDE come l'autocompletamento, la diagnostica in tempo reale e la navigazione del codice.

Impostare il syntax highlighting con Tree-sitter per un'analisi del codice più precisa e veloce.

Alla fine di questo percorso, avrai una configurazione Neovim funzionale e performante, pronta per affrontare qualsiasi progetto Rust. Iniziamo!

PS - Altrimenti puoi semplicemente eseguire questi comandi:

cd $HOME/.config/
mv nvim nvim.bkp_ # Crea backup configurazione corrente
git clone git@github.com:marc0x71/nvim_config_rust.git nvim

e avrai tutto già installato e pronto all'uso! 🤗🦀

Prerequisiti e Dipendenze di Sistema

Installazione su GNU/Linux (Ubuntu)

Prima di iniziare, installiamo tutte le dipendenze necessarie:

# Aggiorna il sistema
sudo apt update && sudo apt upgrade -y

# Dipendenze per i plugin
sudo apt install -y ripgrep fd-find

# Build essentials (necessari per compilare parser Treesitter e alcune estensioni Rust)
sudo apt install -y build-essential git curl

# Node.js (opzionale, necessario solo per alcuni LSP non-Rust)
sudo apt install -y nodejs

# Creiamo un symlink per fd (su Ubuntu si chiama fdfind)
sudo ln -s $(which fdfind) /usr/local/bin/fd 2>/dev/null || true

MacOS

Su macOS useremo Homebrew come package manager:

# Installa Homebrew se non già installato
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Installa Xcode Command Line Tools (contiene gcc, git, etc.)
xcode-select --install

# Dipendenze per i plugin
brew install ripgrep fd

# Node.js (opzionale, utile per altri linguaggi)
brew install node

Spiegazione delle dipendenze:

ripgrep: ricerca velocissima nei file, usata da Telescope
fd: alternativa moderna a find, usata da Telescope
build-essential: gcc e g++ necessari per compilare i parser Treesitter
Node.js: opzionale, ma utile se userai altri linguaggi oltre a Rust

Installazione di Neovim 0.11

Installazione su MacOS

Per eseguire l'installazione di NeoVim, basterà:

brew install neovim

Installazione su GNU/Linux (Ubuntu)

Per questa guida prendiamo come riferimento la distribuzione GNU/Linux Ubuntu.

Installiamo Neovim tramite snap:

# Installa Neovim 0.11 tramite snap (flag --classic per accesso completo al sistema)
sudo snap install nvim --classic

# Verifichiamo l'installazione
nvim --version

Dovresti vedere output simile a:

NVIM v0.11.4
Build type: Release
...

Perché usare snap?

✅ Installazione rapida (pochi secondi vs 10-15 minuti di compilazione)
✅ Sempre aggiornato al latest stable
✅ Aggiornamenti automatici gestiti da snap
✅ Nessuna dipendenza di build necessaria

Nota: Il flag --classic è necessario perché Neovim deve accedere liberamente ai file del sistema per funzionare come editor.

Metodo alternativo: Compilazione dai sorgenti

Se preferisci compilare dai sorgenti per avere il controllo completo, su Ubuntu ti servirà:

# Installa dipendenze di build
sudo apt install -y ninja-build gettext cmake unzip

mentre su MacOS:

# Installa dipendenze di build
brew install ninja cmake gettext

Possiamo ora compilare NeoVim per il nostro sistema:

# Scarica e compila
mkdir -p ~/build && cd ~/build
git clone https://github.com/neovim/neovim.git
cd neovim
git checkout v0.11.4
make CMAKE_BUILD_TYPE=Release
sudo make install

Pro: Controllo totale sulla versione e opzioni di build

Contro: Richiede 10-15 minuti e più dipendenze

Installazione Toolchain Rust

Installiamo Rust e i componenti necessari per lo sviluppo:

# Installa rustup (gestore della toolchain Rust)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Ricarichiamo il PATH
source "$HOME/.cargo/env"

# Installiamo i componenti necessari se non precedentemente installati
rustup component add rust-analyzer  # LSP per Rust
rustup component add rustfmt         # Formatter
rustup component add clippy          # Linter

# Verifichiamo l'installazione
rustc --version
cargo --version
rust-analyzer --version

Nota importante:

rust-analyzer è il language server che fornisce autocompletamento, diagnostica e altre funzionalità IDE (LSP)
codelldb (debugger) verrà installato automaticamente tramite Mason (plugin di Neovim) nella sezione successiva

Struttura della Configurazione

Creiamo la struttura delle directory per la configurazione di Neovim:

mkdir -p ~/.config/nvim/lua/plugins

La struttura finale sarà:

~/.config/nvim/
├── init.lua                 # File principale
└── lua/
    └── plugins/
        ├── mason.lua        # Config Mason (package manager)
        ├── cmp.lua          # Config nvim-cmp (autocompletamento)
        ├── treesitter.lua   # Config Treesitter
        ├── telescope.lua    # Config Telescope
        ├── oil.lua          # Config Oil
        ├── rustacean.lua    # Config Rustaceanvim
        ├── gitsigns.lua     # Config Gitsigns (Git integration)
        ├── fugitive.lua     # Config Fugitive (Git commands)
        ├── which-key.lua    # Config Which-Key (keybinding hints)
        ├── trouble.lua      # Config Trouble (diagnostics list)
        ├── fidget.lua       # Config Fidget (LSP notifications)
        ├── lualine.lua      # Config Lualine (statusline)
        └── colorscheme.lua  # Config Gruvbox Material

Configurazione Lazy.nvim

Creiamo il file ~/.config/nvim/init.lua:

-- init.lua
-- Configurazione base di Neovim

-- Opzioni generali
vim.g.mapleader = " "  -- Space come leader key
vim.g.maplocalleader = " "

-- Impostazioni UI
vim.opt.number = true          -- Numeri di riga
vim.opt.relativenumber = true  -- Numeri relativi
vim.opt.mouse = 'a'            -- Abilita mouse
vim.opt.ignorecase = true      -- Ignora case nella ricerca
vim.opt.smartcase = true       -- Case-sensitive se maiuscole presenti
vim.opt.hlsearch = false       -- Non evidenziare ricerche
vim.opt.wrap = false           -- Non wrappare le righe
vim.opt.breakindent = true     -- Mantieni indentazione quando wrapped
vim.opt.tabstop = 4            -- Tab = 4 spazi
vim.opt.shiftwidth = 4         -- Indentazione = 4 spazi
vim.opt.expandtab = true       -- Usa spazi invece di tab
vim.opt.termguicolors = true   -- Abilita colori 24-bit

-- Clipboard di sistema
vim.opt.clipboard = 'unnamedplus'

-- Salvataggio automatico undo
vim.opt.undofile = true

-- Tempo di aggiornamento ridotto
vim.opt.updatetime = 250
vim.opt.signcolumn = 'yes'

-- Bootstrap lazy.nvim
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=stable",
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

-- Setup lazy.nvim con i plugin
require("lazy").setup({
  -- Importa tutti i file dalla directory plugins
  { import = "plugins" },
}, {
  checker = {
    enabled = true,  -- Controlla automaticamente aggiornamenti
    notify = false,  -- Non notificare
  },
  change_detection = {
    notify = false,  -- Non notificare cambiamenti config
  },
})

-- Toggle diagnostics
local diagnostics_active = true
local toggle_diagnostics = function()
  diagnostics_active = not diagnostics_active
  if diagnostics_active then
    vim.api.nvim_echo({ { "Show diagnostics" } }, false, {})
    vim.diagnostic.enable()
  else
    vim.api.nvim_echo({ { "Disable diagnostics" } }, false, {})
    vim.diagnostic.enable(false)
  end
end

local function open_terminal(command)
  command = command or os.getenv("SHELL")
  if os.getenv("TMUX") then
    if os.getenv("POETRY_ACTIVE") then
      command = "poetry run " .. command
    end
    --  TMUX session active
    print("silent !tmux split-window -l 10 " .. command .. "<cr>")
    vim.cmd("silent !tmux split-window -l 10 " .. command)
  else
    vim.cmd.vnew()
    vim.cmd.term(command)
    vim.cmd.wincmd("J")
    vim.api.nvim_win_set_height(0, 15)
  end
end

-- Keymaps generali
vim.keymap.set('n', '<leader>w', '<cmd>write<cr>', { desc = 'Save' })
vim.keymap.set('n', '<leader>q', '<cmd>quit<cr>', { desc = 'Quit' })
vim.keymap.set("n", "<M-n>", "<cmd>bnext<CR>", {})
vim.keymap.set("n", "<M-p>", "<cmd>bprev<CR>", {})
vim.keymap.set("n", "<Esc>", "<cmd>nohlsearch<CR>")
vim.keymap.set("t", "<esc><esc>", "<c-\\><c-n>", {})

vim.keymap.set("n", "<leader>tt", function()
  open_terminal()
end, { desc = "[T]erminal " })


-- Keymaps per diagnostics
vim.keymap.set('n', '[d', vim.diagnostic.goto_prev, { desc = 'Previous diagnostic' })
vim.keymap.set('n', ']d', vim.diagnostic.goto_next, { desc = 'Next diagnostic' })
vim.keymap.set('n', '<leader>e', vim.diagnostic.open_float, { desc = 'Show diagnostic error' })
vim.keymap.set("n", "<leader>xi", toggle_diagnostics, { desc = "Toggle [i]nline diagnostic" })

Spiegazione keymaps diagnostics:

<leader>e (Space + e) mostra popup con errore/warning della riga corrente
<leader>xi (Space + xi) abilita/disabilita la visualizzazione degli errori/warning
]d salta al prossimo diagnostic (errore/warning)
[d salta al diagnostic precedente

Mason (`~/.config/nvim/lua/plugins/mason.lua`)

return {
  "williamboman/mason.nvim",
  dependencies = {
    "williamboman/mason-lspconfig.nvim",
    "jay-babu/mason-nvim-dap.nvim",
  },
  config = function()
    local mason = require("mason")
    local mason_lspconfig = require("mason-lspconfig")
    local mason_nvim_dap = require("mason-nvim-dap")

    -- Setup Mason
    mason.setup({
      ui = {
        icons = {
          package_installed = "✓",
          package_pending = "➜",
          package_uninstalled = "✗"
        }
      }
    })

    -- Setup Mason LSPConfig
    mason_lspconfig.setup({
      -- Questa lista è vuota perché per Rust usiamo rustaceanvim
      -- che gestisce rust-analyzer automaticamente
      ensure_installed = {},
    })

    -- Setup Mason DAP - installa automaticamente codelldb
    mason_nvim_dap.setup({
      ensure_installed = { "codelldb" },
      automatic_installation = true,
    })

    -- Keymap per aprire Mason
    vim.keymap.set('n', '<leader>m', '<cmd>Mason<cr>', { desc = 'Open Mason' })
  end,
}

Spiegazione:

Mason è un package manager per Neovim che gestisce LSP servers, DAP adapters, linters e formatters
mason-nvim-dap installa automaticamente codelldb al primo avvio
Non includiamo rust-analyzer qui perché rustaceanvim lo usa direttamente dal sistema

nvim-cmp (`~/.config/nvim/lua/plugins/cmp.lua`)

return {
  "hrsh7th/nvim-cmp",
  event = "InsertEnter",
  dependencies = {
    -- Snippet Engine
    {
      "L3MON4D3/LuaSnip",
      version = "v2.*",
      build = "make install_jsregexp",
    },

    -- Autocompletion sources
    "saadparwaiz1/cmp_luasnip",     -- Snippet completions
    "hrsh7th/cmp-nvim-lsp",         -- LSP completions
    "hrsh7th/cmp-buffer",           -- Buffer completions
    "hrsh7th/cmp-path",             -- Path completions
    "hrsh7th/cmp-nvim-lua",         -- Neovim Lua API completions

    -- Snippet collection (optional)
    "rafamadriz/friendly-snippets",
  },
  config = function()
    local cmp = require("cmp")
    local luasnip = require("luasnip")

    -- Carica snippet da friendly-snippets
    require("luasnip.loaders.from_vscode").lazy_load()

    cmp.setup({
      snippet = {
        expand = function(args)
          luasnip.lsp_expand(args.body)
        end,
      },

      mapping = cmp.mapping.preset.insert({
        ["<C-k>"] = cmp.mapping.select_prev_item(), -- Seleziona precedente
        ["<C-j>"] = cmp.mapping.select_next_item(), -- Seleziona successivo
        ["<C-b>"] = cmp.mapping.scroll_docs(-4),
        ["<C-f>"] = cmp.mapping.scroll_docs(4),
        ["<C-Space>"] = cmp.mapping.complete(),     -- Mostra completamento
        ["<C-e>"] = cmp.mapping.abort(),            -- Chiudi
        ["<CR>"] = cmp.mapping.confirm({ select = false }), -- Conferma selezione

        -- Tab per navigare snippet
        ["<Tab>"] = cmp.mapping(function(fallback)
          if cmp.visible() then
            cmp.select_next_item()
          elseif luasnip.expand_or_jumpable() then
            luasnip.expand_or_jump()
          else
            fallback()
          end
        end, { "i", "s" }),

        ["<S-Tab>"] = cmp.mapping(function(fallback)
          if cmp.visible() then
            cmp.select_prev_item()
          elseif luasnip.jumpable(-1) then
            luasnip.jump(-1)
          else
            fallback()
          end
        end, { "i", "s" }),
      }),

      -- Sources per autocompletamento (ordine = priorità)
      sources = cmp.config.sources({
        { name = "nvim_lsp" },   -- Da LSP
        { name = "luasnip" },    -- Da snippet
        { name = "buffer" },     -- Da buffer corrente
        { name = "path" },       -- Da filesystem
        { name = "nvim_lua" },   -- Da Neovim Lua API
      }),

      -- Formattazione voci completamento
      formatting = {
        format = function(entry, item)
          -- Mostra da quale source proviene
          item.menu = ({
            nvim_lsp = "[LSP]",
            luasnip = "[Snippet]",
            buffer = "[Buffer]",
            path = "[Path]",
            nvim_lua = "[Lua]",
          })[entry.source.name]
          return item
        end,
      },
    })
  end,
}

Spiegazione:

nvim-cmp fornisce autocompletamento intelligente con multiple sources
LuaSnip è il motore per gli snippet
Configurato per integrarsi perfettamente con rust-analyzer LSP

Gitsigns (`~/.config/nvim/lua/plugins/gitsigns.lua`)

return {
  "lewis6991/gitsigns.nvim",
  event = { "BufReadPre", "BufNewFile" },
  config = function()
    require("gitsigns").setup({
      signs = {
        add          = { text = '┃' },
        change       = { text = '┃' },
        delete       = { text = '_' },
        topdelete    = { text = '‾' },
        changedelete = { text = '~' },
        untracked    = { text = '┆' },
      },

      on_attach = function(bufnr)
        local gs = package.loaded.gitsigns

        -- Keymaps
        local function map(mode, l, r, opts)
          opts = opts or {}
          opts.buffer = bufnr
          vim.keymap.set(mode, l, r, opts)
        end

        -- Navigazione tra hunks
        map('n', ']c', function()
          if vim.wo.diff then return ']c' end
          vim.schedule(function() gs.next_hunk() end)
          return '<Ignore>'
        end, { expr = true, desc = 'Next Git hunk' })

        map('n', '[c', function()
          if vim.wo.diff then return '[c' end
          vim.schedule(function() gs.prev_hunk() end)
          return '<Ignore>'
        end, { expr = true, desc = 'Previous Git hunk' })

        -- Actions
        map('n', '<leader>hs', gs.stage_hunk, { desc = 'Stage hunk' })
        map('n', '<leader>hr', gs.reset_hunk, { desc = 'Reset hunk' })
        map('v', '<leader>hs', function() gs.stage_hunk {vim.fn.line('.'), vim.fn.line('v')} end, { desc = 'Stage hunk' })
        map('v', '<leader>hr', function() gs.reset_hunk {vim.fn.line('.'), vim.fn.line('v')} end, { desc = 'Reset hunk' })
        map('n', '<leader>hS', gs.stage_buffer, { desc = 'Stage buffer' })
        map('n', '<leader>hu', gs.undo_stage_hunk, { desc = 'Undo stage hunk' })
        map('n', '<leader>hR', gs.reset_buffer, { desc = 'Reset buffer' })
        map('n', '<leader>hp', gs.preview_hunk, { desc = 'Preview hunk' })
        map('n', '<leader>hb', function() gs.blame_line{full=true} end, { desc = 'Blame line' })
        map('n', '<leader>hd', gs.diffthis, { desc = 'Diff this' })
        map('n', '<leader>hD', function() gs.diffthis('~') end, { desc = 'Diff this ~' })

        -- Text object
        map({'o', 'x'}, 'ih', ':<C-U>Gitsigns select_hunk<CR>', { desc = 'Select hunk' })
      end,
    })
  end,
}

Spiegazione:

Mostra modifiche Git nella sign column (barra a sinistra)
Navigazione rapida tra modifiche con ]c e [c
Stage/reset hunks direttamente da Neovim
Preview delle modifiche inline

Fugitive (`~/.config/nvim/lua/plugins/fugitive.lua`)

return {
  "tpope/vim-fugitive",
  cmd = { "Git", "G", "Gdiffsplit", "Gread", "Gwrite", "Ggrep", "GMove", "GRename", "GDelete", "GBrowse" },
  keys = {
    { "<leader>gs", "<cmd>Git<cr>", desc = "Git status" },
    { "<leader>gc", "<cmd>Git commit<cr>", desc = "Git commit" },
    { "<leader>gp", "<cmd>Git push<cr>", desc = "Git push" },
    { "<leader>gl", "<cmd>Git pull<cr>", desc = "Git pull" },
    { "<leader>gb", "<cmd>Git blame<cr>", desc = "Git blame" },
    { "<leader>gd", "<cmd>Gdiffsplit<cr>", desc = "Git diff split" },
  },
}

Spiegazione:

Interfaccia completa a Git direttamente da Neovim
Comandi Git nativi (commit, push, pull, blame, diff)
Si integra perfettamente con Gitsigns

Which-Key (`~/.config/nvim/lua/plugins/which-key.lua`)

return {
  "folke/which-key.nvim",
  event = "VeryLazy",
  init = function()
    vim.o.timeout = true
    vim.o.timeoutlen = 300
  end,
  config = function()
    local wk = require("which-key")

    wk.setup({
      preset = "modern",
      win = {
        border = "rounded",
      },
    })

    -- Registra gruppi di keybindings
    wk.add({
      { "<leader>f", group = "find" },
      { "<leader>r", group = "rust" },
      { "<leader>g", group = "git" },
      { "<leader>h", group = "hunk" },
      { "<leader>d", group = "debug" },
      { "<leader>x", group = "diagnostics" },
    })
  end,
}

Spiegazione:

Mostra automaticamente popup con keybindings disponibili
Aiuta a scoprire e ricordare i comandi

Trouble (`~/.config/nvim/lua/plugins/trouble.lua`)

return {
  "folke/trouble.nvim",
  dependencies = { "nvim-tree/nvim-web-devicons" },
  cmd = { "Trouble" },
  keys = {
    { "<leader>xx", "<cmd>Trouble diagnostics toggle<cr>", desc = "Diagnostics (Trouble)" },
    { "<leader>xX", "<cmd>Trouble diagnostics toggle filter.buf=0<cr>", desc = "Buffer Diagnostics (Trouble)" },
    { "<leader>xs", "<cmd>Trouble symbols toggle focus=false<cr>", desc = "Symbols (Trouble)" },
    { "<leader>xl", "<cmd>Trouble lsp toggle focus=false win.position=right<cr>", desc = "LSP Definitions / references / ... (Trouble)" },
    { "<leader>xL", "<cmd>Trouble loclist toggle<cr>", desc = "Location List (Trouble)" },
    { "<leader>xQ", "<cmd>Trouble qflist toggle<cr>", desc = "Quickfix List (Trouble)" },
  },
  opts = {
    -- Configurazione opzionale
  },
}

Spiegazione:

Mostra lista organizzata di tutti gli errori/warning del progetto
Visualizzazione migliore della quickfix list di default
Integrazione con LSP per diagnostics, references, definitions

Fidget (`~/.config/nvim/lua/plugins/fidget.lua`)

return {
  "j-hui/fidget.nvim",
  opts = {
    notification = {
      window = {
        winblend = 0,  -- Trasparenza finestra (0-100)
        border = "none",
      },
    },
    progress = {
      display = {
        done_icon = "✓",
      },
    },
  },
}

Spiegazione:

Mostra notifiche LSP in basso a destra (es. "rust-analyzer: indexing...")
Progress indicator quando rust-analyzer sta analizzando il codice
Interfaccia pulita e non invasiva

Treesitter (`~/.config/nvim/lua/plugins/treesitter.lua`)

return {
  "nvim-treesitter/nvim-treesitter",
  build = ":TSUpdate",
  event = { "BufReadPost", "BufNewFile" },
  dependencies = {
    "nvim-treesitter/nvim-treesitter-textobjects",  -- Text objects avanzati
  },
  config = function()
    require("nvim-treesitter.configs").setup({
      -- Linguaggi da installare automaticamente
      ensure_installed = {
        "rust",
        "toml",
        "lua",
        "vim",
        "vimdoc",
        "markdown",
        "markdown_inline",
        "json",
        "yaml",
      },

      -- Installa parser in modo sincrono
      sync_install = false,

      -- Installazione automatica parser mancanti
      auto_install = true,

      -- Syntax highlighting
      highlight = {
        enable = true,
        additional_vim_regex_highlighting = false,
      },

      -- Indentazione basata su treesitter
      indent = {
        enable = true,
      },

      -- Selezione incrementale
      incremental_selection = {
        enable = true,
        keymaps = {
          init_selection = "<CR>",
          node_incremental = "<CR>",
          node_decremental = "<BS>",
          scope_incremental = "<TAB>",
        },
      },

      -- Text objects
      textobjects = {
        select = {
          enable = true,
          lookahead = true,
          keymaps = {
            ["af"] = "@function.outer",
            ["if"] = "@function.inner",
            ["ac"] = "@class.outer",
            ["ic"] = "@class.inner",
          },
        },
      },
    })
  end,
}

Telescope (`~/.config/nvim/lua/plugins/telescope.lua`)

return {
  "nvim-telescope/telescope.nvim",
  branch = "0.1.x",
  dependencies = {
    "nvim-lua/plenary.nvim",
    {
      "nvim-telescope/telescope-fzf-native.nvim",
      build = "make",  -- Compilazione per performance migliori
    },
  },
  config = function()
    local telescope = require("telescope")
    local actions = require("telescope.actions")

    telescope.setup({
      defaults = {
        path_display = { "truncate" },
        mappings = {
          i = {
            ["<C-k>"] = actions.move_selection_previous,
            ["<C-j>"] = actions.move_selection_next,
            ["<C-q>"] = actions.send_selected_to_qflist + actions.open_qflist,
          },
        },
      },
      pickers = {
        find_files = {
          hidden = true,  -- Mostra file nascosti
        },
      },
    })

    -- Carica estensione fzf
    telescope.load_extension("fzf")

    -- Keymaps
    local builtin = require("telescope.builtin")
    vim.keymap.set('n', '<leader>ff', builtin.find_files, { desc = 'Find Files' })
    vim.keymap.set('n', '<leader>fg', builtin.live_grep, { desc = 'Live Grep' })
    vim.keymap.set('n', '<leader>fb', builtin.buffers, { desc = 'Buffers' })
    vim.keymap.set('n', '<leader>fh', builtin.help_tags, { desc = 'Help Tags' })
    vim.keymap.set('n', '<leader>fr', builtin.lsp_references, { desc = 'LSP References' })
    vim.keymap.set('n', '<leader>fs', builtin.lsp_document_symbols, { desc = 'Document Symbols' })
  end,
}

Oil.nvim (`~/.config/nvim/lua/plugins/oil.lua`)

return {
  "stevearc/oil.nvim",
  dependencies = { "nvim-tree/nvim-web-devicons" },
  config = function()
    require("oil").setup({
      -- Colonne da mostrare
      columns = {
        "icon",
        "permissions",
        "size",
        "mtime",
      },

      -- Keymaps dentro oil
      keymaps = {
        ["g?"] = "actions.show_help",
        ["<CR>"] = "actions.select",
        ["<C-v>"] = "actions.select_vsplit",
        ["<C-s>"] = "actions.select_split",
        ["<C-t>"] = "actions.select_tab",
        ["<C-p>"] = "actions.preview",
        ["<C-c>"] = "actions.close",
        ["<C-r>"] = "actions.refresh",
        ["-"] = "actions.parent",
        ["_"] = "actions.open_cwd",
        ["`"] = "actions.cd",
        ["~"] = "actions.tcd",
        ["gs"] = "actions.change_sort",
        ["gx"] = "actions.open_external",
        ["g."] = "actions.toggle_hidden",
      },

      -- Mostra file nascosti di default
      view_options = {
        show_hidden = true,
      },
    })

    -- Apri oil con -
    vim.keymap.set("n", "-", "<CMD>Oil<CR>", { desc = "Open parent directory" })
  end,
}

Rustaceanvim (`~/.config/nvim/lua/plugins/rustacean.lua`)

return {
  "mrcjkb/rustaceanvim",
  version = "^5",
  ft = { "rust" },  -- Carica solo per file Rust
  config = function()
    vim.g.rustaceanvim = {
      -- LSP settings
      server = {
        on_attach = function(client, bufnr)
          -- Keymaps per LSP
          local opts = { buffer = bufnr, noremap = true, silent = true }

          vim.keymap.set('n', 'gd', vim.lsp.buf.definition, opts)
          vim.keymap.set('n', 'gD', vim.lsp.buf.declaration, opts)
          vim.keymap.set('n', 'gi', vim.lsp.buf.implementation, opts)
          vim.keymap.set('n', 'gr', vim.lsp.buf.references, opts)
          vim.keymap.set('n', 'K', vim.lsp.buf.hover, opts)
          vim.keymap.set('n', '<leader>rn', vim.lsp.buf.rename, opts)
          vim.keymap.set('n', '<leader>ca', vim.lsp.buf.code_action, opts)
          vim.keymap.set('n', '<leader>f', vim.lsp.buf.format, opts)

          -- Rustacean specific
          vim.keymap.set('n', '<leader>rd', '<cmd>RustLsp debuggables<cr>', opts)
          vim.keymap.set('n', '<leader>rr', '<cmd>RustLsp runnables<cr>', opts)
          vim.keymap.set('n', '<leader>rt', '<cmd>RustLsp testables<cr>', opts)
          vim.keymap.set('n', '<leader>re', '<cmd>RustLsp expandMacro<cr>', opts)
        end,

        default_settings = {
          ['rust-analyzer'] = {
            cargo = {
              allFeatures = true,
              loadOutDirsFromCheck = true,
              buildScripts = {
                enable = true,
              },
            },
            -- Usa 'check' invece di 'checkOnSave'
            check = {
              command = "clippy",  -- Usa clippy invece di check
            },
            procMacro = {
              enable = true,
            },
            diagnostics = {
              enable = true,
              experimental = {
                enable = true,
              },
            },
          },
        },
      },

      -- DAP (Debug Adapter Protocol)
      dap = {
        adapter = {
          type = "server",
          port = "${port}",
          executable = {
            command = vim.fn.stdpath("data") .. "/mason/bin/codelldb",
            args = { "--port", "${port}" },
          },
        },
      },
    }
  end,
  dependencies = {
    -- Plugin per debugging
    {
      "mfussenegger/nvim-dap",
      config = function()
        local dap = require("dap")

        -- Keymaps per debugging
        vim.keymap.set('n', '<F5>', dap.continue, { desc = 'Debug: Start/Continue' })
        vim.keymap.set('n', '<F10>', dap.step_over, { desc = 'Debug: Step Over' })
        vim.keymap.set('n', '<F11>', dap.step_into, { desc = 'Debug: Step Into' })
        vim.keymap.set('n', '<F12>', dap.step_out, { desc = 'Debug: Step Out' })
        vim.keymap.set('n', '<leader>b', dap.toggle_breakpoint, { desc = 'Debug: Toggle Breakpoint' })
      end,
    },

    -- UI per il debugger
    {
      "rcarriga/nvim-dap-ui",
      dependencies = { "nvim-neotest/nvim-nio" },
      config = function()
        local dap, dapui = require("dap"), require("dapui")

        dapui.setup()

        -- Apri/chiudi automaticamente UI
        dap.listeners.after.event_initialized["dapui_config"] = function()
          dapui.open()
        end
        dap.listeners.before.event_terminated["dapui_config"] = function()
          dapui.close()
        end
        dap.listeners.before.event_exited["dapui_config"] = function()
          dapui.close()
        end

        vim.keymap.set('n', '<leader>du', dapui.toggle, { desc = 'Debug: Toggle UI' })
      end,
    },
  },
}

6.9 Lualine (`~/.config/nvim/lua/plugins/lualine.lua`)

return {
  "nvim-lualine/lualine.nvim",
  dependencies = { "nvim-tree/nvim-web-devicons" },
  config = function()
    require("lualine").setup({
      options = {
        theme = "gruvbox-material",
        component_separators = { left = '|', right = '|' },
        section_separators = { left = '', right = '' },
        globalstatus = true,  -- Una statusline per tutte le finestre
      },
      sections = {
        lualine_a = { 'mode' },
        lualine_b = { 'branch', 'diff' },
        lualine_c = { 
          {
            'filename',
            path = 1,  -- 0 = solo nome, 1 = relativo, 2 = assoluto
          }
        },
        lualine_x = {
          {
            'diagnostics',
            sources = { 'nvim_diagnostic' },
            symbols = { error = ' ', warn = ' ', info = ' ', hint = ' ' },
          },
          'encoding',
          'fileformat',
          'filetype',
        },
        lualine_y = { 'progress' },
        lualine_z = { 'location' },
      },
      inactive_sections = {
        lualine_a = {},
        lualine_b = {},
        lualine_c = { 'filename' },
        lualine_x = { 'location' },
        lualine_y = {},
        lualine_z = {},
      },
      extensions = { 'fugitive', 'oil', 'trouble' },
    })
  end,
}

Gruvbox Material (`~/.config/nvim/lua/plugins/colorscheme.lua`)

return {
  "sainnhe/gruvbox-material",
  lazy = false,     -- Carica immediatamente
  priority = 1000,  -- Carica prima di altri plugin
  config = function()
    -- Configura il colorscheme
    vim.g.gruvbox_material_background = 'medium'  -- 'soft', 'medium', 'hard'
    vim.g.gruvbox_material_better_performance = 1
    vim.g.gruvbox_material_enable_italic = 1

    -- Applica il colorscheme
    vim.cmd.colorscheme('gruvbox-material')
  end,
}

Test e Verifica

Prima apertura di Neovim

nvim

Al primo avvio, Lazy.nvim installerà automaticamente tutti i plugin. Vedrai una finestra con il progresso dell'installazione. Mason installerà anche automaticamente codelldb in background.

Verifica installazione plugin

Dentro Neovim, digita:

:Lazy

Dovresti vedere tutti i plugin installati con segno di spunta verde.

Per verificare che codelldb sia stato installato:

:Mason

Dovresti vedere codelldb con il segno ✓ (installato).

Verifica Treesitter

:checkhealth nvim-treesitter

Test con progetto Rust

Crea un progetto di test:

cargo new test_project
cd test_project
nvim src/main.rs

Dovresti vedere:

✅ Syntax highlighting colorato
✅ Autocompletamento (premi Ctrl+Space)
✅ Diagnostica inline (errori/warning sottolineati)
✅ Hover documentation (premi K su una funzione)

Test debugging

Nel file src/main.rs, aggiungi:

fn main() {
    let x = 5;
    let y = 10;
    println!("Sum: {}", x + y);  // Metti breakpoint qui
}

Premi <leader>b sulla riga del println per aggiungere breakpoint
Premi <leader>rd per vedere opzioni di debug
Seleziona "Debug" e premi Enter
Usa F10 per step over, F11 per step into

Comandi Utili

Plugin Management (Lazy.nvim)

:Lazy - Apri interfaccia Lazy
:Lazy update - Aggiorna tutti i plugin
:Lazy sync - Installa/aggiorna/rimuovi plugin

Mason (Package Manager)

:Mason - Apri interfaccia Mason
:MasonInstall <package> - Installa un package
:MasonUninstall <package> - Rimuovi un package
<leader>m - Apri Mason

Autocompletamento (nvim-cmp)

Ctrl+Space - Trigger completamento manualmente
Ctrl+j/k - Naviga suggerimenti
Tab/Shift+Tab - Naviga snippet
Enter - Conferma selezione
Ctrl+e - Chiudi menu completamento

Telescope

<leader>ff - Find files
<leader>fg - Live grep (ricerca in tutti i file)
<leader>fb - Lista buffer aperti
<leader>fr - Trova riferimenti LSP
<leader>fs - Simboli del documento

Oil.nvim

- - Apri directory corrente
<CR> - Entra in directory/apri file
<C-s> - Apri in split orizzontale
<C-v> - Apri in split verticale
g. - Toggle file nascosti

LSP

gd - Go to definition
gr - Go to references
K - Hover documentation
<leader>rn - Rename symbol
<leader>ca - Code actions
<leader>f - Format document

Diagnostics

<leader>e - Show diagnostic popup (errore/warning riga corrente)
]d - Next diagnostic
[d - Previous diagnostic

Rust Specific

<leader>rr - Rust runnables (esegui main, esempi, etc.)
<leader>rt - Rust testables (esegui test)
<leader>rd - Rust debuggables (debug)
<leader>re - Expand macro

Debugging

<F5> - Start/Continue debug
<F10> - Step over
<F11> - Step into
<F12> - Step out
<leader>b - Toggle breakpoint
<leader>du - Toggle debug UI

Git (Gitsigns)

]c / [c - Next/Previous hunk
<leader>hs - Stage hunk
<leader>hr - Reset hunk
<leader>hS - Stage buffer
<leader>hp - Preview hunk
<leader>hb - Blame line
<leader>hd - Diff this
ih - Select hunk (text object)

Git (Fugitive)

<leader>gs - Git status
<leader>gc - Git commit
<leader>gp - Git push
<leader>gl - Git pull
<leader>gb - Git blame
<leader>gd - Git diff split

Which-Key

<leader> - Mostra tutti i keybindings del leader

Trouble (Diagnostics)

<leader>xx - Toggle diagnostics
<leader>xX - Toggle buffer diagnostics
<leader>xs - Toggle symbols
<leader>xl - Toggle LSP info
<leader>xQ - Toggle quickfix

Treesitter

:TSUpdate - Aggiorna parser
:TSInstall <lang> - Installa parser per linguaggio
<CR> in visual mode - Selezione incrementale

Troubleshooting

Problema: Treesitter non compila parser

# Installa dipendenze C
sudo apt install -y gcc g++

# In Neovim
:TSInstall rust

Warning: tree-sitter executable not found

Questo è un warning comune e completamente normale:

⚠️ WARNING tree-sitter executable not found (parser generator, only needed for :TSInstallFromGrammar)

Per eliminare il warning (opzionale):

# Installa tree-sitter CLI
cargo install tree-sitter-cli

Dopo l'installazione, riavvia Neovim e il warning sparirà. Ma ripeto: è puramente estetico, la funzionalità è già completa!

Warning: mini.icons is not installed

⚠️ WARNING mini.icons is not installed
✅ OK nvim-web-devicons is installed

Cosa significa:

which-key può usare mini.icons OPPURE nvim-web-devicons per le icone
La nostra config usa nvim-web-devicons (già installato con Oil e Trouble)
Il warning è solo informativo, le icone funzionano perfettamente

Problema: Telescope non trova file

# Verifica ripgrep e fd
which rg
which fd

# Ubuntu: Se mancano, reinstalla
sudo apt install ripgrep fd-find

# macOS: Se mancano, reinstalla
brew install ripgrep fd

Prossimi Passi e Personalizzazioni

Ora hai un IDE Rust completo e professionale! 🎉

Cosa hai ottenuto:

✅ Autocompletamento intelligente con nvim-cmp
✅ Integrazione Git completa (Gitsigns + Fugitive)
✅ Diagnostics organizzate (Trouble)
✅ Notifiche LSP eleganti (Fidget)
✅ Guida ai keybindings (Which-Key)
✅ Debugging visuale completo
✅ Syntax highlighting avanzato
✅ File explorer moderno (Oil)
✅ Ricerca potente (Telescope)
✅ Statusline informativa (Lualine)

Considera di aggiungere (opzionale):

toggleterm.nvim - Terminale integrato e toggleable
nvim-autopairs - Chiusura automatica di parentesi/virgolette
Comment.nvim - Commenta codice facilmente con gc
indent-blankline.nvim - Mostra guide di indentazione
nvim-colorizer.lua - Evidenzia codici colore nel codice
rust-tools.nvim - Tools extra per Rust (hover actions, ecc.)

Risorse utili:

Documentazione Neovim: :help o https://neovim.io/doc/
rust-analyzer docs: https://rust-analyzer.github.io/
Awesome Neovim: https://github.com/rockerBOO/awesome-neovim

Buon coding! 🦀

Aumentare la produttività con Tmux e Vim

Marco Bollero — Tue, 28 Jan 2025 09:00:00 +0000

L'idea

Tanto tempo fa, in una galassia lontana lontana...

Ops, scusate, è che quando scrivo "tanto tempo fa", poi le dita vanno avanti da sole 😃

Dicevamo... tempo fa, mi sono imbattuto in un video del noto youtuber ThePrimeagen (vi consiglio di seguirlo, è interessante e spesso divertente ma non soltanto per la sua voce che sembra un cartone animato) in cui parlava del suo workflow, cioè del suo flusso di lavoro: con solo due tasti apriva una nuova sessione tmux (o la ripristinava se già presente) e "auto-magicamente" si trovava vim aperto pronto per lavorare! Se non è questa produttività?!?!?!

Una figata pazzesca!

Allora mi sono detto: lo posso fare anch'io, ne ho tutte le capacità ed anch'io ho la voce che sembro Paperino 😃

Mettiamoci a lavoro!

In realtà la cosa è stata abbastanza semplice, per prima cosa mi serviva un file di configurazione con tutti i path dove solitamente memorizzo i miei progetti, ho deciso di chiamare il file: mp_folders

Sicuramente vi starete domandando "ma perché inizia per mp?!?!?!"

Eh, bella domanda, lo capirete a breve 😊

Perfetto, una volta fatta la lista, mi serve un modo per chiedere all'utente quale progetto vuole aprire, e qui ThePrimeagen suggerisce (giustamente) di usare il fzf.

Il fuzzy-finder è un tools a riga di comando per filtrare e selezionare qualsiasi tipo di lista passata in ingresso. Non c'è neanche bisogno di scrivere la stringa esatta! Viene chiamata "ricerca fuzzy", permette cioè di trovare rapidamente elementi all'interno di una lista, anche in presenza di errori di battitura o parole incomplete!

Ad esempio, avete una lista come la seguente?

mela
banana
pesca
pere

per selezionare "pesca" non occorre scrivere pes pesc o addirittura pesca, basta anche solo premere p e s

Ok, ora mettiamo mani al codice... usiamo bash per scrivere un semplice script, come lo chiamiamo?!?!?

Mumble, mumble... my-project! No... troppo longo... ok trovato mp!

#! /bin/bash

LIST=$(cat $HOME/.config/mp_folders | tr "\n" " ")
FOLDER=$(find ${LIST} -mindepth 1 -maxdepth 1 -type d | fzf)

LIST praticamente sarà valorizzato con l'elenco di tutte le cartelle inserite nel file mp_folders separate da un semplice spazio.

Passiamo questa LIST al comando find per farci trovare tutte le sotto-cartelle (senza però scendere troppo nell'albero) e passiamo quindi il tutto al nostro amato fzf.

Bellissimo! Già mi piace!

Una volta che l'utente preme Invio all'interno di FOLDER andrà a finire la cartella selezionata.

Con questa informazione, ci andiamo a costruire il nome della nostra sessione tmux, per sicurezza meglio sostituire i punto con l'underscore, casomai qualcuno s'innervosisse

NAME=$(basename "${FOLDER}" | tr . _)

tmux ci consente di creare ma anche modificare sessioni, ad esempio se volessi aggiungere una nuova finestra ad una sessione, mi basta lanciare:

tmux new-window -n shell -t session1

così facendo abbiamo aggiunto una nuova finestra alla sessione "session1" dandogli il titolo "shell", ditemi voi se questa non è una figata!

Ok, mettiamo un po' comandi nello script

echo "Sessione <$NAME>"

if tmux has-session -t "${NAME}" 2>/dev/null
then
  echo "La sessione esiste"
else
  echo "La sessione non esiste"

  tmux new-session -ds $NAME -c $FOLDER
  tmux send-keys -t ${NAME}:1 "nvim" Enter
  tmux new-window -c $FOLDER -n shell -t ${NAME}:2
  tmux select-window -t ${NAME}:1
fi

if [[ -z $TMUX ]]
then
  # Non sono già in tmux
  tmux attach-session -t $NAME
else
  # Sono già in tmux
  tmux switch-client -t $NAME
fi

Lo "spiegone"

Un po' di spiegazioni...

Per prima cosa controlliamo se la sessione che abbiamo esiste già
Se c'è, allora non dobbiamo fare nulla e scriviamo solo un commento che potrebbe esserci utile in futuro
- Se invece non c'è, allora creiamo la sessione col nome che abbiamo costruito e specifichiamo anche la cartella corrente
- Tramite send-keys diciamo di scrivere nvim e premere Invio
- Dentro questa sessione, andiamo a creare una nuova finestra che chiamiamo "shell"
- E con select-window andiamo a selezionare la prima finestra (il nostro editor)
Come ultimo step, andiamo a controllare la variabile di ambiente `TMUX'
- Se non è impostata non ci troviamo già all'interno di tmux e quindi usiamo attach-session
- Altrimenti dobbiamo usare switch-client

Il nostro script è terminato, ora se lanciamo mp auto-magicamente ci verrà mostrata la lista dei nostri progetti, selezioniamo quello che vogliamo aprire e voilà! Il nostro script ci ha creato la nuova sessione tmux ed ha già aperto il nostro editor preferito!

E se volessimo cambiare progetto? Nessun problema, la sessione corrente verrebbe sostituita con la nuova e lasciata li ad aspettarci!

La ciliegina sulla torta

Ovviamente, non mi va ogni volta di aprire il terminale e scrivere mp, quindi mi sono creato un keymap che ho salvato nel mio ~/.tmux.conf:

bind -r Space run-shell tmux new-window ~/bin/mp

Nel mio caso il prefix è Ctrl + Space quindi mi basta premere Ctrl + Space + Space per fare lo switch ad un'altra sessione.

Ma vi dirò di più, dato che uso i3, ho fatto uno script simile (px) che invece del fzf utilizza rofi per visualizzare la lista dei progetti, basta questa piccola modifica:

FOLDER=$(find ${LIST} -mindepth 1 -maxdepth 1 -type d | rofi -dmenu -p "Seleziona il progetto" -font "Monospace 18")

ed aggiungere questa riga alla configurazione di i3

bindsym $mod+t exec kitty -e $HOME/bin/px

Così, anche da i3, mi basta premere un tasto per avere il mio progetto aperto e pronto a lavorare!

Per oggi è tutto, ci vediamo presto! 😎

DEV Community: Marco Bollero

I wrote Ratiform to stop writing forms in Ratatui

The problem: two fields are fine, three start to hurt

The idea: the field identifier is a real Rust type

1. The bare minimum: a single field

2. More fields, one Tab to move between them

3. Not just text: checkbox, select, text area

4. Getting values back: still no magic strings

5. Validation: "required" and "well-formed" are two separate questions

6. Normalizing, not just validating

7. Layout: horizontal or stacked, decided at runtime

8. Theming: when the default gray isn't enough

Closing the loop

Ho scritto Ratiform per smettere di scrivere i form in Ratatui

Il problema: due campi vanno bene, tre iniziano a far male

L'idea: l'identificatore del campo è un tipo Rust vero

1. Il minimo indispensabile: un solo campo

2. Più campi, un solo Tab per spostarsi

3. Non solo testo: checkbox, select, area di testo

4. Recuperare i valori: ancora niente stringhe magiche

5. Validazione: obbligatorietà e regole di forma sono due cose distinte

6. Normalizzare, non solo validare

7. Layout: orizzontale o impilato, deciso a runtime

8. Theming: quando il grigio di default non basta

Chiudendo il cerchio

Ratatui passo dopo passo - Introduzione

Una nota personale

Cos'è Ratatui

A chi si rivolge questa serie

Come è strutturata la serie

Switching from C/C++ to Rust: the invisible checklist

The invisible checklist

The "no" that comes immediately

Two types of muscle memory

It's not about "better" or "worse"

A final thought

Passare da C/C++ a Rust: la checklist invisibile

La checklist invisibile

Il "no" che arriva subito

Due tipi di "muscle memory"

Non è una questione di "meglio" o "peggio"

Una riflessione finale

Il patto delle dipendenze: quando diventa un Contratto col Diavolo

Il giorno in cui tutto va a puttane

Le Due Vie dell'Inevitabilità (o: Perché Siamo Tutti Condannati)

Il Vero Problema Non È la Dipendenza, Sei Tu

Supply Chain Attacks: Quando il Pericolo Viene da Dentro

L'Abbandono: La Tragedia Silenziosa

Il Patto Faustiano

Quindi? Che Facciamo?

La Vera Domanda

L'IA nella Programmazione: Strumento o Stampella?

Il Problema: L'Outsourcing del Pensiero

Un Problema Vecchio, ma Amplificato

L'Analogia della Calcolatrice

Copiare Senza Garanzie

Cosa Perdiamo Veramente

Gli Usi Corretti dell'IA

1. L'IA come Tutor Personale

2. Comprendere Algoritmi Classici

3. Supporto nella Documentazione

4. Generazione di Test

La Regola d'Oro

Le Questioni Legali ed Etiche

Il Problema delle Licenze

Una Zona Grigia Normativa

L'Etica della Formazione Professionale

Verso una Visione Equilibrata

Quattro Principi Guida

Il Mio Workflow Personale

La Competenza è Insostituibile

Conclusione

Guida Completa: Neovim 0.11 IDE per Rust su Ubuntu/MacOS

Prerequisiti e Dipendenze di Sistema

Installazione su GNU/Linux (Ubuntu)

MacOS

Installazione di Neovim 0.11

Installazione su MacOS

Installazione su GNU/Linux (Ubuntu)

Metodo alternativo: Compilazione dai sorgenti

2. More fields, one `Tab` to move between them

2. Più campi, un solo `Tab` per spostarsi

Mason (`~/.config/nvim/lua/plugins/mason.lua`)

nvim-cmp (`~/.config/nvim/lua/plugins/cmp.lua`)

Gitsigns (`~/.config/nvim/lua/plugins/gitsigns.lua`)

Fugitive (`~/.config/nvim/lua/plugins/fugitive.lua`)

Which-Key (`~/.config/nvim/lua/plugins/which-key.lua`)

Trouble (`~/.config/nvim/lua/plugins/trouble.lua`)

Fidget (`~/.config/nvim/lua/plugins/fidget.lua`)

Treesitter (`~/.config/nvim/lua/plugins/treesitter.lua`)

Telescope (`~/.config/nvim/lua/plugins/telescope.lua`)

Oil.nvim (`~/.config/nvim/lua/plugins/oil.lua`)

Rustaceanvim (`~/.config/nvim/lua/plugins/rustacean.lua`)

6.9 Lualine (`~/.config/nvim/lua/plugins/lualine.lua`)

Gruvbox Material (`~/.config/nvim/lua/plugins/colorscheme.lua`)