Forem: Marco Bollero

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! 😎

Forem: Marco Bollero

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

Installazione Toolchain Rust

Struttura della Configurazione

Configurazione Lazy.nvim

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)

Test e Verifica

Prima apertura di Neovim

Verifica installazione plugin

Verifica Treesitter

Test con progetto Rust

Test debugging

Comandi Utili

Plugin Management (Lazy.nvim)

Mason (Package Manager)

Autocompletamento (nvim-cmp)

Telescope

Oil.nvim

LSP

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`)