Mojo 1.0 Beta

(mojolang.org)

3 poin oleh GN⁺ 7 jam lalu | 1 komentar | Bagikan ke WhatsApp

Mojo mengusung bahasa dengan slogan “ditulis seperti Python, berjalan seperti C++”, dan saat ini menyediakan versi stabil 1.0.0b1 (7 Mei)
Bahasa ini ditujukan untuk menulis kode cepat di berbagai perangkat keras, dari CPU hingga GPU, tanpa terikat pada vendor tertentu, dan dirancang sebagai bahasa bertipe statis berperforma tinggi untuk sistem AI modern
Mendukung interoperabilitas Python secara native, sehingga bottleneck performa bisa dipindahkan ke Mojo tanpa harus menulis ulang seluruh kode yang ada; juga mendukung Python import untuk kode Mojo maupun import pustaka Python
Dapat menulis kernel GPU dalam bahasa yang sama, dan melalui metaprogramming saat kompilasi yang memakai bahasa yang sama dengan kode runtime, Mojo ingin menyediakan optimasi per perangkat keras serta abstraksi tanpa biaya
Pustaka standar Mojo telah sepenuhnya open source di GitHub dan menerima kontribusi, sementara kompilator Mojo direncanakan menjadi open source pada 2026

Versi dan materi awal

Versi stabil saat ini adalah 1.0.0b1 (7 Mei), dan nightly terbaru adalah 9 Mei
Mojo terinspirasi oleh sintaks Python yang intuitif, keamanan memori Rust, dan metaprogramming compile-time Zig yang kuat sekaligus intuitif
Sebagai bahasa bertipe statis yang dikompilasi, Mojo juga cocok untuk pemrograman berbasis agen
Alih-alih memaksa memilih antara produktivitas atau performa, Mojo menargetkan keduanya sekaligus, dimulai dari pola pemrograman yang sederhana dan familier lalu menambahkan kompleksitas saat diperlukan
Jalur awal yang tersedia meliputi Install Now, Quickstart, Releases, Roadmap, dan GitHub
Untuk melihat halaman dalam Markdown, Anda bisa menambahkan .md pada URL, dan indeks seluruh dokumentasi Mojo dapat dilihat di llms.txt

GPU dan interoperabilitas Python

Pemrograman GPU

Mojo bertujuan membuat pemrograman GPU dapat diakses tanpa pustaka khusus vendor atau kode kompilasi terpisah
Kernel GPU berperforma tinggi dapat ditulis dengan bahasa yang sama seperti yang dipakai untuk CPU

Contoh kernel vector_add menerima TileTensor dan menjalankan result[i] = a[i] + b[i] berdasarkan global_idx.x

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 < layout.size():  
        result[i] = a[i] + b[i]

Interoperabilitas Python
- Mojo berinteroperasi secara native dengan Python, sehingga bottleneck performa dapat dihilangkan tanpa menulis ulang seluruh kode yang ada
- Bisa dimulai dari satu fungsi, lalu diperluas dengan memindahkan kode yang kritis terhadap performa ke Mojo sesuai kebutuhan
- Kode Mojo dapat di-import secara alami di Python dan dibundel bersama sebagai paket untuk distribusi
- Sebaliknya, dari dalam kode Mojo juga bisa meng-import pustaka dari ekosistem Python
- Contoh fungsi mojo_square_array memperoleh pointer dari ctypes.data milik PythonObject, lalu menghitung lebar SIMD saat kompilasi untuk mengkuadratkan elemen array
```
# 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)  
```

Metaprogramming saat kompilasi

Metaprogramming Mojo menyediakan sistem intuitif untuk memaksimalkan performa dengan memakai bahasa yang sama seperti kode runtime
Melalui kompilasi bersyarat, Mojo dapat membuat optimasi spesifik perangkat keras; melalui evaluasi saat kompilasi, Mojo dapat menjamin keamanan memori dan menghilangkan percabangan runtime yang mahal
Tujuannya adalah menyediakan abstraksi tanpa biaya sambil tetap mengekspresikan niat dengan jelas

