Intervista d’Autore: Luca Palmieri
Da blog post a bestseller: intervista a Luca Palmieri, autore di “Zero to Production in Rust” e “100 Exercises To Learn Rust”.
Nel nostro format “Intervista d’Autore” organizzato dal team libreria di Develer, abbiamo avuto il piacere di parlare con Luca Palmieri, autore di Zero to Production in Rust e 100 Exercises to Learn Rust, nonché principal engineer con un solido background in machine learning, sistemi distribuiti e backend development. In questa chiacchierata, abbiamo approfondito il suo percorso, il processo di scrittura tecnica, il mondo Rust e anche qualche consiglio pratico per chi volesse scrivere un libro di programmazione.
Chi sei, cosa fai oggi e com’è iniziato il tuo percorso?
Sviluppo da una decina d’anni. Di formazione vengo dal mondo della matematica e ho iniziato la carriera come machine learning engineer. Durante il mio percorso professionale mi sono spostato sempre più verso lo sviluppo software vero e proprio e da circa 7-8 anni lavoro con Rust anche a livello professionale.
Nel tempo ho scritto due libri: Zero to Production in Rust, una guida completa allo sviluppo backend in Rust – per chi conosce già il linguaggio ma vuole imparare l’ecosistema -, e 100 Exercises to Learn Rust, un’introduzione pratica al linguaggio attraverso piccoli problemi con test di verifica.
Oggi lavoro come consulente e principal engineer, aiutando le aziende ad adottare Rust e a scalare i loro sistemi cloud.
Hai usato strumenti AI (es. ChatGPT) per la scrittura dei tuoi libri?
No, non in modo significativo. Preferisco mantenere uno stile personale nella scrittura. L’output delle AI ha ancora un tono abbastanza uniforme e riconoscibile, che non rispecchia il mio stile. Uso l’AI per altre cose – lo sviluppo, per esempio – ma per la scrittura voglio mantenere il mio tono di voce.
Quanto tempo richiede scrivere un libro tecnico? Come organizzi la scrittura nella vita quotidiana?
Zero to Production in Rust ha richiesto circa due anni, che corrispondono più o meno a cinque-sei mesi di lavoro full time. Lo scrivevo principalmente la sera e nei weekend.
Il secondo libro, invece, che ha meno teoria e più esercizi, l’ho scritto in un mese e mezzo di lavoro full time: è nato come materiale didattico per i workshop che facciamo con Mainmatter per insegnare Rust, quindi la base c’era già. In generale, serve molto tempo e dipende da quanta ricerca bisogna fare: magari alcuni argomenti li conosci benissimo, ma per altri hai bisogno di consultare delle fonti. Una grossa parte di tempo la uso per strutturare il libro prima ancora di scrivere: una delle più grandi difficoltà è la stesura dell’indice. Ho imparato che la scrittura in senso stretto non è necessariamente la parte che ti prende più tempo.
Scrivere un libro tecnico sul codice deve essere molto diverso da scrivere un romanzo. Cos’è più difficile: scrivere o strutturare?
Decisamente la struttura. 100 esercizi va letto in ordine, ma gli esercizi sono tutti indipendenti. La parte più complessa è stata trovare una sequenza logica di esercizi: serve un filo conduttore che garantisca apprendimento graduale, senza introdurre concetti non ancora spiegati.
Anche Zero to Production è complesso perché segue un’unica code base che evolve, da pagina 1 a pagina 650: qui il sequenziamento è molto stringente perché necessariamente devi far evolvere il progetto nel corso del libro e lo devi seguire con la narrativa. Lì serve rigore, continuità e tanti checkpoint.
Tu fornisci concetti astratti, ma anche esercizi che devono compilare ed eseguire correttamente: come funziona la fase di review e test del codice?
Per 100 Esercizi è abbastanza semplice: essendo una raccolta di esercizi auto contenuti, c’è una CI. Ogni volta che faccio un edit di uno degli esercizi, la CI ha un branch con le soluzioni, che è sempre un commit sopra al branch degli esercizi da risolvere, e controlla che le soluzioni funzionino.
Zero Production è molto più complicato perché è un unico progetto, quindi non tutto il codice è mostrato nel libro, ma cambia da pagina in pagina. Anche lì abbiamo un sistema di branch, per cui ogni capitolo ha uno o più branch che fanno da check point, e ciascuno di questi branch è su GitHub, nella repository del progetto, e ciascuno di questi branch ha la sua CI e dei test. Senza test automatici e manuali e un minimo di CI, sarebbe impossibile far evolvere il libro: un minimo cambiamento rischierebbe di rompere tutto.
Parliamo di pubblicazione: casa editrice o autopubblicazione?
Io ho scelto l’autopubblicazione per Zero Production, ma è un caso un po’ particolare. Il libro è nato come una serie di blog post per aiutare i colleghi ad adottare Rust in azienda per il backend. A un certo punto mi sono reso conto che avevo scritto più di 100 pagine.
La serie ha avuto molto successo nella community, perché non c’era un libro di livello intermedio sul linguaggio, e da lì è diventata un libro. Gli editori sono venuti da me, ma a quel punto avevo già pubblico, revisori e materiale pronto. Ho preferito tenere il controllo completo e pubblicarlo da solo. E così ho fatto anche per l’altro libro.
Perché proprio Rust? Otto anni fa non era al punto in cui è oggi, quindi è stata una scelta di certo originale.
La vita, a volte, è questione di coincidenze. Ai tempi lavoravo nel machine learning, un ambito dove si usa quasi sempre Python. Di solito si sfruttano librerie ad alte prestazioni scritte in C, che permettono di ottenere buoni risultati pur scrivendo codice ad alto livello. Ma quando ti serve qualcosa di più personalizzato, e quelle librerie non esistono, ti ritrovi a dover implementare tutto in Python — e lì iniziano i problemi di performance.
Fu allora che il mio CTO mi parlò di un nuovo linguaggio di programmazione di sistema che aveva scoperto: si chiamava Rust e gli sembrava promettente. Così, quasi per curiosità, iniziai a documentarmi. Presi un libro, iniziai a fare qualche prova… e poco dopo ebbi l’opportunità di usarlo in un progetto reale. È stato un mix di casualità e scelta consapevole: mi sono ritrovato a essere un early adopter, anche grazie al fatto che avevo uno use case concreto che giustificava l’investimento in una tecnologia di nicchia.
Scrivere libri ti ha aiutato anche come sviluppatore?
Sì, su due livelli.
Dal punto di vista tecnico, scrivere ti costringe ad approfondire davvero ciò che spieghi. Devi studiare le fonti, leggere le referenze e chiarire ogni dettaglio: è un lavoro di ricerca che nella pratica quotidiana spesso non fai, ma che ti rende molto più solido nelle conoscenze.
Sul piano professionale, invece, un libro ti dà autorevolezza. Se il tuo libro è conosciuto, non devi più dimostrare chi sei: chi ti incontra spesso lo ha letto, e ti riconosce subito come esperto. Questo apre molte opportunità e accelera la carriera.
Che strumenti e tecniche usi per scrivere?
È bellissimo perché molti mi fanno questa domanda pensando che abbia chissà quale sistema ultra sofisticato di scrittura, mentre sono un cavernicolo! Ho dei file in markdown, uno per ogni capitolo, che dò in pasto a Pandoc che ti butta fuori il pdf. Niente Obsidian, niente tool sofisticati. Scrivo con il mio editor preferito, in modo semplice.
C’è un nuovo libro in cantiere?
No, al momento no. Sto lavorando su un progetto open source, e ho anche un lavoro!
Che consigli daresti a chi vuole scrivere un libro tecnico?
- Scrivi tanto, anche male. La scrittura si migliora scrivendo.
- Parti da un blog. Scrivere post lunghi ti abitua al formato.
- Non puntare alla perfezione. Concentrati sulla quantità della scrittura prima che sulla qualità.
- Sii padrone dei tuoi strumenti. L’atto della scrittura dev’essere fluido. Padroneggia a fondo il tuo editor per minimizzare la frizione.
Develer organizza RustLab. Come può crescere ulteriormente la community Rust in Italia?
Le conferenze tematiche sono ottime per chi è già nell’ecosistema, ma se vogliamo far conoscere Rust dobbiamo portarlo anche in eventi più generici o dedicati ad altri linguaggi, come per esempio Codemotion o PyCon. Bisogna intercettare i curiosi. Far toccare con mano Rust in contesti concreti. È così che si semina, e poi – magari tre anni dopo – quella persona potrebbe diventare uno sviluppatore Rust professionista.
Quello che le conferenze come RustLab fanno davvero bene sono i workshop: offrono l’opportunità di imparare qualcosa di concreto e di metterlo subito in pratica. C’è poi un grande valore nella parte di networking, perché permette agli sviluppatori che sperimentano Rust nel tempo libero di entrare in contatto diretto con le aziende che lo utilizzano davvero.
Grazie ancora a Luca per questa intervista ricca e piena di spunti!
Per chi volesse approfondire, trovate il suo lavoro sul suo sito, oppure potete seguirlo su X/Twitter.
Guarda il video dell’intervista integrale: https://youtu.be/SSUp8RmeyDY