Mojo 1.0 Beta

(mojolang.org)

3 Punkte von GN⁺ 7 시간 전 | 1 Kommentare | Auf WhatsApp teilen

Mojo bezeichnet sich als eine Sprache, die „wie Python geschrieben und wie C++ ausgeführt“ wird, und stellt derzeit die stabile Version 1.0.0b1 (7. Mai) bereit
Ziel ist es, schnellen Code für verschiedenste Hardware von CPU bis GPU zu schreiben, ohne an einen bestimmten Vendor gebunden zu sein; die Sprache ist als performante statisch typisierte Sprache für moderne AI-Systeme konzipiert
Python-Interoperabilität wird nativ unterstützt, sodass nicht der gesamte bestehende Code neu geschrieben werden muss, sondern nur Performance-Engpässe nach Mojo verlagert werden können; unterstützt werden sowohl Python-Imports in Mojo-Code als auch der Import von Python-Bibliotheken
GPU-Kernel lassen sich in derselben Sprache schreiben, und Compile-Time-Metaprogrammierung mit derselben Sprache wie der Runtime-Code soll hardwareabhängige Optimierungen und Zero-Cost-Abstraktionen ermöglichen
Die Mojo-Standardbibliothek ist auf GitHub vollständig Open Source veröffentlicht und nimmt Beiträge an; für den Mojo-Compiler ist eine Open-Source-Veröffentlichung im Jahr 2026 geplant

Versionen und Einstiegsmaterialien

Die aktuelle stabile Version ist 1.0.0b1 (7. Mai), das neueste Nightly ist 9. Mai
Mojo ist inspiriert von der intuitiven Syntax von Python, der Speichersicherheit von Rust und der leistungsfähigen und intuitiven Compile-Time-Metaprogrammierung von Zig
Als kompilierte statisch typisierte Sprache eignet sie sich auch für agentenorientierte Programmierung
Statt zwischen Produktivität und Performance wählen zu müssen, ist das Ziel, beides zu bieten; man kann mit einfachen und vertrauten Programmiermustern beginnen und bei Bedarf Komplexität hinzufügen
Als Startpunkte werden Install Now, Quickstart, Releases, Roadmap und GitHub angeboten
Um Seiten als Markdown zu sehen, kann man .md an die URL anhängen; der vollständige Index der Mojo-Dokumentation ist unter llms.txt verfügbar

GPU und Python-Interoperabilität

GPU-Programmierung

Mojo will GPU-Programmierung ohne vendorspezifische Bibliotheken oder separaten zu kompilierenden Code zugänglich machen
Performante GPU-Kernel können in derselben Sprache geschrieben werden, die auch für die CPU verwendet wird

Der Beispiel-Kernel vector_add nimmt TileTensor entgegen und führt auf Basis von global_idx.x result[i] = a[i] + b[i] aus

def vector_add(  
    a: TileTensor[float_dtype, type_of(layout), element_size=1, ...],  
    b: TileTensor[float_dtype, type_of(layout), element_size=1, ...],  
    result: TileTensor[  
        mut=True, float_dtype, type_of(layout), element_size=1, ...  
    ],  
):  
    var i = global_idx.x  
    if i &lt; layout.size():  
        result[i] = a[i] + b[i]

Python-Interoperabilität
- Mojo ist nativ interoperabel mit Python und kann Performance-Engpässe beseitigen, ohne den bestehenden Code vollständig neu zu schreiben
- Man kann mit einer einzelnen Funktion beginnen und den Ansatz dann je nach Bedarf auf performancekritischen Code in Mojo ausweiten
- Mojo-Code lässt sich natürlich in Python importieren und zusammen mit Deploy-Paketen bündeln
- Umgekehrt können innerhalb von Mojo-Code auch Bibliotheken aus dem Python-Ökosystem importiert werden
- Die Beispielfunktion mojo_square_array holt sich einen Pointer aus ctypes.data von PythonObject, berechnet die SIMD-Breite zur Compile Time und quadriert die Array-Elemente
```
# SIMD-vectorized kernel squaring array elements in place.  
def mojo_square_array(array_obj: PythonObject) raises:  
    comptime simd_width = simd_width_of[DType.int64]()  
    ptr = array_obj.ctypes.data.unsafe_get_as_pointer[DType.int64]()  
    def pow[width: Int](i: Int) unified {mut ptr}:  
        elem = ptr.load[width=width](i)  
        ptr.store[width=width](i, elem * elem)  
    vectorize[simd_width](len(array_obj), pow)  
```

