Otwarcie kompilatora Mojo to krok, na który wielu deweloperów czekało. 18 sierpnia 2026 roku Modular ogłosił, że język, kompilator i narzędzia Mojo są open source na Apache 2.0 z wyjątkami LLVM. Kod trafił do modular/modular przez PR #6904, obejmujący ponad 561 tysięcy dodanych linii i 2 853 zmienione pliki. Stało się to tydzień po Mojo 1.0, opisywanym jako stabilna podstawa.

Abstrakcyjny otwarty kompilator z otwartą kłódką i generycznymi chipami

Dla Open Source Radar to nie jest zwykła wiadomość o języku. Mojo jest ciekawe, bo obiecuje składnię bliską Pythonowi z wydajnością systemową, SIMD, GPU i akceleratorami AI. Łatwo było je jednak odrzucić, bo kompilator był zamknięty. Dla maintainerów open source, zespołów badawczych i firm robiących security review był to poważny bloker. Teraz jest słabszy. Zaczyna się trudniejszy test: czy Mojo potrafi być poważnym projektem otwartym.

Co jest otwarte

Modular twierdzi, że Mojo jest otwarte na Apache 2.0 with LLVM exceptions. Repozytorium zawiera kompilator, tooling i kod potrzebny do budowy języka. README wskazuje kompilator w /KGEN, bibliotekę standardową w /mojo/stdlib, MAX accelerator library w /max/kernels, pipelines, przykłady i dokumentację. Pokazuje też build przez Bazel wrapper: ./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo.

To duża zmiana względem wcześniejszych etapów. Części były już otwarte, ale serce języka pozostawało własnościowe. Teraz widać kod, historię i issues. GitHub pokazuje około 27 tysięcy gwiazdek, prawie 3 tysiące forków i ponad tysiąc otwartych issues.

Licencja też ma znaczenie. Apache 2.0 z wyjątkami LLVM jest znany w świecie kompilatorów. Nie rozwiązuje wszystkiego, ale ułatwia ocenę prawną i techniczną.

Czego nie mylić

Granica przy MAX jest ważna. Modular pisze o usunięciu device usage restrictions, source-available częściach, open alliance i nowych akceleratorach. MAX nie jest jednak tym samym co otwarty kompilator Mojo. Cała Modular Platform nie jest open source w tym samym sensie.

Zespoły powinny oddzielić eksperyment językowy od zależności platformowej. Mojo, MAX inference server, kernels i model pipelines mogą mieć inne licencje, dystrybucję i zasady wkładu.

Druga sprawa to contributions. README przyjmuje wkład do biblioteki standardowej, MAX accelerator library, architektur modeli, przykładów i docs, ale jeszcze nie do kompilatora Mojo. Widoczny kod i możliwość forka to nie pełna governance.

Dlaczego to było ważne

Kompilator nie jest zwykłą zależnością. Definiuje semantykę, tworzy artefakty i należy do podstawy zaufania. Gdy jest zamknięty, użytkownik musi wierzyć dostawcy w sprawie wsparcia, platform, bezpieczeństwa i licencji. Dla młodego języka rywalizującego z Rust, Zig, Julia, C++, CUDA, Triton, Numba i Cython to duże wymaganie.

Mojo celuje właśnie w ludzi, którzy patrzą na toolchain: infrastrukturę ML, wydajnościowych programistów Python, autorów kerneli i zespoły blisko sprzętu. Otwarcie kompilatora odpowiada na ich główny zarzut.

Spór społeczności

Hacker News i Lobsters pokazują zainteresowanie, ale też praktyczny sceptycyzm. Jedni mówią, że znika kryterium eliminujące. Inni pytają, czy Mojo nie spóźniło się, czy Bazel nie utrudnia buildów, co oznacza Qualcomm, dlaczego nie ma jeszcze patchy do kompilatora i jak dojrzałe jest 1.0.

To właściwe pytania. Czy można zbudować ze źródeł? Czy da się spakietować toolchain? Czy można używać Mojo bez MAX? Czy Windows będzie realny? Co jeśli strategia komercyjna się zmieni? Otwarty język musi wytrzymać taką kontrolę.

Gdzie Mojo może pasować

Mojo nie powinno być opisane tylko jako “szybszy Python”. Mocniejszy pomysł to ergonomia Pythona plus kontrola: ownership, lifetimes, programowanie w czasie kompilacji, typy jawne, SIMD, GPU i akceleratory AI. Jeśli to działa, nisza istnieje.

Pierwsza grupa to autorzy kerneli numerycznych, przetwarzania danych, infrastruktury inference i krytycznych części bibliotek, którzy dziś wybierają C++, Rust, Cython, Numba, JAX, Triton albo CUDA. Mojo chce zmniejszyć koszt zmiany języka bez obiecywania magii.

Jak testować

Pierwszy test powinien być nudny: instalacja, prosty przykład, build ze źródeł, zapis systemu, sprzętu, czasu builda, cache i błędów. Drugi test porównuje z realną alternatywą w zespole. Liczą się packaging, edytor, testy, deployment i onboarding, nie tylko benchmark. Trzeci test to licencje i organizacja: oddziel Mojo od MAX, przeczytaj contribution guide i potraktuj brak patchy do kompilatora jako aktualne ograniczenie governance.

Werdykt

Mojo znów zasługuje na uwagę, bo najważniejszy ukryty element stał się widoczny. O adopcji zdecydują jednak zewnętrzne buildy, dokumentacja, triage issues, jasne granice wkładu, Windows, pakiety i uczciwe oddzielenie Mojo od MAX. Otwarty kompilator to początek testu, nie jego koniec.