Eine neue Sprach-Homepage ist unter mojolang.org live gegangen, und das Versprechen ist präzise: Python-Syntax, Rust-Speichersicherheit, Zigs Compile-Time-Metaprogrammierung, GPU-Kernel in der gleichen Datei wie dein CPU-Code. Modular, das Unternehmen hinter Mojo, nennt es «AI native» — eine kompilierte, statisch typisierte Sprache, gebaut um leistungskritisches Python aus dem Interpreter zu bewegen ohne Vollrewrite. Das ist ein echtes Problem für jeden, der numerischen oder generativen Code ausführt, daher lohnt sich ein Nachmittag. Aber lies zuerst bis zu Ende. Ein Satz dort ist die ganze Geschichte.

Warum das jetzt möglich ist

Mojo ist keine Idee aus dem Nichts. Sie baut auf MLIR auf, der Compiler-Infrastruktur, die aus dem LLVM-Projekt und Chris Lattners Swift-Arbeit wuchs — die gleiche Abstammung, die heute heterogene Hardware adressiert, CPUs und GPUs und Acceleratoren, aus einer Intermediate Representation. Das ist die Grenzverschiebung: Compiler-Forschung erreichte den Punkt, wo eine Sprache zu vielen Chips übersetzt wird ohne herstellerspezifische Bibliotheken oder separater kompilierter Kernel. Vor fünf Jahren schrieb man CUDA in einem Dialekt und Python in einem anderen und klebte sie mit Hoffnung zusammen. Mojos Behauptung: der Klebstoff ist weg.

Das Werkzeug: Mojo, von Modular. Es liest sich wie typisiertes Python, kompiliert vorab, exponiert SIMD und GPU-Primitive als First-Class-Syntax, und interoperiert mit dem CPython-Ökosystem — du kannst NumPy in Mojo importieren und Mojo zurück in Python. Die Homepage beweist die Behauptung mit zwei ausführbaren Kerneln: ein GPU-vector_add über einen TileTensor, und ein SIMD-mojo_square_array, der ein int64-Array in place quadriert durch simd_width_of[DType.int64]() — GPU- und CPU-Arbeit in einer Syntax geschrieben. Für einen Computational Designer, der eine Grasshopper-ähnliche Mesh-Routine profilet und feststellt, dass Python der Engpass ist, ist dieser inkrementelle Weg — eine Funktion umschreiben, den Rest behalten — das ehrliche Verkaufsargument.

Einrichtung

curl -fsSL https://pixi.sh/install.sh | bash
# Shell neustarten, dann:
pixi init hello-mojo && cd hello-mojo
pixi add mojo
pixi run mojo --version
echo 'def main(): print("Kaffi")' > hello.mojo
pixi run mojo hello.mojo   # prints: Kaffi

Erste Schritte:

1. Überprüfe die Toolchain: pixi run mojo --version sollte einen Build drucken. Falls nicht, hat deine Shell pixi nicht aufgegriffen — öffne das Terminal neu.
2. Öffne hello.mojo und füge eine typisierte Funktion hinzu: ein def square(x: Float64) -> Float64: return x * x, rufe sie in main auf, führe es erneut aus. Du hast jetzt eine kompilierte, statisch typisierte Funktion.
3. Ersetze die Scalar-Schleife mit der SIMD-Form aus den Docs (füge .md an jede mojolang.org-Seite an, um sie als Markdown zu lesen) und führe aus. Gleiches Ergebnis, anderer Durchsatz — diese Lücke ist der Punkt.

←TODAY: Mojos Standard Library ist vollständig Open-Source auf GitHub; der Compiler nicht — Modular sagt, es plant, ihn 2026 Open-Source zu machen. →3012: die Workflows, die überleben, sind genau die, deren Fundament du forken durftest. Fulcrum: eine Sprache ist nur so tragbar wie ihre am wenigsten offene Schicht, und heute ist diese Schicht der Compiler.

Der Kontrollmechanismus, benannt

Hier ist der Satz. Modular schreibt, dass es sich verpflichtet, alles Mojo Open-Source zu machen, «aber die Sprache ist noch sehr jung und wir glauben, dass eine enge Gruppe von Ingenieuren mit gemeinsamer Vision schneller voran kommt als ein Community-getriebener Aufwand.» Das ist eine verteidigbare Engineering-Entscheidung. Es ist auch, präzise, die Form von Open-Core-Lock-in: die Teile, die du inspizieren kannst, sind offen, der Teil, der deinen Build entscheidet, nicht. Die Frage ist also nicht, ob Mojo gut ist. Es ist klar, dass es ist. Die Frage ist, was du einem Compiler schuldest, den du noch nicht forken darfst, und was dieser dich später kosten kann.

Atelier: Ein Schweizer Computational-Design-Büro, das Mojo evaluiert, sollte es als Abhängigkeit behandeln, nicht als Religion. Der Zug: bevor Mojo-Code eine Abrechnungs-Pipeline berührt, schreibe die Ausstiegsklausel — eine Seite, die auflistet, welche Funktionen portiert wurden, was der reine-Python-Fallback ist, und der Trigger (Lizenzänderung, Preisänderung, verzögertes 2026-Open-Source-Datum), das dich zurückschickt. Teste Mojo auf einem unkritischen Kernel; halte die CPython-Version im Repo, nicht im Gedächtnis.

Hack: Messe eine heisse Schleife in Mojo, dann die identische in Standard-CPython, bevor du eine Zeile Production-Code migrierst. Migrationsentscheidungen auf Vendor-Benchmarks sind vom Vendor getroffen.

def main():
    var total: Float64 = 0.0
    for i in range(10_000_000):
        total += Float64(i) * Float64(i)
    print(total)

Verpacke es als pixi run bash -c 'time mojo hello.mojo', führe dann time python -c "print(sum(i*i for i in range(10_000_000)))" aus und lies die Wall-Clock-Lücke. Die Zahl, die du bekommst, ist deine, gemessen auf deiner Hardware — der einzige Benchmark, den eine Beschaffungsnote zitieren sollte.

Learn-it:

• Sprach-Home: mojolang.org
• Docs (füge .md an jede Seite an, um sie als Markdown zu lesen): mojolang.org/docs/manual/basics
• Vollständiger Dokumentations-Index für Tools und Agenten: mojolang.org/llms.txt
• PAZ-Notiz: kombiniere das mit unserem Creative-Coding-Concept-Panel — der gleiche «drei Parameter exponieren, eine Familie von Ergebnissen bekommen»-Instinkt, den p5.js im Browser lehrt, ist das, was einen schnellen Kernel überhaupt wert macht zu schreiben.

Der Zug

Klone das Setup, portiere genau eine Funktion, der du schon vertraust, und benchmark sie gegen ihr Python-Twin auf deinem Rechner. Dann schreibe die Ausstiegsklausel im gleichen Commit. Nimm Mojo für die Geschwindigkeit; behalte den Fallback für den Tag, wenn die Compiler-Lizenz, nicht seine Leistung, die Geschichte wird.