Compile-Time-Metaprogrammierung

Die Metaprogrammierung von Mojo bietet ein intuitives System zur Maximierung der Performance, das dieselbe Sprache wie der Runtime-Code verwendet
Mit bedingter Kompilierung lassen sich hardwareabhängige Optimierungen erstellen, Compile-Time-Auswertung kann Speichersicherheit gewährleisten und teure Runtime-Verzweigungen eliminieren
Ziel ist es, Zero-Cost-Abstraktionen bereitzustellen und dabei die Absicht klar auszudrücken

Die Beispiel-Implementierung von __eq__ verwendet Compile-Time-Reflection, um Namen und Typen von Struct-Feldern zu erhalten, prüft dann, ob alle Felder Equatable erfüllen, und führt anschließend feldweise Equality-Prüfungen aus

# Generic struct equality using compile-time reflection.  
@always_inline  
def __eq__(self, other: Self) -&gt; Bool:  
    comptime r = reflect[Self]()  
    comptime names = r.field_names()  
    comptime types = r.field_types()  
    comptime for i in range(names.size):  
        comptime T = types[i]  
        comptime assert conforms_to(T, Equatable), &quot;All fields must be Equatable&quot;  
        if trait_downcast[Equatable](  
            r.field_ref[i](self)  
        ) != trait_downcast[Equatable](r.field_ref[i](other)):  
            return False  
    return True

Roadmap und Open Source

Mojo wurde Ende 2022 gestartet, und es bleibt noch viel zu tun
Phase 0
- Phase zum Aufbau des anfänglichen Fundaments
- In dieser Phase werden der Kern-Parser, Speichertypen, Funktionen, Structs, Initialisierer, Calling Conventions und weitere Sprachgrundlagen implementiert
Phase 1
- Die derzeit laufende Phase
- Ziel ist es, die Sprache zu einem leistungsfähigen und ausdrucksstarken Werkzeug für das Schreiben performanter Kernel auf CPU, GPU und ASIC zu machen und Entwickler in die Lage zu versetzen, Python nahtlos zu erweitern
Phase 2
- Phase für Systemanwendungsprogrammierung
- In dieser Phase wird die Sprache erweitert, um ein garantiert speichersicheres Modell und mehr Abstraktionsfunktionen zu unterstützen, wie sie Entwickler im Systemprogrammierbereich erwarten
Phase 3
- Phase für dynamische objektorientierte Programmierung
- In dieser Phase werden mehr dynamische Python-Funktionen wie Klassen, Vererbung und untypisierte Variablen unterstützt, um die Kompatibilität mit Python-Code zu maximieren
- Weitere Details finden sich in der Mojo roadmap
- Die Mojo-Standardbibliothek ist auf GitHub vollständig Open Source veröffentlicht und nimmt Beiträge an
- Der Mojo-Compiler soll 2026 Open Source werden
- Es gibt zwar die grundsätzliche Linie, Mojo vollständig Open Source zu machen, doch da die Sprache noch sehr jung ist, wird eingeschätzt, dass eine eng zusammenarbeitende Gruppe von Ingenieuren mit gemeinsamer Vision schneller vorankommt als ein rein Community-getriebener Ansatz
- Als Beteiligungsmöglichkeit wird die developer community angeboten

Lern- und Community-Materialien

Install und Quickstart guide: Materialien für den Einstieg in Mojo
Beginner tutorial: Mojo lernen, indem man Game of Life erstellt
GPU puzzles: GPU-Programmierung mit Mojo durch das Lösen von Rätseln lernen
Intro to Mojo: Einführung in die Funktionen der Mojo-Sprache insgesamt
Developer forum: Fragen und Updates rund um Mojo
Events: Informationen zu Events, Meetups, Vorträgen und Hackathons
Contributions: Hinweise zu offenen Issues, Dokumentationsbeiträgen und dem Teilen von Projekten

1 Kommentare

GN⁺ 7 시간 전

Hacker-News-Kommentare

