Mojo 1.0 diventa open source e prepara lo sbarco nativo su Windows

Mojo 1.0 segna un passaggio importante per uno dei linguaggi più interessanti nati attorno al calcolo ad alte prestazioni e all’intelligenza artificiale. Modular (adesso sotto l’ala di Qualcomm) ha pubblicato la versione stabile l’11 agosto 2026 e, pochi giorni dopo, il 18 agosto, ha aperto completamente il codice del linguaggio con licenza Apache 2.0, comprese le LLVM Exceptions: non soltanto la libreria standard, quindi, ma anche compilatore e tooling. La seconda novità riguarda direttamente una platea enorme di sviluppatori: Modular sta lavorando insieme al team Windows di Microsoft per portare Mojo in modo nativo sul sistema operativo, superando l’attuale dipendenza da WSL (Windows Subsystem for Linux).

La storia di Mojo è piuttosto breve ma tecnicamente significativa. Modular lo presentò nel 2023 con un obiettivo ambizioso: conservare una sintassi familiare a chi programma in Python, aggiungendo però caratteristiche da linguaggio di sistema, compilazione nativa e accesso diretto a CPU, GPU e acceleratori specializzati. Nel 2024 arrivò l’apertura della libreria standard; nel 2025 Modular ha reso open source una parte consistente dei kernel di calcolo utilizzati da MAX, cioè il codice ottimizzato che esegue operazioni matematiche e di machine learning su CPU e GPU.

Con Mojo 1.0 il progetto raggiunge ora la stabilità del codice sorgente promessa dagli sviluppatori, mentre l’apertura del compilatore elimina una delle principali obiezioni che accompagnavano il linguaggio fin dalla sua nascita.

Mojo 1.0 diventa realmente open source

Fino a pochi giorni fa Mojo non era completamente open source. Parti considerevoli del progetto risultavano già disponibili pubblicamente, compresa la libreria standard, ma il cuore della toolchain rimaneva chiuso. Adesso Modular ha pubblicato anche il compilatore Mojo; la licenza permissiva è adatta anche all’impiego commerciale e alla redistribuzione.

Chi vuole esaminare il compilatore non deve quindi accontentarsi dei binari distribuiti da Modular. L’azienda spiega che è possibile clonare il repository e compilare localmente Mojo utilizzando Bazel.

C’è però un dettaglio che ridimensiona, almeno per ora, l’immagine di un progetto immediatamente governato dalla comunità. Modular pubblica il codice del compilatore, permette di studiarlo, modificarlo e costruirlo, ma al momento non accetta contributi esterni per lo sviluppo di compilatore e tooling. L’obiettivo dichiarato è aprire anche quella possibilità entro la fine del 2026.

Perché Mojo assomiglia a Python ma non è semplicemente un “Python più veloce”

Definire Mojo come un “Python compilato” sarebbe poco accurato. La sintassi è intenzionalmente familiare ai programmatori Python e il linguaggio offre una forte interoperabilità con Python; l’architettura, però, nasce per risolvere problemi differenti da quelli affrontati da CPython.

Un programma Python tradizionale gira normalmente attraverso l’interprete CPython. Le estensioni che richiedono prestazioni elevate delegano spesso il lavoro a codice C, C++, Fortran, CUDA o ad altre implementazioni native. NumPy, PyTorch e numerose librerie scientifiche funzionano molto bene proprio perché il codice Python rappresenta spesso il livello di orchestrazione, mentre le operazioni costose finiscono in componenti compilati.

Mojo prova ad avvicinare i due mondi. Permette di scrivere codice di alto livello con costrutti familiari a chi conosce Python ma, quando serve, offre controllo sui tipi, sulla memoria, sulla vettorizzazione SIMD, sulla specializzazione a tempo di compilazione e sull’esecuzione su acceleratori. Non nasce quindi soltanto per ridurre il tempo impiegato da un ciclo for: punta a coprire parti che oggi richiedono linguaggi e strumenti differenti.

L’interoperabilità rimane fondamentale perché nessun nuovo linguaggio può ignorare l’enorme patrimonio software Python. Mojo può importare moduli Python e invocarne funzioni ma esiste anche il percorso inverso, che consente di esporre codice Mojo verso Python. Modular descrive proprio la migrazione graduale come uno degli scenari principali: si mantiene l’applicazione Python e si spostano in Mojo soltanto le sezioni che richiedono maggiore controllo o prestazioni.

Un solo linguaggio per CPU e GPU: l’obiettivo è più ampio di CUDA

