In sintesi: Il titolare d’azienda non ha bisogno di sapere programmare, ma deve capire il panorama dei linguaggi per fare le domande giuste. I linguaggi principali nel 2026 — JavaScript/TypeScript, Python, Java, C#, PHP, Go — hanno ciascuno il proprio ecosistema e mercato del lavoro. I linguaggi esotici nei progetti critici sono un segnale d’allarme. Il vendor lock-in vale più del costo dello sviluppo.
Questo articolo fa parte del pillar Fondamenti IT per il titolare d’azienda.
Perché il titolare d’azienda dovrebbe preoccuparsi dei linguaggi di programmazione
Tre motivi pratici:
- Valutazione dei fornitori — come capire se un fornitore propone una tecnologia adeguata o esotica per risparmiare sui propri costi interni?
- Dipendenza dal fornitore — alcune scelte tecnologiche rendono la sostituzione del fornitore praticamente impossibile.
- Recruiting e costi — i linguaggi diversi hanno mercati del lavoro diversi e costi molto diversi.
I principali linguaggi di programmazione nel 2026
JavaScript / TypeScript
Il linguaggio più diffuso al mondo (Stack Overflow Developer Survey 2025: 12° anno consecutivo in cima). Gira nel browser (frontend) e sul server (Node.js, Deno, Bun).
TypeScript è JavaScript con tipi statici — riduce gli errori, migliora la manutenibilità. Standard de facto per i progetti seri nel 2026.
- Disponibilità degli sviluppatori: Altissima
- Costo relativo: Medio
- Adatto per: App web, API, mobile (React Native), serverless
- Framework principali: React, Next.js, Vue, Angular (frontend); Express, NestJS, Fastify (backend)
Python
Il linguaggio della data science, AI e automazione. Leggibile, ricco di librerie, enorme ecosistema.
- Disponibilità degli sviluppatori: Alta
- Costo relativo: Medio-alto
- Adatto per: Machine learning, analisi dati, scripting, automazione, backend API
- Framework principali: FastAPI, Django, Flask; scikit-learn, TensorFlow, PyTorch per AI
Java
Enterprise standard da 30 anni. Verboso ma affidabile, eccellente per sistemi grandi e complessi. Usato in banche, assicurazioni, grandi aziende.
- Disponibilità degli sviluppatori: Alta
- Costo relativo: Alto
- Adatto per: Sistemi enterprise, backend, microservizi
- Framework principali: Spring Boot, Quarkus, Micronaut
C# (.NET)
L’ecosistema Microsoft. Simile a Java nel design, ma con un’ottima integrazione con i prodotti Microsoft (Azure, Active Directory, M365). Molto usato nelle aziende che già usano l’infrastruttura Microsoft.
- Disponibilità degli sviluppatori: Media-alta
- Costo relativo: Alto
- Adatto per: Sistemi enterprise, app Windows, backend, giochi (Unity)
- Framework principali: ASP.NET Core, Blazor
PHP
Il veterano del web. Powers WordPress, Magento, Drupal. Nel 2026 meno glamour, ma ancora molto usato.
- Disponibilità degli sviluppatori: Alta (molti junior)
- Costo relativo: Basso-medio
- Adatto per: CMS, e-commerce, siti web, backend
- Framework principali: Laravel, Symfony
Go (Golang)
Linguaggio moderno di Google (2009). Compilato, performante, concorrente. Ottimo per microservizi e infrastruttura cloud.
- Disponibilità degli sviluppatori: Media
- Costo relativo: Alto
- Adatto per: API performanti, microservizi, CLI tools, infrastruttura cloud
- Usato da: Google, Uber, Dropbox, Docker, Kubernetes
Rust
Il linguaggio della sicurezza della memoria — nessun garbage collector, prestazioni C++, sicurezza della memoria garantita a compile time. Nel 2026 cresce in uso per browser, OS e infrastruttura critica.
- Disponibilità degli sviluppatori: Bassa
- Costo relativo: Molto alto
- Adatto per: Sistemi embedded, infrastruttura critica, browser engine, WebAssembly
Segnali d’allarme: linguaggi esotici nei progetti critici
Se un fornitore propone di sviluppare il tuo ERP o sistema CRM in Erlang, Haskell, OCaml, COBOL o un altro linguaggio di nicchia — chiedere perché.
Non è che questi linguaggi siano sbagliati in sé (Erlang è eccellente per la concorrenza, Haskell per la correttezza formale), ma:
- Mercato del lavoro ristretto — se il fornitore ti abbandona, trovare qualcuno in grado di manutenere il codice è difficile e costoso
- Probabilmente la scelta riflette le preferenze del fornitore, non le tue esigenze
- Tooling e librerie più limitati — meno soluzioni pronte, più sviluppo custom
Eccezione: se il fornitore ha una chiara argomentazione tecnica per cui il linguaggio risolve un problema specifico del tuo caso (ad es. Erlang per la massima disponibilità in telecomunicazioni), ascolta. Ma sii scettico.
7 domande da fare al fornitore di sviluppo
Prima di firmare un contratto per lo sviluppo software su misura:
- “In quale linguaggio e framework sviluppate?” — verifica che non sia esotico e che il mercato del lavoro esista
- “Chi possiede il codice sorgente?” — deve essere di tua proprietà, non del fornitore
- “Come esportate i miei dati se mi voglio spostare?” — formato standard (SQL dump, JSON, CSV), non proprietario
- “Avete documentazione del codice e dei processi?” — senza documentazione il codice diventa un segreto
- “Come gestite gli aggiornamenti di sicurezza delle dipendenze?” — le librerie si aggiornano continuamente; serve una policy
- “Avete CI/CD e test automatici?” — senza test, ogni modifica è una potenziale regressione
- “Che succede se il vostro team chiave lascia l’azienda?” — verifica del bus factor
Il tech stack di Modulario
Per trasparenza: Modulario è costruito con:
- Backend: NestJS (TypeScript) + PostgreSQL
- Frontend: Next.js (TypeScript/React)
- Infrastruttura: AWS EU-West, Kubernetes
- AI: Claude API (Anthropic)
La scelta di TypeScript su entrambi i lati (backend + frontend) riduce il contesto di switching per il team e facilita il hiring in un mercato del lavoro ampio.
Vendor lock-in: il rischio più sottovalutato
Il vendor lock-in è più costoso della scelta del linguaggio. Tre situazioni tipiche:
Lock-in tecnologico
Il fornitore usa una piattaforma proprietaria (low-code/no-code di nicchia, database proprietario, cloud vendor con servizi non portabili). Migrare significa riscrivere tutto da zero.
Prevenzione: preferire open source o standard aperti. Se si usa un servizio cloud proprietario, assicurarsi che esista un’alternativa realistica.
Lock-in dei dati
I dati sono in un formato proprietario o non esportabile. Il fornitore è l’unico in grado di leggerli.
Prevenzione: contratto che include il diritto all’esportazione dei dati in formato standard in qualsiasi momento.
Lock-in del codice
Il fornitore non consegna il codice sorgente o consegna codice offuscato / non documentato.
Prevenzione: contratto con consegna del codice sorgente commentato + documentazione tecnica minima. Considerare il deposito del codice in escrow.
Quando scegliere SaaS invece di sviluppo su misura
Regola pratica:
| Situazione | Consiglio |
|---|---|
| Esiste un SaaS che copre l’80% dei processi | SaaS — costo minore, manutenzione zero |
| Il processo differenziante è unico | Sviluppo su misura selettivo |
| Budget IT < 50k EUR/anno | SaaS quasi sempre |
| Team IT interno > 5 persone | Si può considerare sviluppo su misura |
| Requisiti di compliance molto specifici | Valutare caso per caso |
Lo sviluppo su misura costa 5-20x in più nel primo anno rispetto al SaaS equivalente e richiede manutenzione continuativa (aggiornamenti di sicurezza, nuove funzionalità, bug fix). Il beneficio reale arriva solo quando il processo è abbastanza unico da non avere alternative SaaS adeguate.
Domande frequenti
Devo sapere programmare per gestire un’azienda tecnologica? No. Ma devi capire abbastanza da fare le domande giuste ai tuoi sviluppatori o fornitori. Questo articolo ti dà esattamente questo vocabolario minimo.
Come scelgo tra sviluppo su misura e SaaS? Regola pratica: SaaS se esiste una soluzione che copre l’80% dei tuoi processi a un costo ragionevole. Sviluppo su misura se il tuo vantaggio competitivo dipende da un processo unico. Lo sviluppo su misura costa 5-20x in più nel primo anno e richiede manutenzione continuativa.
Cos’è il vendor lock-in e come evitarlo? Il vendor lock-in è la situazione in cui cambiare fornitore diventa estremamente costoso. Tre segnali: (1) tecnologie proprietarie non portabili, (2) dati in formati non esportabili, (3) il fornitore non consegna il codice sorgente. Prevenzione: contratto con clausola di consegna del codice, dati in formati standard, architettura che separa business logic da infrastruttura.