Ich habe in den letzten zwei Jahren zum Spaß viel mit Mojo herumgespielt, und es ist wirklich eine großartige Sprache
Es gibt ein Ownership-Modell ähnlich wie bei Rust, mächtigere Compile-Time-Ausführung als bei Zig, ein reichhaltiges Typsystem und erstklassige SIMD-Unterstützung
Auch leistungsmäßig wirkt es seit Langem mal wieder wie eine Sprache und nicht nur wie ein einfacher LLVM-Wrapper. LLVM wird zwar weiterhin genutzt, aber auf eine andere Weise als bei Rust oder Zig
Wenn es Ende dieses Jahres Open Source wird, freue ich mich sehr auf Mojo
- Es wäre gut, den Teil mit der „mächtigeren Compile-Time-Ausführung als bei Zig“ etwas genauer zu erklären
  Allein aus der aktuellen Mojo-Dokumentation ist diese Schlussfolgerung schwer nachzuvollziehen
Als jemand, der im Machine Learning arbeitet und sich für Performance interessiert, hoffe ich, dass Mojo erfolgreich wird. Besonders spannend finde ich, dass man GPU- und CPU-Code in derselben Sprache mischen kann
Ich mache mir allerdings Sorgen, dass die aktuellen Änderungen Python-Entwickler eher abschrecken könnten. Als ich es zuletzt ausprobiert habe, wollte ich einfache String-Manipulation testen und habe var x = 'hello'; print(x[3]) versucht, aber das funktionierte nicht, und len(x) ging auch nicht, sodass ich eine Stunde festhing
Wie sich herausstellte, wollte man Byte- und Codepoint-Darstellungen stärker voneinander trennen, aber die Dokumentation widersprach der tatsächlichen Implementierung
Ich hoffe, dass es auch für allgemeineres Machine Learning brauchbar wird, aber im Moment wirkt es noch ziemlich eingeschränkt. Einige brauchbare Grundfunktionen rund um Tensoren wurden ebenfalls entfernt
Vorerst werde ich wohl weiter JAX verwenden und nur gelegentlich wieder nachsehen
- Ich verstehe nicht, warum es noch keine Sprache gibt, die einfachen, rechenlastigen Code mit minimaler Zusatzsyntax zumindest in SIMD / Multithreading / Multiprocessing / GPU-Code umwandelt
  So etwas klingt doch nach dem Traum von Leuten, die sich für Compiler und Sprachdesign interessieren
  Sie muss nicht in jeder Situation Effizienz garantieren oder absolute Spitzenleistung liefern, es wäre schon gut, wenn sie einfach existieren würde
  Ich verstehe, dass man so eine Sprache bauen könnte, aber offenbar hat sie die Leute, die dazu fähig wären, nicht interessiert
- Mojo ist cool, aber ich verstehe nicht, warum man so sehr an der Abwärtskompatibilität zu Python festhält. Dadurch steht es sich selbst im Weg
  Fast alle Nachteile, die mir bei Kotlin einfallen, kommen von der Java-Kompatibilität. Hier hätte man es vielleicht expliziter besser lösen können, aber der aktuelle Ansatz wirkt zum Scheitern verurteilt
- Wenn es nicht Open Source ist, hat es kaum Bedeutung. Die meisten Python-Entwickler werden ohnehin nicht kommen
- Unter diesem Aspekt wirkt es fast so, als wolle man die Programmiersprache Nim noch einmal bauen
Es heißt dort: „Wir haben versprochen, Mojo im Herbst 2026 als Open Source zu veröffentlichen“
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
- Es wäre schön, wenn man den Quellcode eines echten hochmodernen MLIR-Programms sehen könnte
Leider ist Nvidia in der Zwischenzeit auch nicht untätig geblieben und hat mit einem ähnlichen, auf MLIR basierenden Compiler-Stack das Next-Gen-CUDA CuTile für Python und bald auch für C++ geschaffen
Selbst wenn es nicht portabel ist, wird es wahrscheinlich viel stärker genutzt werden als Mojo, einfach weil Nvidia es massiv pusht, es in die Entwicklerwerkzeuge integriert wird und neben bestehendem CUDA-Code funktioniert
Tile IR dürfte eher eine Reaktion auf die Bedrohung durch Triton als durch Mojo gewesen sein. Das gilt besonders, wenn man schaut, wie einfach sich halbwegs performante LLM-Kernel schreiben lassen
- Um nicht zurückzufallen, unternehmen auch Intel und AMD ähnliche Anstrengungen, und auch CPython JIT wird nach mehreren Versuchen endlich Realität
  Es gibt auch Ansätze wie GraalPy und PyPy
  All diese Bemühungen laufen derzeit unter Windows. Das ist ziemlich wichtig in Umgebungen, in denen die meisten Mitarbeiter im Unternehmen Windows-Geräte bekommen und nur die Server Linux-Distributionen nutzen
  Das lässt mich immer wieder daran denken, ob das nicht wie ein weiteres Swift for Tensorflow enden könnte
