Cos'è Ruby e ha ancora senso nel 2026

Ogni volta che chiedi se vale la pena imparare Ruby ti rispondono due cose opposte: "è morto da dieci anni" e "con Rails tiri su un prodotto in un pomeriggio". Sono vere entrambe, e il motivo è che parlano di due cose diverse. In questo articolo trovi cos'è Ruby davvero, da dove nasce la sua stranezza, e una risposta onesta alla domanda del titolo.

Cos'è Ruby

Ruby è un linguaggio interpretato e completamente a oggetti, creato in Giappone da Yukihiro "Matz" Matsumoto nel 1995 con un obiettivo dichiarato insolito: rendere felice chi scrive il codice, non efficiente la macchina che lo esegue.

Questa non è una frase da brochure, è una scelta di progetto documentata dall'autore, ed è la chiave che spiega tutto il resto. Quando devi scegliere tra una sintassi che gira più veloce e una che si legge come una frase, Ruby sceglie sempre la seconda. Quando devi scegliere tra un solo modo canonico di fare una cosa e cinque modi comodi, Ruby sceglie i cinque.

È l'esatto opposto della filosofia di Go, che toglie funzionalità per rendere il codice prevedibile. Qui la prevedibilità si sacrifica in cambio dell'espressività, e questo ha conseguenze precise che vedremo.

Tutto è un oggetto. Davvero tutto

In molti linguaggi ci sono i "tipi primitivi" — numeri, booleani — che stanno fuori dal sistema a oggetti. In Java un int non è un oggetto e serve una classe involucro per trattarlo come tale.

In Ruby quell'eccezione non esiste.

5.times { puts "ciao" }
(-7).abs          # => 7
nil.to_a          # => []
true.class        # => TrueClass
"stringa".upcase  # => "STRINGA"

5 è un oggetto, nil è un oggetto, true è un oggetto. Ogni cosa risponde a dei messaggi, e non c'è una categoria di valori "di serie B" con regole proprie. Il risultato è che non devi ricordare due insiemi di regole: ne impari uno e vale ovunque.

Corollario meno ovvio: anche le classi sono oggetti, e puoi modificarle mentre il programma gira. Ci torniamo, perché è il potere e il problema di Ruby insieme.

I blocchi: il costrutto caratteristico

Se c'è una cosa che riconosci a colpo d'occhio nel codice Ruby, sono i blocchi. Un blocco è un pezzo di codice che passi a un metodo perché lo esegua lui, quando e quante volte vuole.

utenti.each do |utente|
  puts utente.nome
end

attivi = utenti.select { |u| u.attivo? }
nomi   = utenti.map    { |u| u.nome }
totale = ordini.sum    { |o| o.importo }

Sembra banale — anche JavaScript e Python hanno costrutti simili — ma in Ruby il blocco è talmente centrale che ci si costruiscono sopra cose che altrove richiedono sintassi dedicata:

File.open("dati.txt") do |f|
  f.each_line { |riga| puts riga }
end
# il file viene chiuso da solo all'uscita dal blocco

Qui il metodo open apre la risorsa, ti passa il controllo, e alla fine la chiude comunque — anche se dentro il blocco succede un errore. La gestione della risorsa è incapsulata nel metodo invece che nelle tue mani. Lo stesso schema copre transazioni, misurazioni di tempo, blocchi di configurazione.

E poi c'è il dettaglio che fa capire la mentalità: i punti interrogativi e esclamativi nei nomi dei metodi.

nome.empty?      # ? = restituisce vero o falso
elenco.sort      # restituisce una copia ordinata
elenco.sort!     # ! = modifica l'originale, attenzione

Non è una regola del linguaggio, è una convenzione — ma è rispettata ovunque, e leggere utente.admin? invece di utente.is_admin() cambia davvero la sensazione di scorrere il codice.

Ruby e Rails sono quasi la stessa cosa (e questo è un problema)