Implementasi contoh __eq__ menggunakan refleksi saat kompilasi untuk memperoleh nama dan tipe field struct, memeriksa apakah semua field memenuhi Equatable, lalu melakukan equality per field

# Generic struct equality using compile-time reflection.  
@always_inline  
def __eq__(self, other: Self) -> 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), "All fields must be Equatable"  
        if trait_downcast[Equatable](  
            r.field_ref[i](self)  
        ) != trait_downcast[Equatable](r.field_ref[i](other)):  
            return False  
    return True

Roadmap dan open source

Mojo dimulai pada akhir 2022, dan masih banyak pekerjaan yang harus dilakukan
Phase 0
- Tahap pembangunan fondasi awal
- Ini adalah tahap implementasi parser inti, tipe memori, fungsi, struct, initializer, konvensi argumen, dan fondasi bahasa lainnya
Phase 1
- Tahap yang sedang berjalan saat ini
- Tujuannya adalah menjadikannya bahasa yang kuat dan ekspresif untuk menulis kernel berperforma tinggi di CPU, GPU, dan ASIC, serta memungkinkan developer memperluas Python dengan mulus
Phase 2
- Tahap pemrograman aplikasi sistem
- Ini adalah tahap perluasan dukungan untuk model keamanan memori yang terjamin dan lebih banyak fitur abstraksi yang diharapkan oleh developer pemrograman sistem
Phase 3
- Tahap pemrograman berorientasi objek dinamis
- Ini adalah tahap penambahan lebih banyak fitur dinamis Python seperti class, inheritance, dan variabel tanpa tipe untuk memaksimalkan kompatibilitas dengan kode Python
- Detail lebih lanjut dapat dilihat di Mojo roadmap
- Pustaka standar Mojo telah sepenuhnya open source di GitHub dan menerima kontribusi
- Kompilator Mojo direncanakan menjadi open source pada 2026
- Ada kebijakan untuk meng-open-source-kan seluruh Mojo, tetapi karena bahasanya masih sangat muda, mereka menilai bahwa kelompok engineer yang erat dengan visi bersama dapat bergerak lebih cepat dibanding pendekatan yang dipimpin komunitas
- Jalur partisipasi tersedia melalui developer community

Materi belajar dan komunitas

Install dan Quickstart guide: materi awal untuk memulai Mojo
Beginner tutorial: belajar Mojo sambil membuat Game of Life
GPU puzzles: belajar pemrograman GPU dengan Mojo lewat pemecahan puzzle
Intro to Mojo: pengenalan umum fitur-fitur bahasa Mojo
Developer forum: pertanyaan dan pembaruan terkait Mojo
Events: informasi acara, meetup, presentasi, dan hackathon
Contributions: panduan issue terbuka, kontribusi dokumentasi, dan berbagi proyek

1 komentar

GN⁺ 7 jam lalu

Komentar Hacker News

Selama 2 tahun terakhir saya cukup sering memakai Mojo untuk senang-senang, dan ini benar-benar bahasa yang keren
Ada model ownership yang mirip Rust, eksekusi saat compile time yang lebih kuat daripada Zig, sistem tipe yang kaya, dan dukungan SIMD kelas satu
Dari sisi performa juga, ini terlihat seperti bahasa sungguhan yang bukan sekadar pembungkus LLVM sederhana. LLVM tetap dipakai, tetapi dimanfaatkan dengan cara yang berbeda dari Rust atau Zig
Saya sangat menantikan Mojo saat nanti menjadi open source di akhir tahun ini
- Akan bagus kalau bagian “eksekusi saat compile time yang lebih kuat daripada Zig” bisa dijelaskan lebih lanjut
  Dari dokumentasi Mojo saat ini, sulit untuk sampai pada kesimpulan itu