- Nach Gesprächen mit einigen Tile-IR-Entwicklern war die Hauptmotivation, bessere Portabilität für Tensor-Core-Programmierung als mit PTX zu bieten
  Abgesehen von Kundenfeedback hat niemand gesagt, dass es eine Reaktion auf irgendetwas sei
- Viele verwechseln Mojo mit einfach nur guter Syntax zum Schreiben von GPU-Code und glauben, Nvidias Python-Frameworks würden diese Rolle bereits erfüllen
  Aber wird CuTile auch auf AMD-GPUs oder Apple Silicon laufen? Egal was Nvidia tut, Vendor Lock-in bleibt bestehen
- Ich frage mich, wie groß der Einfluss von CuTile wirklich ist
Als ich zum ersten Mal von Mojo hörte, dachte ich, es solle mit bestehendem Python-Code kompatibel sein
Aber in naher Zukunft scheint es von diesem Ziel sehr weit entfernt zu sein. Man wird zwischen Python und Mojo hin- und heraufrufen können, aber Mojo selbst kann bestehenden Python-Code nicht ausführen
- In der ursprünglichen Vermarktung war das eindeutig einer der zentralen Punkte. Es hieß sinngemäß, dass man durch das Hinzufügen von Type Hints zu Python-Code große Geschwindigkeitsgewinne erzielen könne
  Aber im Laufe der tatsächlichen Entwicklung scheint sich die Richtung geändert zu haben
- Wenn ich mich richtig erinnere, wurden auch 36.000-fache Geschwindigkeitssteigerungen gegenüber entsprechendem Python beworben, ohne klarzumachen, dass das nur in extremen Edge Cases möglich ist
  Es wirkte weniger wie ein ehrlicher Versuch, das Python-Ökosystem zu verbessern, und mehr wie ein Pump-and-Dump-Krypto-Projekt
- Wenn man sehr genau hingesehen hat, war von Anfang an klar, dass die Idee darin bestand, eine Systemsprache der nächsten Generation zu bauen
  Eine Sprache, die Lehren aus Swift und Rust aufnimmt, CPU/GPU/heterogene Targets anvisiert und MLIR ins Zentrum stellt
  Gleichzeitig war sie so angelegt, dass sich Python irgendwann relativ einfach einbetten oder erweitern ließe, und die Python-Positionierung hat bei der Finanzierung ziemlich sicher geholfen
  Chris Lattner hat mehr über die Beziehung zwischen MLIR und Mojo gesprochen als über die zwischen Python und Mojo
- So wurde es anfangs beworben. Es wollte eine Art Kotlin für Python sein, hat aber schnell den Kurs geändert
  Das und das Entwicklungsmodell, das nicht vollständig Open Source ist, ließen es für mich immer wie Vaporware wirken
- Auf der Website steht Folgendes
  Python-Interoperabilität: „Mojo ist nativ mit Python interoperabel, sodass Sie Performance-Bottlenecks in bestehendem Code beseitigen können, ohne alles neu schreiben zu müssen. Sie können mit einer einzelnen Funktion beginnen und nach Bedarf kritischen Code in Mojo verlagern. Mojo-Code lässt sich ganz natürlich aus Python importieren und zusammen für die Auslieferung paketieren. Ebenso können Bibliotheken aus dem Python-Ökosystem in Mojo-Code importiert werden“
