- Chris Lattner ist ein zentraler Entwickler von LLVM und der Sprache Swift und entwickelt derzeit die neue Sprache Mojo, um die Leistung moderner ML-Hardware maximal auszuschöpfen
- Mojo soll als Sprache sowohl gute Nutzbarkeit als auch feingranulare Kontrolle über Hardware-Details bieten und unterstützt durch typsichere Metaprogrammierung einen effizienten Umgang mit Hardware-Spezifika
- Ein zentraler Hintergrund ist der Aufbau einer vereinheitlichten Computing-Plattform, um die Fragmentierung des AI-Beschleuniger-Ökosystems mit GPU, TPU, ASIC usw. zu lösen und die Abhängigkeit von einzelnen Anbietern zu verringern
- Wegen Kompatibilitäts- und Komplexitätsproblemen bestehender GPU-Software-Stacks (CUDA, ROCm, XLA usw.) ist die Entwicklung einer nächsten Generation von Sprachen für hohe Performance und Portabilität unerlässlich
- Modular verfolgt ein Geschäftsmodell, bei dem Mojo kostenlos angeboten wird und der Fokus auf der Lösung realer Probleme wie integrierter Hardware-Unterstützung und Enterprise-Services liegt
Vorstellung von Chris Lattner und sein Karriereweg
- Chris Lattner hat Erfahrung in der Leitung mehrerer Schlüsselprojekte der Computertechnik, darunter LLVM, Clang, MLIR, Swift und Mojo
- Er arbeitete bei Apple, Tesla, Google, SiFive, Modular und weiteren Organisationen und sammelte umfassende praktische Erfahrung in Compiler- und Programmiersprachen-Design
- Am Anfang standen einfache Sprachen wie BASIC und PC-Umgebungen; über Spiele und Grafik entwickelte er ein Interesse an der maximalen Ausnutzung von Hardware-Leistung
- Während des Studiums entdeckte er eher zufällig durch den Einfluss eines Professors für Compiler seine Faszination für Systeme und großskalige Software-Architekturen
Zwischen Compilerbau und Sprachdesign
- Chris Lattner verfügt sowohl über Erfahrung in Compiler-Engineering als auch Sprachdesign und erzielte an der Schnittstelle beider Bereiche große Erfolge
- LLVM etwa ist eine Zwischensprache, die von vielen Sprachen genutzt werden kann, und hat weitreichende Einsatzfälle nicht nur in C++-Implementierungen, sondern auch in Rust, Julia und anderen geschaffen
- Auch die Entwicklung von Swift begann als Versuch, die Grenzen und die Ermüdung durch bestehende C++-Implementierungen zu überwinden, wobei die Notwendigkeit praktischer Funktionen wie Pattern Matching betont wurde
- Bei Innovationen in Programmiersprachen bevorzugt er einen Ansatz, der sich weniger auf mathematische Theorie als auf konkrete Problemlösung und Nutzen stützt
Theorie der Programmiersprachen und Praxisnähe
- Chris verfolgt eher ein problemorientiertes als ein mathematisch rigoroses Denken und interessiert sich bei PL-Papers weniger für die Theorie selbst als für praktische Beispiele und Einsatzszenarien
- Er erkennt an, dass sprachliche Features mit starker mathematischer Grundlage Vorteile bei Konsistenz und Kombinierbarkeit haben, doch sichtbarer praktischer Nutzen ist der eigentliche Treiber für Einführung und Akzeptanz
- Er betont, wie wichtig es ist, bei neuen Sprachen oder Technologien die „Sandkorn“-Komplexität so weit wie möglich zu reduzieren, um Vereinfachung des Designs und Erweiterbarkeit zu fördern
Strukturelle Probleme im AI-Hardware-Ökosystem
- Die traditionelle Compiler-Infrastruktur (LLVM) war CPU-zentriert, während AI/Machine Learning vielfältige Spezialhardware wie GPU, TPU, ASIC und FPGA erfordert
- Jeder Anbieter entwickelt seinen eigenen Software-Stack (CUDA, ROCm, XLA usw.), was zu mangelnder Kompatibilität und einer gespaltenen Ökosystemlandschaft führt
- ML-Software wie etwa PyTorch benötigt getrennte Optimierungen für verschiedene Hardware-Anbieter, was Wartung und Erweiterung stark erschwert
- Da sich Stack, Sprache und Tool-Ökosystem je nach Hardware unterscheiden, leiden Produktivität und Portabilität aus Sicht von Softwareentwicklern erheblich
Die Rolle von Modular und Mojo
- Das Team von Modular konzentriert sich darauf, zur Lösung dieser Probleme eine allgemeine und integrierte Software-Plattform aufzubauen
- Mojo ist darauf ausgelegt, nicht nur die leistungsorientierten Eigenschaften moderner GPU-Architekturen wie Tensor Cores auszunutzen, sondern auch portable Kernel für verschiedene Hardware zu ermöglichen
- Mit einer mehrschichtigen Struktur aus Mojo, MAX (u. a. High-Performance-LLM-Serving) und Mammoth (Cluster-/Kubernetes-Management) wird eine integrierte AI-Infrastruktur bereitgestellt
Warum Mojo nötig ist und welche Sprachdesign-Entscheidungen dahinterstehen
- Mit bestehenden Sprachen lassen sich die beiden Anforderungen Portabilität hochperformanter ML-Kernel und anbieterbezogene Optimierung nicht gleichzeitig erfüllen
- Mojo muss dynamisch auf Hardware-Details reagieren können, etwa auf verschiedene Datentypen wie 8-Bit-Floating-Point und auf sich rasant verändernde Hardware wie Tensor Cores
- Mit einem typsicheren Metaprogrammierungsmodell wird komplexe Hardware-Kontrolle effizienter und besser teilbar gemacht
Veränderungen bei Hardware- und Kernel-Design
- Die CPU moderner Rechenzentren skaliert zwar auf viele Kerne, doch die GPU hat sich mit auf Parallelverarbeitung spezialisierten Designs wie SMs (Streaming Multiprocessors) und Warps (Ausführung mit 32 Threads) rasant weiterentwickelt
- Durch die Einführung AI-spezifischer Recheneinheiten wie Tensor Cores in Hardware wird ein Hardware-Programmierparadigma nötig, das sich deutlich von traditionellem CUDA unterscheidet
- Selbst innerhalb desselben Anbieters ändern sich die Kompatibilitätsbedingungen häufig zwischen Architektur-Generationen (z. B. Nvidia Volta/Hopper/Blackwell), und die Software-Stacks halten damit nicht Schritt
Geschäftsmodell und Strategie für ein offenes Ökosystem
- Modular konzentriert sich nicht auf den Verkauf der Sprache selbst, sondern stellt Mojo kostenlos bereit
- Das zentrale Erlösmodell basiert auf Plattform- und Serviceangeboten für integriertes Hardware-Management und Enterprise-Kunden
- So will das Unternehmen ein gemeinsames Ökosystem ohne Vendor Lock-in aufbauen und gleichzeitig breite Hardware-Unterstützung sowie effizientes Infrastruktur-Management vorantreiben
Fazit
- Das Mojo-Projekt von Chris Lattner und Modular ist bedeutsam, weil es den Aufbau einer neuen Programmiersprache und Plattform für fortgeschrittenes Machine Learning, AI-Hardware-Innovation und die Überwindung von Ökosystem-Fragmentierung verfolgt
- Mit innovativem Sprachdesign und der Ausweitung eines offenen Ökosystems soll es zur Demokratisierung des AI-Ökosystems und zu höherer Produktivität beitragen
1 Kommentare
Hacker-News-Kommentare
Ich möchte mich bei allen bedanken, die Interesse an Mojo und dem Podcast gezeigt haben. Wer mehr über Mojo erfahren möchte, findet im FAQ Antworten auf häufige Fragen (auch auf „Warum verbessert ihr nicht einfach Julia?“). Die Dokumentation ist ebenfalls hier verfügbar, und auch der Open-Source-Code mit mehreren hunderttausend Zeilen ist öffentlich. Die Mojo-Community ist außerdem wirklich großartig, daher würde ich mich freuen, wenn ihr im Discourse-Forum oder im Discord-Chat vorbeischaut – Kommentar von Chris Lattner
Ich bin ein Fan. Ich habe mehrere Vorträge über Mojo gesehen, und obwohl immer gesagt wird, dass Mojo modernste Compiler-Technologien nutzt, habe ich nie konkrete Beispiele dazu gehört. Auch wenn man als Nicht-Compilerentwickler vielleicht nur 20 % versteht, würde ich gern einmal wirklich sehen, was an diesen fortgeschrittenen Techniken so besonders ist. Ein wirklich tiefgehender und technischer Blogpost dazu wäre großartig
Im FAQ wird auf die Frage „Ist der Mojo Playground noch verfügbar?“ auf genau diesen Playground verwiesen, aber dort steht dann, dass der Playground in der nächsten Version 25.6 entfernt wird. Wenn die FAQ auf die Frage, ob etwas verfügbar ist, auf eine Funktion verweist, die bald entfernt wird, verfehlt das irgendwie den Kern. Praktisch lautet die Antwort also wohl eher: „Nicht mehr lange“
Chris, schön, dich hier zu sehen. Ich habe damals sogar über Light Table investiert und frage mich, ob es dazu irgendwelche Updates gibt. (Nicht ganz ernst gemeint, aber Mojo sieht schon ziemlich cool aus.) Mich würde interessieren, wie es mit der langfristigen Tragfähigkeit solcher Projekte aussieht und ob es dafür eine belastbare Grundlage gibt
Python dominiert den ML-Bereich, weil moderne ML-Anwendungen keine bloßen Rechenskripte sind, sondern eine breite Funktionalität und ein robustes Ökosystem verlangen. Datenvorverarbeitung aller Art (ETL), Verarbeitung verschiedenster Datenformate, verteilte Verarbeitung auf High-Performance-Computing-Clustern, Visualisierung sowie GUI-/DB-Integration – all das deckt außer Python praktisch keine Sprache ab. Numerische Berechnungen sind durch den internen Einsatz von C/C++/FORTRAN in NumPy, PyTorch, JAX usw. ohnehin sehr schnell, und performancekritischer Code lässt sich leicht separat in C/C++ implementieren. Auch Pythons C/C++-FFI-System ist im Vergleich zu anderen Sprachen ausreichend praxistauglich. Das hat viel mehr Vorteile, als das gesamte Ökosystem in anderen Sprachen wie Julia noch einmal nachzubauen
Das Python-Ökosystem ist unerreicht, aber die Kombination aus Elixir/Nx leistet schon jetzt einen großen Teil dessen, was Mojo verspricht. Über EXLA ist GPU-/TPU-Kompilierung möglich, mit Explorer/Polars kann man DataFrame-Arbeit erledigen, und mit Pythonx lassen sich Python-Bibliotheken einbetten. Der Unterschied ist, dass Elixir von Anfang an auf verteilte Systeme ausgerichtet war, sodass BEAM/OTP massive gleichzeitige Anfragen und die Koordination zwischen GPU-Knoten bewältigen kann. Wenn man tatsächlich ML-Services baut, kann ein solider Stack aus Phoenix, LiveView und Nx mit extremer Fehlertoleranz und Skalierbarkeit wichtiger sein als ein kleiner Hardware-Performancevorteil
Ich sehe das auf der Inference-Seite etwas anders. CUDA-Kernel direkt anzupassen und zu bauen ist nicht schwer, und das aktuelle CUTLASS 3 sowie modernes C++ sind deutlich komfortabler geworden. Darauf sitzt Torch nur als dünne Schicht, und genau dieser Teil ist schwer zu bauen und macht wegen Referenzzählung und verschiedener anderer Probleme alles nur komplexer. Die eigentliche Kernimplementierung steckt unten in den Kerneln, und ich denke, dass wir diesen „Torch-Überzug“ bald entfernen und stattdessen sauber an ein klares C++-Programm anbinden werden
Dieses Problem betrifft GPU-Kernel, und solche Kernel schreibt man von vornherein nicht in Python. Python ist für ML eine „Glue“-Sprache. Der Aussage „Nur Python bietet all diese Fähigkeiten“ stimme ich zu, aber es ist trotzdem ein wenig schade, dass das Ökosystem um Python gewachsen ist und nicht um eine bessere Sprache
Dass Python zur führenden ML-Sprache geworden ist, ist ein „positiver Rückkopplungseffekt“. Das Ökosystem ist groß geworden, weil Python bereits gewählt war; warum es ursprünglich gewählt wurde, muss getrennt erklärt werden. Heute ist es so groß, dass es uneinholbar wirkt, aber das erklärt nicht wirklich, warum es überhaupt Python geworden ist
Ironischerweise ist Python für all die genannten Aufgaben die schlechteste denkbare Sprache. Packaging und Binaries (
wheel) sind beide schmerzhaft, und ständig geht irgendetwas kaputt. Für einzelne Skripte ist es okay, aber wenn Python mit dem Ziel entworfen worden wäre, die Hauptsprache für ML zu werden, hätte niemand sich gewünscht, dass es so aussiehtIch war schockiert, als ich die Episode gehört habe. Dass selbst im September 2025 Klassensupport noch ein mittelfristiges Ziel sein soll, hat mich überrascht. Früher wurde Mojo oft als „superset of Python“ beworben, aber beim aktuellen Fortschrittstempo wirkt das eher wie ein Idealziel
Tatsächlich war „Python-Superset“ nie wirklich das Ziel. Das war eher ein Slogan, um Aufmerksamkeit zu erzeugen; anfangs wurde das stark betont und dann stillschweigend zurückgenommen
Vielleicht liegt es nicht an der Geschwindigkeit, sondern daran, dass man OOP an sich nicht mag
Es war schon immer ein langfristiges Ziel
Vielleicht ist das eine häufige Frage, aber ich frage mich, warum es nicht Lisp geworden ist. Wenn man annimmt, dass künftiger ML-Code letztlich von Maschinen (oder Systemen zur automatischen Umwandlung auf Basis natürlicher Sprache) geschrieben wird, dann sind Lisp-S-Expressions für Maschinen am natürlichsten, weil sie praktisch dem AST entsprechen. Da meist auch eine vollwertige REPL-Umgebung vorhanden ist, scheint das auch als Python-Ersatz hervorragend zu passen
Yann LeCun und andere haben mit Lush einmal ein Lisp für ML entwickelt. In den 2000ern war das Spitze, und bevor Python (Theano) oder Lua (Torch) kamen, gab es kaum Alternativen. Ich wünschte, Lisp würde heute wieder mehr Aufmerksamkeit bekommen. Python hat großartige Bibliotheken, aber an der Sprache selbst gibt es noch einiges zu verbessern
LLMs (große Sprachmodelle) sind noch nicht besonders gut darin, Klammern zu zählen ;)
Weil Lisp während früherer AI-Booms schon einmal links liegen gelassen wurde, verwenden viele Entwickler bis heute nur Emacs + SBCL. In Wirklichkeit gibt es aber auch andere hochwertige Lisp-Implementierungen wie LispWorks, Allegro oder Clozure, die viele einfach nie ausprobiert haben
Schon die Lizenz von Mojo gefällt mir nicht
Ich habe es mir auch angesehen: In der Mojo-Lizenz wird zwischen CPU- oder Nvidia-Nutzung und anderen „Beschleunigern“ (TPU, AMD usw.) unterschieden, und für kommerzielle Nutzung sei eine separate Lizenz nötig siehe Blog
Aus meiner Sicht gibt es überhaupt keinen Grund, eine Sprache wie Mojo, die vollständig unter der Kontrolle eines einzelnen Unternehmens steht, in einem Geschäftsumfeld einzusetzen. Bei den Java-Lizenzänderungen haben schon viele Unternehmen schlechte Erfahrungen gemacht. Ein Geschäft auf Mojo statt auf Python aufzubauen, ist viel zu riskant
Im Mojo-FAQ klingt es so, als strebe man im strengen Sinn ein Python-Superset an, aber in der Roadmap steht wiederum: „bietet Python-Code und Vertrautheit, kann aber kein vollständiges Superset sein“, was nur noch mehr Verwirrung stiftet. Wenn Python-Kompatibilität nicht das Ziel ist, verstehe ich nicht, warum Python immer wieder erwähnt wird. Und ich frage mich, ob die Sache mit einer Emoji-Dateiendung tatsächlich stimmt
Soweit ich weiß, zielt Mojo nur auf eine Python-artige Syntax und Interoperabilität mit Python. Alles, was darüber hinaus nach besonderer Python-Ähnlichkeit klingt, ist weitgehend Marketing
Was die Emoji-Endung angeht: Ja, das stimmt. Es ist U+2615 (Kaffee-Emoji)
Ich würde gern wissen, worin Mojo Julia überlegen sein soll. Julia hat zwar ebenfalls Grenzen bei Interfaces und Ökosystem, aber die Anbindung an Python funktioniert dort inzwischen auch gut, daher sehe ich nicht wirklich, was Mojo besser machen soll
Gerade Julia hat mit JuliaGPU und Reactant ein gut ausgebautes GPU-Ökosystem siehe Reactant.jl
Die Python-Kompatibilität ist bei Mojo vielleicht etwas besser, aber über PythonCall.jl lassen sich auch in Julia Python-Bibliotheken recht stabil aufrufen. Auch ML-Frameworks wie Lux.jl und Flux.jl funktionieren innerhalb von Julia gut. In Mojo scheint es noch kein vergleichbares natives ML-Framework zu geben
Mojo scheint eher auf ein deutlich Low-Level-näheres Sprachgefühl, mehr Kontrolle und Robustheit abzuzielen. Julia ist in Bedeutung und Performance nicht vorhersehbar genug und deshalb als Grundlage kritischer Software ungeeignet, während Mojo dort im Vorteil ist
Ich wollte Python-Module in Julia erstellen, hatte aber den Eindruck, dass die Unterstützung dafür noch unzureichend ist. Bei Mojo ist das ein Kernfeature
Julia kann Code noch nicht wirklich vollständig zu nativen Binärdateien kompilieren, also so wie Rust oder C++
Dass Mojo nicht riesige Aufmerksamkeit bekommt und PyTorch weiterhin genutzt wird, könnte ein Hinweis darauf sein, dass die Lizenzfrage in der Praxis doch wichtiger ist als erwartet
Vielleicht hat Mojo sein eigenes Spielfeld zu optimistisch eingeschätzt. Auch Julia wird in der Praxis schrittweise immer stärker kommerziell genutzt und hat gute GPU-Unterstützung. Selbst wenn Pythons JIT-Compiler schwach sind, optimieren Nvidia, Intel und andere GPGPU-Programmierung bereits stark über Python-DSLs, sodass man innerhalb von Python fast auf C++-Niveau arbeiten kann. Letztlich hat Mojo damit nur ein schwaches Alleinstellungsmerkmal
Aus Systemsicht ist der Versuch von Chris und seinem Team beeindruckend, mit Mojo die Probleme mehrsprachiger FFI grundsätzlich zu bereinigen. Aber bevor es Open Source wird, kann ich weder über Investitionen noch über einen Einsatz ernsthaft sprechen
Es ist noch nicht bereit, als allgemeine Programmiersprache verwendet zu werden. Selbst Modular wollte die Mojo-API auf die MAX-Engine anwenden, hat die Investition aber wegen der zu schnellen Sprachänderungen aufgegeben. Laut Roadmap ist ein echter Einsatz erst nach Abschluss von Phase 1 zu erwarten
Ich bin mir nicht sicher, ob es wirklich als öffentlich gelten kann. Bis vor Kurzem war es noch nicht Open Source, und ich habe Hemmungen, mich auf proprietäre kommerzielle Software zu verlassen
Gleich am Anfang des Artikels heißt es, dass man „modernste Kernel“ verwenden könne. Am Ende scheint Mojo also mit C++ bei der Kernel-Entwicklung konkurrieren zu wollen. In PyTorch oder Julia schreibt man Kernel normalerweise nicht direkt, sondern arbeitet überwiegend auf höherer Ebene
Es gibt Podcast-Episoden von Lex Fridman mit Chris Lattner:
Der Versuch mit Mojo ist mutig und interessant, aber wenn es wie Matlab eine geschlossene Sprache bleibt, ist das für mich und viele andere ein gravierender Ausschlussgrund