Mojo vuole consentire allo sviluppatore di scrivere nello stesso linguaggio sia codice destinato alla CPU sia kernel GPU.

Modular supporta attualmente GPU NVIDIA, AMD e Apple Silicon, con requisiti diversi a seconda della piattaforma. Attraverso Mojo e le API di accelerazione di MAX è possibile controllare dispositivi, tensori e operazioni GPU mantenendo lo stesso linguaggio usato dal resto del programma. Quando serve un livello ancora più basso, rimane possibile arrivare a primitive specifiche dell’hardware, compreso PTX nel caso NVIDIA.

Non significa che CUDA diventi improvvisamente inutile. CUDA dispone di librerie mature, strumenti di profiling molto evoluti e decenni di ottimizzazioni dedicate all’hardware NVIDIA. La proposta di Modular affronta un problema diverso: ridurre il legame tra il software e un’unica famiglia di acceleratori.

Trainium, Google TPU e Qualcomm: la vera prova della portabilità

Modular afferma che la propria piattaforma supporta ora, oltre a CPU e GPU NVIDIA e AMD, anche AWS Trainium, Google TPU, Qualcomm Cloud AI 100 Ultra e Qualcomm Dragonfly.

Per Modular è una dimostrazione della portabilità perseguita fin dall’inizio: modello, API, workflow di serving e astrazioni principali dovrebbero rimanere sostanzialmente gli stessi mentre cambia l’hardware sottostante. L’azienda sostiene inoltre di aver ridotto di oltre 10 volte il lavoro ingegneristico necessario per abilitare nuove architetture rispetto agli approcci tradizionali.

Secondo Modular, un piccolo gruppo di ingegneri HTEC avrebbe realizzato il supporto Google TPU in pochi mesi, con il team dell’azienda principalmente in funzione di supporto. Per un progetto che vuole convincere produttori di chip e operatori cloud, poter aggiungere nuovi backend senza ricostruire da zero l’intero stack è probabilmente più importante di qualsiasi confronto sintetico tra linguaggi.

Mojo su Windows oggi significa ancora WSL

La documentazione aggiornata di Modular continua a indicare Linux e macOS come piattaforme native. Su Windows, invece, WSL resta necessario: Mojo viene eseguito dentro una distribuzione Linux installata attraverso Windows Subsystem for Linux.

Dal punto di vista dell’utente Windows l’esperienza d’uso può apparire quasi trasparente, soprattutto usando Visual Studio Code con integrazione WSL, ma tecnicamente rimangono due ambienti distinti.

È però in arrivo un importante cambiamento: Modular/Qualcomm hanno annunciato l’avvio della collaborazione con Microsoft per realizzare il supporto nativo Windows. Non c’è ancora una data di disponibilità: è quindi prematuro parlare di Mojo 1.0 come già installabile direttamente su Windows senza WSL.

La collaborazione diretta con Microsoft è però quindi fondamentale: Windows ospita un’enorme comunità di sviluppatori Python, C++, .NET e AI; obbligare tutti a utilizzare WSL crea un vincolo che può essere accettabile per sperimentare un linguaggio, molto meno quando si pensa alla distribuzione di applicazioni e strumenti professionali.

Perché Mojo 1.0 è più interessante oggi rispetto al debutto

Al momento della presentazione, Mojo attirava attenzione soprattutto per l’idea provocatoria di combinare ergonomia simile a Python e prestazioni da linguaggio compilato. Tre anni dopo il quadro è più concreto. La versione stabile 1.0 esiste, il compilatore è consultabile e compilabile dai sorgenti, il progetto dichiara stabilità del codice sorgente e il supporto hardware non si limita più alle normali CPU e GPU.

Certo, c’è ancora tanto lavoro da fare. La compatibilità Python non è completa, Windows richiede ancora WSL, alcuni processi di contribuzione al compilatore devono essere aperti e il successo dipenderà anche dalla disponibilità di librerie, debugger, profiler, pacchetti e strumenti maturi.

La strada, però, è segnata: Mojo ha l’ambizione di offrire un livello comune che parte dal codice applicativo e può arrivare fino ai kernel ottimizzati per hardware molto diversi.

Se il supporto Windows arriverà con una toolchain realmente nativa e se l’apertura del compilatore attirerà contributi da produttori di acceleratori e sviluppatori indipendenti, Mojo 1.0 potrebbe quindi segnare il passaggio da progetto promettente a strumento realmente utilizzabile per sviluppare software ad alte prestazioni su CPU, GPU e acceleratori AI differenti.