Mojo sieht ordentlich aus, aber für High-Performance Numerical Computing über CPU und GPU hinweg bin ich mit Julia derzeit ziemlich zufrieden
Abgesehen von der Python-ähnlichen Syntax wirkt diese Nische bereits weitgehend gelöst. Sogar für Python selbst gibt es mit Numba und Triton Werkzeuge, die bei weniger komplexen und unabhängigeren Problemtypen effektiv sind
Für denselben Zweck ist Julia reifer, und seit letztem Jahr bringt Nvidia bei CUDA die Python- und C++-Werkzeuge funktional auf Gleichstand
Mit dem Python-cuTile-JIT-Compiler kann man CUDA-Kernel fast wie reines Python schreiben
AMD und Intel verfolgen ähnliche Ansätze
Ob Mojo noch rechtzeitig kommt, um eine breitere Akzeptanz zu finden, muss man erst sehen
- Die Aussage, dass man mit dem Python-cuTile-JIT-Compiler CUDA-Kernel in reinem Python schreiben könne, stimmt nicht. Schon jetzt ist es kein reines Python und wird es auch künftig nicht sein
  Diese „performancefreundlichen“ Python-Dialekte wie Triton, Pythran, CuTile, Numba, Pycell, cuPy usw. sehen oberflächlich wie Python aus, aber wenn man an der Oberfläche kratzt, sind sie überhaupt kein Python
  Es sind Python-artige DSLs, die so gebaut wurden, dass Optimierung und Typinferenz gut funktionieren. Wenn man sie tatsächlich benutzt, merkt man das deutlich. In jedem von ihnen kann man viele, vielleicht die meisten Python-Funktionen nicht verwenden, muss aber dennoch die eigentümlichen Probleme von Python in Kauf nehmen
  Ehrlich gesagt ist Python für Effizienz und Performance grundsätzlich ungeeignet
  Das geht weit über das GIL hinaus. Dynamische Typisierung, Referenzsemantik, Monkey Patching, ein extrem dynamisches Objektmodell, das CPython-ABI, BigInt als Standard, das Modulsystem zur Laufzeit usw. sind für eine kleine Skriptsprache nachvollziehbar, aber für High-Performance Computing und Effizienz sehr schlecht
  Auch das NumPy/SciPy-Ökosystem selbst ist fast eher ein Hack, um die Grenzen von Python für einfache CPU-gebundene Tensorarithmetik zu umgehen
  Die Basis-Performance von Python ist so schlecht, dass schon eine einfache for-Schleife Excel wie ein Rennpferd aussehen lässt
  Mojo ist anders
  Mojo versucht, statt auf einem bestehenden problematischen Fundament herumzuhacken, von einem sauberen Ausgangspunkt zu starten
  Und anstelle von über 30 Jahre altem Python soll es eine „Python-artige Erfahrung“ mit einer gut entworfenen Sprache bieten, die auf den Erfahrungen moderner Sprachentwicklung aufbaut
  Allein deshalb hoffe ich, dass es erfolgreich wird
Heutzutage scheint man zumindest für manche Leute Werbung zu brauchen, die AI native prominent herausstellt
Mich stößt das allerdings eher ab. Es wirkt wie eine Formulierung, die inhaltlich eigentlich nichts sagt
Könnte mir jemand, der von AI begeistert ist, erklären, warum „ideal auch für agentisches Programmieren, weil es eine kompilierte und statisch typisierte Sprache ist“ stimmen soll und was das überhaupt bedeuten soll?
- Seit AI so stark betont wird, fand ich es wirklich interessant, wie verzweifelt die Startseiten solcher Produkte und Dienste oft wirken
  Am lustigsten fand ich persönlich, als ich die Produktseite von IBM DB2 öffnete und dort AI database stand
  Gemeint ist vermutlich, dass man zur Compile-Zeit mehr Fehler abfangen kann, sodass ein Agent seine Arbeit auch ohne Unit-Tests oder andere Tests schneller statisch überprüfen kann
- Aktuelle LLMs wurden auf riesigen Bibliotheken früheren Codes trainiert. Deshalb werden sie in absehbarer Zeit in etablierten Sprachen besser funktionieren als in neuen
  Besonders im Vorteil sind Sprachen wie Python, für die viel nutzbarer Open-Source-Code existiert. Für neue Teilnehmer ohne vorhandene Codebasis zum Trainieren ist das ein großes Problem
  Deshalb könnte man in einer „agentischen“ Welt zu solcher verzweifelten AI-native-Vermarktung greifen müssen, um relevant zu wirken. Ob das reicht, wird die Zeit zeigen