Sebagai orang yang mengerjakan machine learning dan peduli pada performa, saya berharap Mojo berhasil. Terutama menarik karena kode GPU dan kode CPU bisa dicampur dalam bahasa yang sama
Hanya saja, saya khawatir perubahan sekarang akan membuat developer Python menjauh. Terakhir kali saya menjalankannya, saya mencoba menguji manipulasi string dasar dengan var x = 'hello'; print(x[3]), tetapi itu tidak jalan, dan len(x) juga tidak bisa, jadi saya buang waktu satu jam
Ternyata mereka memutuskan untuk memisahkan representasi byte dan code point dengan lebih spesifik, tetapi dokumentasinya bertentangan dengan implementasi nyata
Saya berharap ini bisa mencapai kondisi yang layak dipakai untuk machine learning umum juga, tetapi saat ini rasanya masih cukup terbatas. Beberapa fitur dasar terkait tensor yang lumayan juga sudah dibuang
Untuk sementara saya akan tetap memakai JAX dan sesekali mengeceknya
- Saya tidak tahu kenapa sampai sekarang belum ada bahasa yang bisa mengubah kode yang sederhana dan berfokus pada komputasi menjadi kode SIMD / multithread / multiprocessing / GPU hanya dengan tambahan sintaks seminimal mungkin
  Rasanya ini seperti hal yang layak diimpikan orang-orang yang tertarik pada compiler dan desain bahasa
  Tidak harus menjamin efisiensi di semua situasi atau menghasilkan performa terdepan; cukup ada saja pun sudah bagus
  Saya paham bahasa seperti ini mungkin bisa dibuat, tetapi tampaknya belum cukup menarik minat orang yang mampu membuatnya
- Mojo memang keren, tetapi saya tidak paham kenapa mereka begitu mempertahankan kompatibilitas ke bawah dengan Python. Itu justru jadi beban buat mereka sendiri
  Hampir semua kekurangan yang saya ingat dari Kotlin berasal dari kompatibilitas Java. Mungkin di sini itu bisa diselesaikan dengan cara yang lebih eksplisit, tetapi pendekatan sekarang terlihat seperti akan gagal
- Kalau bukan open source, hampir tidak ada artinya. Kebanyakan developer Python juga tidak akan datang
- Dari sisi ini, kelihatannya hampir seperti mencoba membuat ulang bahasa pemrograman Nim
Tertulis bahwa mereka “berjanji akan merilis Mojo sebagai open source pada musim gugur 2026”
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
- Akan menarik kalau kita bisa melihat source code program MLIR yang benar-benar mutakhir
Sayangnya, sementara itu Nvidia juga tidak tinggal diam, dan melalui stack compiler serupa berbasis MLIR mereka membuat CUDA generasi berikutnya bernama CuTile untuk Python, dan segera untuk C++
Meski tidak portabel, ada kemungkinan ini akan dipakai jauh lebih luas daripada Mojo hanya karena Nvidia mendorongnya dengan kuat, mengintegrasikannya ke tool pengembangan, dan membuatnya bekerja berdampingan dengan kode CUDA yang sudah ada
Mungkin saja Tile IR lebih merupakan respons terhadap ancaman dari Triton ketimbang Mojo. Terutama jika dilihat dari seberapa mudah menulis kernel LLM dengan performa yang lumayan
- Agar tidak tertinggal, Intel dan AMD juga sedang melakukan upaya serupa, dan JIT CPython akhirnya mulai menjadi kenyataan setelah beberapa kali percobaan
  Ada juga upaya seperti GraalPy dan PyPy
  Semua upaya ini saat ini berjalan di Windows. Ini cukup penting di lingkungan tempat sebagian besar karyawan mendapat perangkat Windows sementara hanya server yang memakai distribusi Linux
  Hal ini terus membuat saya bertanya-tanya apakah akhirnya akan berujung seperti Swift for Tensorflow lagi