Va detto subito perché è la fonte di metà dei fraintendimenti: Ruby è il linguaggio, Rails è un framework web scritto in Ruby. Sono due cose distinte. Nella pratica, però, il 90% delle offerte di lavoro dice "Ruby" e intende "Rails", e la maggior parte di chi impara Ruby lo fa per Rails.

Rails nasce nel 2004 e impone un principio che all'epoca era rivoluzionario: convenzione sulla configurazione. Se chiami la classe Prodotto, il framework va a cercare da solo la tabella prodotti, il file prodotto.rb, le viste in views/prodotti/. Non configuri niente: rispetti la convenzione e tutto si aggancia.

class Prodotto < ApplicationRecord
  belongs_to :categoria
  validates :nome, presence: true
  scope :disponibili, -> { where("giacenza > 0") }
end

Quattro righe, e hai un modello collegato al database, con una relazione, una validazione e una query riutilizzabile. Aggiungi il generatore da riga di comando e in un pomeriggio hai un'applicazione con autenticazione, pannello e API funzionanti.

Questa velocità è reale e non va sminuita. È il motivo per cui prodotti come GitHub, Shopify, Basecamp e Airbnb sono nati su Rails: quando devi scoprire se un'idea funziona, arrivare in produzione in due settimane vale più di qualsiasi considerazione architetturale.

Il prezzo: la magia implicita

Il conto arriva dopo, e arriva sotto forma di una domanda: da dove esce questo metodo?

Ruby permette la metaprogrammazione, cioè scrivere codice che genera altro codice mentre il programma è in esecuzione. Rails ne fa un uso massiccio: molti metodi che chiami non sono scritti da nessuna parte, vengono creati al volo in base ai nomi delle colonne del database o alle relazioni dichiarate.

utente.articoli.pubblicati.recenti
# nessuno di questi tre metodi è scritto in un file che puoi aprire

Finché segui il percorso previsto, è magnifico. Quando devi capire perché una cosa si comporta in modo strano, cercare la definizione con un editor non serve a niente: il metodo non esiste come testo. Devi conoscere le convenzioni di Rails, non solo Ruby.

Per chi inizia questo è il vero ostacolo: non stai imparando un linguaggio, stai imparando un linguaggio più un enorme corpo di convenzioni implicite. Ed è un'esperienza molto diversa da quella di un progetto in TypeScript, dove ogni cosa è dichiarata e l'editor te la trova.

È morto? Risposta onesta

No. Ma è uscito dalla moda, ed è una cosa diversa dall'essere morto.

Tra il 2008 e il 2015 Rails era la scelta predefinita per chiunque costruisse un prodotto web. Poi l'attenzione si è spostata su JavaScript e sui framework a componenti, su Python per i dati e l'AI, su Go per l'infrastruttura. Ruby ha smesso di essere l'argomento di cui si parla.

Cosa è rimasto:

Le aziende nate su Rails ci girano ancora sopra, e sono aziende grandi. Shopify investe direttamente nelle prestazioni di Ruby.
Rails continua a evolversi e resta, insieme a Laravel, uno dei modi più veloci di portare un prodotto web dall'idea alla produzione.
Il mondo delle startup lo usa ancora, per esattamente lo stesso motivo del 2010: velocità di esecuzione iniziale.

Cosa non è rimasto: il flusso di nuovi progetti. Chi comincia oggi da zero sceglie più spesso altro, e questo significa che il numero di posizioni Ruby cresce meno del numero di posizioni JavaScript.

Sull'Italia va detta la verità: il mercato Ruby qui è piccolo. Esistono agenzie e prodotti che ci lavorano, e chi li cerca fatica a trovare gente perché in pochi lo studiano — quindi la concorrenza sulle posizioni è bassa. Ma il numero assoluto di offerte è una frazione di quelle su JavaScript, Java o PHP. Se il tuo obiettivo è il primo lavoro in tempi brevi, Ruby non è la scorciatoia più corta; se lavori in remoto per l'estero, il discorso cambia parecchio.