- Ich würde mich nicht als AI-Enthusiasten bezeichnen, nutze es aber tatsächlich
  Agenten arbeiten tendenziell besser, je mehr Feedback sie bekommen. Typprüfung ist gut darin, eine Menge dummer Fehler automatisch abzufangen
  Der Punkt ist: Je mehr Hinweise ein Agent bekommt, desto besser ist es in der Regel
- Ich weiß nicht, in welchem Sinn dieser Ausdruck gemeint war, aber ich stimme zu, dass „AI native“ bei einer Programmiersprache dieser Art eher bedeutungslos ist
  Was Kompilierung und statische Typisierung angeht: Beim agentischen Programmieren ist es sehr hilfreich, Probleme schon zur Compile-Zeit erkennen zu können
  Dann gibt es weniger Probleme, die erst zur Laufzeit auftauchen, und weniger Situationen, mit denen Agenten nur schwer umgehen können. Unit-Tests können diese Lücke teilweise schließen, aber nicht vollständig
  Was auf der Website nicht steht, ist, dass Mojo für agentisches Programmieren sogar eher eine schlechte Wahl sein könnte. Es gibt nämlich noch nicht viele Mojo-Trainingsdaten
- Das ist das neue „...on the blockchain“
  Python+ruff+pycheck und TypeScript werden nicht zu Maschinencode, sondern zu Bytecode kompiliert. Auch statisch typisiert im Sinn von Rust sind sie nicht
  Trotzdem habe ich gesehen, dass Modelle in beiden Fällen recht guten, validen Code erzeugen. Es musste nicht strikt „kompiliert“ oder „statisch typisiert“ sein
  Am Ende kümmert sich AI eher darum, ob es gute Werkzeuge gibt, mit denen Code schnell überprüft und iteriert werden kann, als um solche Eigenschaften
Modular will noch in diesem Jahr das vollständige Mojo SDK inklusive Compiler als Open Source veröffentlichen
Es heißt: „Mojo 1.0 wird Ende dieses Jahres finalisiert, zusammen mit der Veröffentlichung des Compilers und der Zusicherung von Sprachstabilität“
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
Ich beobachte Mojo weiterhin. Ehrlich gesagt ist das, was ich an Python am wenigsten mag, die Syntax
Jemand hier hat Julia erwähnt, und ich halte es für eine gute Sprache. Aber die Fehlermeldungen des Compilers und die Bibliotheksdokumentation sind nicht auf dem Niveau, das ich von einer so reifen Sprache erwarten würde
Auch Genauigkeitsprobleme in Blogposts, die ich früher gelesen habe, machen mir Sorgen. Außerdem glaube ich wegen der Binärgröße und der Startzeit nicht, dass ich den Typ Python-Modul, den ich mir wünsche, in Julia bauen könnte
Trotzdem hoffe ich, dass Mojo zu einer Option wird. Andererseits mag ich REPLs und auch die dynamische Natur von Python, sodass ich am Ende vielleicht doch nicht wegen der Performance aus NumPy ausbreche
- Bei mir ist es genau umgekehrt. Das Einzige, was ich an Python mag, ist die Syntax
  Deshalb mag ich Nim wirklich sehr. Man bekommt Geschwindigkeiten auf C-Niveau, Compile-Time-Ausführung, Metaprogramming, ein starkes Typsystem und Memory Safety, und der Code ist oft auch noch kurz und elegant
  Mojo ist ebenfalls interessant, aber bisher scheint es sich eher auf Machine Learning als auf allgemeine Programmierung zu konzentrieren. Und soweit ich weiß, ist der Compiler noch nicht Open Source
- Ich mag das Design von Mojo sehr. Mit deterministischem Speichermanagement ist es nicht wirklich mit Julia vergleichbar
  Es wirkt auch so, als sei Mojo stärker darauf ausgerichtet, eine robuste Sprache für den industriellen Einsatz zu werden. Ich war schockiert, als ich sah, dass Julias erste Implementierung der Vorkompilierung keinen Datei-I/O bot

Mojo 1.0 Beta

Versionen und Einstiegsmaterialien

GPU und Python-Interoperabilität

GPU-Programmierung

Python-Interoperabilität

Compile-Time-Metaprogrammierung

Roadmap und Open Source

Phase 0

Phase 1

Phase 2

Phase 3

Lern- und Community-Materialien

Verwandte Beiträge

1 Kommentare

Hacker-News-Kommentare