- Dari pembicaraan saya dengan beberapa developer Tile IR, motivasi utamanya adalah memberi portabilitas yang lebih baik untuk pemrograman tensor core dibanding PTX
  Selain feedback pelanggan, tidak ada yang menyebut ini sebagai respons terhadap sesuatu yang lain
- Banyak orang salah paham mengira Mojo sekadar sintaks yang nyaman untuk menulis kode GPU, lalu menganggap framework Python dari Nvidia sudah mengisi peran itu
  Tapi apakah CuTile akan berjalan juga di GPU AMD atau Apple Silicon? Apa pun yang dilakukan Nvidia, ketergantungan pada vendor tetap ada
- Saya penasaran seberapa besar pengaruh CuTile nantinya
Saat pertama kali mendengar Mojo, saya mengira tujuannya adalah dibuat kompatibel dengan kode Python yang sudah ada
Tetapi dalam waktu dekat, tampaknya sangat jauh dari tujuan itu. Anda memang bisa bolak-balik memanggil antara Python dan Mojo, tetapi Mojo sendiri tidak bisa menjalankan kode Python yang sudah ada
- Dalam promosi awal, itu jelas salah satu poin utamanya. Nadanya seperti menambahkan type hint ke kode Python lalu mendapat peningkatan kecepatan besar
  Tetapi saat benar-benar mulai dibangun, arahnya tampak berubah
- Kalau ingatan saya benar, mereka juga pernah mengiklankan peningkatan kecepatan 36.000x dibanding Python setara, tetapi sama sekali tidak menjelaskan bahwa itu hanya mungkin pada edge case yang ekstrem
  Rasanya lebih seperti skema pump-and-dump kripto daripada upaya jujur untuk memperbaiki ekosistem Python
- Kalau diperhatikan dengan sangat saksama, sejak awal sebenarnya sudah jelas bahwa idenya adalah membuat bahasa sistem generasi berikutnya
  Bahasa yang mengambil pelajaran dari Swift dan Rust, menargetkan CPU/GPU/target heterogen, dan berpusat pada MLIR
  Pada saat yang sama, strukturnya juga dirancang dengan gagasan agar suatu hari Python bisa di-embed atau diperluas dengan relatif mudah, dan framing Python hampir pasti membantu penggalangan dana
  Chris Lattner lebih sering membicarakan hubungan MLIR dan Mojo daripada hubungan Python dan Mojo
- Memang begitu iklan awalnya. Mereka ingin menjadi semacam Kotlin untuk Python, tetapi cepat berbelok arah
  Itu, ditambah model pengembangan yang tidak sepenuhnya open source, selalu membuatnya terasa seperti vaporware
- Di situsnya tertulis begini
  Interoperabilitas Python: “Mojo berinteroperasi secara native dengan Python, sehingga Anda dapat menghilangkan bottleneck performa pada kode yang ada tanpa menulis ulang semuanya. Anda bisa mulai dari satu fungsi dan memperluasnya sesuai kebutuhan dengan memindahkan kode yang sensitif terhadap performa ke Mojo. Kode Mojo dapat diimpor secara alami ke Python dan dikemas bersama untuk distribusi. Demikian pula, library dalam ekosistem Python dapat diimpor ke dalam kode Mojo”