Dove ha senso e dove no

Ambito	Ruby	Perché
Prodotti web, MVP, startup	Molto	Rails porta da zero a produzione in tempi brevi
Gestionali e applicazioni CRUD	Molto	La convenzione copre il 90% del lavoro ripetitivo
Script e automazioni	Sì	Sintassi comodissima per manipolare testo e file
API e backend di prodotto	Sì	Rails in modalità API funziona benissimo
Calcolo intensivo, dati, AI	No	L'ecosistema è in Python e non cambierà
Sistemi, embedded, performance	No	È interpretato, vedi Rust o C++
Mobile e desktop	No	Non è il suo mestiere

Errori comuni

Aspettarsi che sia veloce come un compilato. Ruby è interpretato e paga in prestazioni pure: su un ciclo numerico intenso perde nettamente contro qualunque linguaggio compilato. Nelle applicazioni web reali il collo di bottiglia è quasi sempre il database, quindi conta meno di quanto sembri — ma se il tuo problema è calcolo, Ruby è lo strumento sbagliato e nessuna ottimizzazione lo salva.

Abusare della metaprogrammazione. Poter riscrivere le classi a runtime non significa doverlo fare. Il codice che definisce metodi dinamicamente per risparmiare dieci righe è impossibile da leggere per chiunque non l'abbia scritto, impossibile da cercare, e invisibile agli strumenti di analisi. Usala quando elimina una ripetizione vera e su larga scala, non per fare colpo.

Confondere Ruby con Rails. Se impari solo Rails, il giorno che devi scrivere uno script Ruby senza framework ti accorgi che metà di ciò che conosci non esiste. Conviene passare qualche ora sul linguaggio puro prima di aprire Rails: oggetti, blocchi, moduli, Enumerable.

Modificare classi del linguaggio a cuor leggero. Puoi aggiungere un metodo a String in qualsiasi punto del programma. Puoi anche ridefinirne uno esistente, e allora rompi codice scritto da altri che non sa nulla di te. Si fa con moderazione estrema.

Ignorare la gestione delle versioni. Progetti Ruby diversi richiedono versioni diverse dell'interprete e delle gemme. Senza un gestore di versioni e senza bundler finisci in un pasticcio di dipendenze incompatibili nel giro di due progetti.

In sintesi

Ruby è progettato per la felicità di chi lo scrive, e questa non è una metafora: è il criterio dichiarato con cui sono state prese le decisioni di progetto. Tutto è un oggetto, i blocchi permettono di incapsulare comportamenti in modo elegante, e la sintassi tende a leggersi come linguaggio naturale.

Ruby e Rails nella pratica viaggiano insieme. La convenzione sulla configurazione ti fa arrivare in produzione in tempi che pochi altri stack reggono, e il prezzo è una quantità notevole di magia implicita: metodi che esistono a runtime ma non in nessun file, e un modello mentale che devi conoscere per forza.

Non è morto, è fuori moda. Resta una scelta razionale per chi deve portare un prodotto sul mercato in fretta, e le aziende grandi nate su Rails non lo stanno abbandonando. In Italia però il mercato è piccolo: è un'informazione che va pesata prima di investirci mesi.

Quando ha senso impararlo: se lavori o vuoi lavorare su prodotti web dove la velocità di sviluppo conta più delle prestazioni, o se ti interessa capire un modo di progettare linguaggi radicalmente diverso da quello dominante oggi. Non come primo linguaggio in assoluto se il tuo obiettivo è il lavoro in Italia — per quello vedi quale linguaggio imparare nel 2026.

Se stai ancora scegliendo dove investire il tuo tempo, il quadro completo è in tutti i linguaggi di programmazione; se preferisci partire con un percorso guidato invece che da soli, dai un'occhiata ai corsi di CodeGrind.