Mojo terlihat cukup bagus, tetapi untuk komputasi numerik berperforma tinggi lintas CPU dan GPU, saat ini saya sudah cukup puas dengan Julia
Selain sintaks mirip Python, rasanya ceruk ini sebenarnya sudah banyak terpecahkan. Bahkan Python sendiri punya alat seperti Numba dan Triton yang efektif untuk jenis masalah yang kurang rumit dan lebih terisolasi
Untuk tujuan yang sama, Julia lebih matang, dan sejak tahun lalu Nvidia sedang menyamakan kesetaraan fitur antara tool Python dan tool C++ di CUDA
Dengan Python cuTile JIT compiler, Anda bisa menulis kernel CUDA hampir seperti Python murni
AMD dan Intel juga mengikuti pendekatan serupa
Masih harus dilihat apakah Mojo akan datang cukup tepat waktu untuk mendapatkan adopsi yang lebih luas
- Tidak tepat mengatakan bahwa Python cuTile JIT compiler memungkinkan penulisan kernel CUDA dalam Python murni. Saat ini pun bukan Python murni, dan ke depannya juga tidak akan bisa
  Dialek Python yang “ramah performa” seperti Triton, Pythran, CuTile, Numba, Pycell, cuPy, dan lain-lain, memang tampak seperti Python di permukaan, tetapi sedikit saja digali jelas itu bukan Python
  Itu adalah DSL bergaya Python yang dirancang agar optimisasi dan inferensi tipe bekerja dengan baik. Saat benar-benar dipakai, terasa seperti itu. Dalam masing-masing, banyak—mungkin sebagian besar—fitur Python tidak bisa dipakai, tetapi masalah khas Python tetap harus ditanggung
  Sejujurnya, Python memang secara inheren tidak cocok untuk efisiensi dan performa
  Ini masalah yang jauh melampaui GIL. Dynamic typing, reference semantics, monkey patching, model objek yang sangat dinamis, ABI CPython, BigInt bawaan, sistem modul runtime, semuanya masuk akal untuk bahasa scripting kecil, tetapi sangat buruk untuk high-performance computing dan efisiensi
  Ekosistem NumPy/SciPy sendiri hampir seperti serangkaian hack untuk menghindari keterbatasan Python demi aritmetika tensor sederhana yang CPU-bound
  Performa dasar Python begitu buruk sampai for loop sederhana saja bisa membuat Excel terlihat seperti kuda pacu
  Mojo berbeda
  Alih-alih meretas fondasi lama yang bermasalah, Mojo mencoba memulai dari titik awal yang bersih
  Dan bukan Python berusia lebih dari 30 tahun, melainkan pengalaman “mirip Python” yang dibangun di atas bahasa yang dirancang dengan baik berdasarkan pengalaman desain bahasa yang lebih baru
  Hanya karena alasan itu pun saya berharap ia berhasil
Belakangan ini sepertinya setidaknya bagi sebagian orang, iklan yang menonjolkan AI native di depan memang diperlukan
Tetapi bagi saya itu agak bikin ilfeel. Soalnya terlihat seperti ungkapan yang sebenarnya tidak mengatakan apa-apa
Bisakah para penggemar AI menjelaskan kenapa kalimat “karena ini bahasa yang dikompilasi dan bertipe statis, maka ini juga ideal untuk pemrograman agentic” masuk akal, dan sebenarnya maksudnya apa
- Sejak AI mulai ditonjolkan, sangat menarik melihat kesan putus asa di halaman depan berbagai produk dan layanan semacam ini
  Secara pribadi yang paling lucu buat saya adalah saat membuka halaman produk IBM DB2 dan melihat label AI database
  Sepertinya maksudnya, kalau lebih banyak error bisa ditangkap saat compile time, agen bisa memverifikasi pekerjaannya sendiri secara statis dengan cepat tanpa unit test atau pengujian lain
- LLM saat ini dilatih dengan perpustakaan kode masa lalu yang sangat besar. Karena itu, dalam waktu dekat mereka akan bekerja lebih baik pada bahasa yang sudah mapan daripada bahasa baru
  Terutama bahasa seperti Python yang punya banyak kode open source yang bisa dipakai. Ini masalah besar bagi pendatang baru yang belum punya basis kode lama untuk dipelajari
  Jadi untuk terlihat relevan di dunia “agentic”, mungkin memang perlu pemasaran AI native yang terkesan putus asa seperti ini. Cukup atau tidak, waktu yang akan menjawab
- Saya tidak merasa diri pengguna AI yang fanatik, tetapi saya memang memakainya
  Agen cenderung bekerja lebih baik jika mendapat banyak feedback. Pemeriksaan tipe bagus untuk otomatis menangkap banyak kesalahan bodoh
  Intinya, bagi agen, semakin banyak petunjuk biasanya semakin baik
- Saya tidak tahu persis maksud istilah itu saat ditulis, dan saya setuju bahwa ungkapan “AI native” pada bahasa pemrograman seperti ini agak tidak bermakna
  Soal kompilasi dan static typing, saat melakukan pemrograman agentic sangat membantu jika masalah bisa ditangkap saat compile time
  Dengan begitu, jumlah masalah yang muncul saat runtime berkurang, dan berkurang juga situasi yang sulit diselesaikan agen. Unit test memang bisa menutup sebagian celah, tetapi tidak sepenuhnya
  Yang tidak tertulis di situsnya adalah bahwa Mojo justru kemungkinan merupakan pilihan buruk untuk pemrograman agentic. Alasannya, data pelatihan Mojo masih belum banyak
- Ini adalah versi baru dari “...on the blockchain”
  Python+ruff+pycheck dan TypeScript dikompilasi ke bytecode, bukan kode mesin. Juga bukan static type dalam arti ala Rust
  Tetapi saya sudah melihat model menghasilkan kode valid yang cukup bagus untuk keduanya
  Jadi tidak harus “terkompilasi” secara ketat atau “bertipe statis”
  Pada akhirnya AI tidak terlalu peduli pada sifat-sifat itu, selama ada tool yang bagus untuk memeriksa kode dengan cepat dan melakukan iterasi
Modular berencana merilis seluruh Mojo SDK sebagai open source, termasuk compiler, pada akhir tahun ini
Tertulis, “Mojo 1.0 akan difinalisasi pada akhir tahun ini, bersamaan dengan pembukaan compiler dan penyediaan stabilitas bahasa”
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
Saya terus mengikuti Mojo. Sejujurnya, hal yang paling tidak saya sukai dari Python adalah sintaksnya
Ada orang lain di sini yang menyebut Julia, dan menurut saya itu bahasa yang bagus. Tetapi pesan error compiler dan dokumentasi library-nya belum di tingkat yang saya harapkan dari bahasa sematang itu
Saya juga khawatir soal masalah akurasi dari blog yang dulu pernah saya baca. Selain itu, karena ukuran binary dan waktu startup awal, saya rasa saya tidak akan bisa membuat modul Python dalam bentuk yang saya inginkan dengan Julia
Meski begitu, saya tetap berharap Mojo bisa menjadi opsi. Hanya saja saya suka REPL dan juga sifat dinamis Python, jadi demi performa pun mungkin saya tetap tidak akan keluar dari NumPy
- Bagi saya justru sebaliknya. Satu-satunya hal yang saya suka dari Python adalah sintaksnya
  Itulah kenapa saya sangat menyukai Nim. Anda mendapat kecepatan setara C, eksekusi saat compile time, metaprogramming, sistem tipe yang kuat, dan keamanan memori, sementara kodenya juga sering singkat dan elegan
  Mojo juga menarik, tetapi sejauh ini tampaknya lebih banyak berfokus pada machine learning daripada pemrograman umum. Dan setahu saya compiler-nya masih belum open source
- Saya sangat menyukai desain Mojo. Karena ada manajemen memori deterministik, ini tidak bisa dibandingkan dengan Julia
  Mojo juga tampaknya lebih berfokus menjadi bahasa yang cukup tangguh untuk industri. Saya sempat kaget melihat implementasi precompile pertama Julia bahkan tidak menyediakan file I/O

Mojo 1.0 Beta

Versi dan materi awal

GPU dan interoperabilitas Python

Pemrograman GPU

Interoperabilitas Python

Metaprogramming saat kompilasi

Roadmap dan open source

Phase 0

Phase 1

Phase 2

Phase 3

Materi belajar dan komunitas

Bacaan terkait

1 komentar

Komentar Hacker News