Mojo 1.0 Beta

(mojolang.org)

3 puan yazan GN⁺ 7 시간 전 | 1 yorum | WhatsApp'ta paylaş

Mojo, “Python gibi yaz, C++ gibi çalıştır” sloganıyla öne çıkan bir dil ve şu anda kararlı sürüm olarak 1.0.0b1 (7 Mayıs) sunuluyor
CPU’dan GPU’ya kadar farklı donanımlarda hızlı kod yazmayı hedeflerken belirli bir üreticiye bağımlı olmamayı amaçlıyor; modern yapay zeka sistemleri için yüksek performanslı, statik tipli bir dil olarak tasarlandı
Python birlikte çalışabilirliğini yerel olarak desteklediği için mevcut kodun tamamını yeniden yazmadan yalnızca performans darboğazlarını Mojo’ya taşımayı mümkün kılıyor; hem Mojo kodunun Python tarafından import edilmesini hem de Python kütüphanelerinin import edilmesini destekliyor
Aynı dilde GPU kernel yazılabiliyor ve çalışma zamanı koduyla aynı dili kullanan derleme zamanı metaprogramlama ile donanıma özel optimizasyonlar ve sıfır maliyetli soyutlamalar sunmayı hedefliyor
Mojo standart kütüphanesi GitHub’da tamamen açık kaynak olarak yayımlandı ve katkılara açık; Mojo derleyicisinin ise 2026’da açık kaynak yapılması planlanıyor

Sürümler ve başlangıç kaynakları

Güncel kararlı sürüm 1.0.0b1 (7 Mayıs), en yeni nightly ise 9 Mayıs
Mojo; Python’un sezgisel sözdiziminden, Rust’ın bellek güvenliğinden ve Zig’in güçlü ama sezgisel derleme zamanı metaprogramlamasından ilham alıyor
Derlenen, statik tipli bir dil olarak ajan tabanlı programlamaya da uygun
Verimlilik ve performanstan birini seçtirmek yerine ikisini birden sunmayı hedefliyor; basit ve tanıdık programlama kalıplarıyla başlayıp gerektiğinde karmaşıklık eklemeye izin veriyor
Başlangıç için Install Now, Quickstart, Releases, Roadmap, GitHub bağlantıları sunuluyor
Sayfayı Markdown olarak görmek için URL’ye .md eklenebilir; tüm Mojo dokümantasyon dizini llms.txt içinde görülebilir

GPU ve Python birlikte çalışabilirliği

GPU programlama

Mojo, üreticiye özel kütüphaneler veya ayrı derleme kodları olmadan GPU programlamaya erişimi mümkün kılmayı hedefliyor
CPU için kullanılan aynı dille yüksek performanslı GPU kernel’leri yazılabiliyor

Örnek vector_add kernel’i TileTensor alır ve global_idx.x temelinde result[i] = a[i] + b[i] işlemini yapar

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 birlikte çalışabilirliği
- Mojo, Python ile yerel olarak birlikte çalışır ve mevcut kodun tamamını yeniden yazmadan performans darboğazlarını gidermeyi sağlar
- Tek bir fonksiyonla başlayıp gerektiğine göre performans açısından kritik kodu Mojo’ya taşıyarak ilerlemek mümkündür
- Mojo kodu Python içinde doğal biçimde import edilebilir ve dağıtım paketleriyle birlikte paketlenebilir
- Tersine, Mojo kodu içinden Python ekosistemindeki kütüphaneler de import edilebilir
- Örnek mojo_square_array fonksiyonu, PythonObject içindeki ctypes.data üzerinden işaretçi alır; SIMD genişliğini derleme zamanında hesaplayıp dizi öğelerini karesine çevirir
```
# 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)  
```

Derleme zamanı metaprogramlama

Mojo’nun metaprogramlaması, performansı en üst düzeye çıkarmak için çalışma zamanı koduyla aynı dili kullanan sezgisel bir sistem sunuyor
Koşullu derleme ile donanıma özel optimizasyonlar oluşturabiliyor, derleme zamanı değerlendirmesiyle bellek güvenliğini garanti altına alabiliyor ve maliyetli çalışma zamanı dallanmalarını ortadan kaldırabiliyor
Amacı, niyeti açıkça ifade ederken sıfır maliyetli soyutlamalar sağlamak

Örnek __eq__ uygulaması, derleme zamanı reflection ile struct alan adlarını ve türlerini alır; tüm alanların Equatable koşulunu sağlayıp sağlamadığını denetledikten sonra alan bazında eşitlik karşılaştırması yapar

# 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

Yol haritası ve açık kaynak

Mojo, 2022’nin sonunda başladı ve önünde hâlâ yapılacak çok iş var
Phase 0
- İlk temel altyapının kurulduğu aşama
- Çekirdek parser, bellek tipleri, fonksiyonlar, struct’lar, initializer’lar, çağrı sözleşmeleri ve diğer dil temellerinin uygulandığı aşama
Phase 1
- Hâlen devam eden aşama
- CPU, GPU ve ASIC üzerinde yüksek performanslı kernel’ler yazmak için güçlü ve ifade gücü yüksek bir dil olmak ve geliştiricilerin Python’u sorunsuz biçimde genişletmesini sağlamak hedefleniyor
Phase 2
- Sistem uygulama programlama aşaması
- Garantili bellek güvenliği modeli ile sistem programlama geliştiricilerinin beklediği daha fazla soyutlama özelliğini destekleyecek şekilde genişleme aşaması
Phase 3
- Dinamik nesne yönelimli programlama aşaması
- Python koduyla uyumluluğu en üst düzeye çıkarmak için class, inheritance ve türsüz değişkenler gibi Python’un daha fazla dinamik özelliğini destekleme aşaması
- Ayrıntılar Mojo roadmap sayfasında görülebilir
- Mojo standart kütüphanesi GitHub’da tamamen açık kaynak olarak yayımlandı ve katkılara açık
- Mojo derleyicisinin 2026’da açık kaynak yapılması planlanıyor
- Tüm Mojo’yu açık kaynak yapma yönünde bir politika var; ancak dil hâlâ çok genç olduğundan, ortak bir vizyona sahip yakın çalışan bir mühendis grubunun topluluk odaklı bir yaklaşımdan daha hızlı ilerleyebileceği düşünülüyor
- Katılım için developer community bağlantısı sunuluyor

Öğrenme ve topluluk kaynakları

Install ve Quickstart guide: Mojo’ya başlangıç kaynakları
Beginner tutorial: Game of Life yaparak Mojo öğrenimi
GPU puzzles: Bulmacalar çözerek Mojo ile GPU programlama öğrenimi
Intro to Mojo: Mojo dil özelliklerine genel giriş
Developer forum: Mojo ile ilgili sorular ve güncellemeler
Events: Etkinlikler, meetup’lar, sunumlar ve hackathon duyuruları
Contributions: Açık konular, dokümantasyon katkıları ve proje paylaşımı bilgileri

1 yorum

GN⁺ 7 시간 전

Hacker News görüşleri

Son 2 yılda eğlencesine Mojo ile epey oynadım; gerçekten harika bir dil
Rust’a yakın bir sahiplik modeli, Zig’den daha güçlü derleme zamanı yürütme, zengin bir tip sistemi ve birinci sınıf SIMD desteği var
Performans açısından da uzun zamandır sadece basit bir LLVM sarmalayıcısı olmayan bir dil gibi görünüyor. Hâlâ LLVM kullanıyor ama bunu Rust veya Zig’den farklı bir şekilde kullanıyor
Bu yılın sonunda açık kaynak olursa Mojo için gerçekten heyecanlıyım
- “Zig’den daha güçlü derleme zamanı yürütme” kısmını biraz daha açarsan iyi olur
  Şu an sadece Mojo dokümanlarına bakınca bu sonuca varmak zor
Makine öğrenmesiyle uğraşıp performansa önem veren biri olarak Mojo’nun başarılı olmasını istiyorum. Özellikle aynı dil içinde GPU kodu ile CPU kodunu karıştırabilme fikri heyecan verici
Ama şu anki değişimlerin Python geliştiricilerini uzaklaştırmasından endişe ediyorum. En son denediğimde temel string işlemlerini test etmek için var x = 'hello'; print(x[3]) yapmıştım, çalışmamıştı; len(x) de yoktu, bununla bir saat uğraştım
Meğer byte ve codepoint gösterimlerini daha açık biçimde ayırmaya karar vermişler ama dokümantasyon gerçek uygulamayla çelişiyordu
Genel makine öğrenmesi için de kullanılabilir bir noktaya gelmesini isterim ama şu an hâlâ oldukça sınırlı hissettiriyor. Tensor’larla ilgili bazı düzgün temel özellikleri de kaldırmışlar
Şimdilik JAX kullanmaya devam edip ara sıra bakacağım
- Basit, hesaplama ağırlıklı kodu neden sadece çok az ek sözdizimiyle SIMD / çoklu iş parçacığı / çoklu işlem / GPU koduna dönüştüren bir dil hâlâ yok, anlamıyorum
  Bu, derleyici ve dil tasarımıyla ilgilenen insanların hayalini kuracağı türden bir şey değil mi?
  Her durumda verimlilik garantisi vermesi ya da son teknoloji performans sunması gerekmiyor, sadece var olması bile güzel olurdu
  Böyle bir dilin yapılabileceğini anlıyorum ama yapabilecek kişilerin ilgisini çekememiş gibi görünüyor
- Mojo havalı ama neden Python geriye dönük uyumluluğuna tutunuyor, anlamıyorum. Bu yüzden kendi ayağına sıkıyor
  Kotlin’de akla gelen dezavantajların neredeyse hepsi Java uyumluluğundan kaynaklanıyor. Burada bunu daha açık bir şekilde daha iyi çözebilirlerdi belki ama mevcut yaklaşım başarısız olmaya mahkûm gibi görünüyor
- Açık kaynak değilse pek anlamı yok. Çoğu Python geliştiricisi zaten gelmeyecek
- Bu açıdan bakınca neredeyse Nim programlama dilini yeniden yapmaya çalışıyorlar gibi duruyor
“Mojo’yu 2026 sonbaharında açık kaynak olarak yayımlamayı taahhüt ettiler” deniyor
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
- Gerçekten son teknoloji bir MLIR programının kaynak kodunu görebilsek güzel olurdu
Ne yazık ki bu arada Nvidia da boş durmadı ve MLIR tabanlı benzer bir derleyici yığınıyla Python için, yakında da C++ için CuTile adlı yeni nesil CUDA’yı yaptı
Taşınabilirlik olmasa bile, Nvidia’nın bunu güçlü biçimde itmesi, geliştirme araçlarına entegre etmesi ve mevcut CUDA koduyla birlikte çalıştırabilmesi nedeniyle Mojo’dan çok daha yaygın kullanılma ihtimali yüksek
Tile IR, Mojo’ya değil daha çok Triton’un oluşturduğu tehdide bir yanıt olabilir. Özellikle de yeterince performanslı LLM kernel’larını ne kadar kolay yazabildiğin açısından böyle düşünüyorum
- Geri kalmamak için Intel ve AMD de benzer çabalar içinde ve CPython JIT de birçok denemeden sonra nihayet gerçeğe dönüşüyor
  GraalPy ve PyPy gibi girişimler de var
  Tüm bu çabalar şu anda Windows’ta çalışıyor. Şirkette çalışanların çoğuna Windows cihazı verilip yalnızca sunucularda Linux dağıtımları kullanılan ortamlarda bu oldukça önemli
  Bunun da Swift for Tensorflow’a benzer bir sona gitmesinden korkmadan edemiyorum
- Birkaç Tile IR geliştiricisi ile konuştuğum kadarıyla, asıl motivasyon PTX’e kıyasla tensor core programlamasında daha iyi taşınabilirlik sunmaktı
  Müşteri geri bildirimi dışında buna başka bir şeye tepki olarak baktığını söyleyen olmadı
- İnsanlar sık sık Mojo’yu GPU kodu yazmak için iyi sözdizimine sahip bir şey sanıyor ve Nvidia’nın Python çerçevelerinin zaten bunu yaptığını düşünüyor
  Ama CuTile, AMD GPU’larda ya da Apple Silicon’da çalışacak mı? Nvidia ne yaparsa yapsın tedarikçiye bağımlılık ortadan kalkmıyor
- CuTile’ın etkisinin ne kadar büyük olacağını merak ediyorum
Mojo’yu ilk duyduğumda mevcut Python koduyla uyumlu olmaya çalıştığını sanmıştım
Ama yakın gelecekte bu hedeften çok uzak görünüyor. Python ile Mojo arasında gidip gelerek çağrı yapmak mümkün olabilir ama Mojo’nun kendisi mevcut Python kodunu çalıştıramıyor
- İlk tanıtımlarda bunun açıkça temel noktalardan biri olduğu söyleniyordu. Python koduna type hint ekleyerek büyük hız artışları elde edeceğin türünden bir anlatı vardı
  Ama geliştirdikçe yön değiştirmiş gibi görünüyorlar
- Yanlış hatırlamıyorsam eşdeğer Python’a göre 36.000 kat hızlanma da reklam etmişlerdi ama bunun yalnızca aşırı uç durumlarda mümkün olduğunu hiç açık etmediler
  Python ekosistemini iyileştirmeye dönük dürüst bir girişimden çok pump-and-dump tarzı bir kripto para planı gibi hissettiriyordu
- Çok dikkatli bakılsaydı, en başından beri fikrin yeni nesil bir sistem dili yaratmak olduğu açıktı
  Swift ve Rust’ın derslerini alan, CPU/GPU/heterojen hedefleri gözeten ve merkezine MLIR’i koyan bir dildi
  Aynı zamanda bir gün Python’u görece kolay biçimde gömebilmek ya da genişletebilmek de düşünülmüş gibiydi ve Python çerçevesi büyük olasılıkla finansman bulmaya ciddi biçimde yardımcı oldu
  Chris Lattner, Python ile Mojo arasındaki ilişkiden çok MLIR ile Mojo arasındaki ilişkiden söz ediyordu
- İlk reklamlar gerçekten öyleydi. Python için Kotlin benzeri bir şey olmak istiyorlardı ama kısa sürede yön değiştirdiler
  Bu ve tamamen açık kaynak olmayan geliştirme modeli yüzünden bana hep vaporware gibi geldi
- Sitede şöyle yazıyor
  Python birlikte çalışabilirliği: “Mojo, Python ile doğal olarak birlikte çalışabildiği için her şeyi yeniden yazmadan mevcut kodunuzdaki performans darboğazlarını ortadan kaldırabilirsiniz. Tek bir fonksiyonla başlayıp ihtiyaç oldukça performans açısından kritik kodları Mojo’ya taşıyarak ölçekleyebilirsiniz. Mojo kodu doğal biçimde Python’a import edilir ve dağıtım için birlikte paketlenir. Benzer şekilde Python ekosistemindeki kütüphaneler de Mojo koduna import edilebilir”
Mojo fena görünmüyor ama CPU ve GPU’yu kapsayan yüksek performanslı sayısal hesaplama için şu anda Julia’dan oldukça memnunum
Python benzeri sözdizimi dışında bu niş büyük ölçüde zaten çözülmüş gibi geliyor. Python’ın kendisinde bile Numba ve Triton gibi, daha az karmaşık ve daha bağımsız türde problemlerde etkili araçlar var
Aynı amaç için Julia daha olgun ve Nvidia geçen yıldan beri CUDA’da Python araçlarıyla C++ araçları arasında özellik eşitliği sağlamaya çalışıyor
Python cuTile JIT derleyicisiyle neredeyse saf Python yazar gibi CUDA kernel’ları yazabiliyorsun
AMD ve Intel de benzer yaklaşımı izliyor
Mojo’nun daha geniş benimsenme elde edecek kadar zamanında gelip gelmeyeceğini görmek lazım
- Python cuTile JIT derleyicisinin saf Python ile CUDA kernel’ı yazdırdığı doğru değil. Şu anda da saf Python değil, gelecekte de olamaz
  Triton, Pythran, CuTile, Numba, Pycell, cuPy gibi bu “performans dostu” Python lehçeleri dışarıdan Python gibi görünür ama biraz kazıyınca Python’la pek ilgileri kalmaz
  Bunlar, optimizasyon ve tip çıkarımının iyi çalışması için tasarlanmış Python tarzı DSL’lerdir. Gerçekte kullanınca da öyle hissettirirler. Her birinde Python’un birçok, hatta belki de çoğu özelliğini kullanamazsın ama Python’a özgü sorunları yine de taşımaya devam edersin
  Açıkçası Python verimlilik ve performans açısından özünde iyi bir dil değil
  Bu, GIL’in çok ötesinde bir mesele. Dinamik tipleme, referans semantiği, monkey patching, aşırı dinamik nesne modeli, CPython ABI, varsayılan BigInt, çalışma zamanı modül sistemi gibi şeyler küçük betik dilleri için mantıklı olabilir ama yüksek performanslı hesaplama ve verimlilik için çok kötüler
  NumPy/SciPy ekosistemi de aslında basit CPU sınırlı tensor aritmetiği için Python’un sınırlarını aşmaya çalışan bir hack yığınına yakın
  Çünkü temel Python performansı o kadar kötü ki basit bir for döngüsü bile Excel’i yarış atı gibi gösterebiliyor
  Mojo farklı
  Mojo, sorunlu mevcut temeli hack’lemek yerine temiz bir başlangıç noktasından yola çıkmaya çalışıyor
  Ve 30 yılı aşmış Python’un yerine, geçmiş dil tasarımı deneyimlerinin üzerine iyi tasarlanmış bir dille “Python benzeri bir deneyim” sunmak istiyor
  Sırf bu yüzden bile başarılı olmasını istiyorum
Görünüşe göre bugünlerde en azından bazı insanlara AI native vurgusuyla reklam yapmak gerekiyor
Ama bana biraz itici geliyor. Çünkü aslında hiçbir şey söylemeyen bir ifade gibi duruyor
“Derlenen ve statik tipli bir dil olduğu için ajan tabanlı programlama için de idealdir” sözünün neden doğru olduğu ve tam olarak ne anlama geldiği konusunda yapay zeka heyecanlıları açıklama yapabilir mi?
- Yapay zekanın öne çıkmasından sonra bu ürün ve hizmetlerin açılış sayfalarında görülen o çaresizlik gerçekten çok ilginçti
  Benim için en komiği IBM DB2 ürün sayfasını açtığımda üstünde AI database yazdığını görmekti
  Derleme zamanında daha fazla hata yakalanması, ajanların birim testi ya da başka testler olmadan da kendi işlerini statik olarak hızlıca doğrulayabilmesi anlamına geliyor olabilir
- Günümüz LLM’leri geçmişte yazılmış devasa kod kütüphaneleri üzerinde eğitildi. Bu yüzden yakın gelecekte yeni dillerden çok yerleşik dillerde daha iyi çalışacaklar
  Özellikle Python gibi kullanılabilir açık kaynak kodu bol olan diller avantajlı. Öğrenecek mevcut kodu olmayan yeni gelenler için bu büyük bir sorun
  O yüzden “ajan tabanlı” dünyada ilgili görünmek için böyle umutsuz bir AI native pazarlaması gerekebilir. Yeterli olup olmadığını zaman gösterecek
- Kendimi yapay zeka tutkunu saymam ama gerçekten kullanıyorum
  Ajanlar daha çok geri bildirim aldıkça daha iyi performans gösterme eğiliminde. Tip denetimi aptalca hataların önemli bir kısmını otomatik olarak yakalamakta faydalı
  Yani mesele şu: ajanlara ne kadar çok ipucu verirsen, genelde o kadar iyi oluyorlar
- Bununla tam olarak ne demek istediklerini bilmiyorum ve bu tür programlama dillerinde “AI native” ifadesinin biraz anlamsız olduğuna katılıyorum
  Derleme ve statik tipleme konusunda ise, ajan tabanlı programlama yaparken sorunları derleme zamanında yakalayabilmek gerçekten çok yardımcı oluyor
  Böylece çalışma zamanında karşılaşılan sorunlar azalıyor ve ajanın çözmekte zorlanacağı durumlar da azalıyor. Birim testler bu boşluğun bir kısmını kapatabilir ama tamamını değil
  Sitede yazmayan şey şu: Mojo aslında ajan tabanlı programlama için kötü bir seçim bile olabilir. Çünkü henüz yeterince Mojo eğitim verisi yok
- Bu, yeni “...on the blockchain” oldu
  Python+ruff+pycheck ve TypeScript makine koduna değil bytecode’a derleniyor. Rust tarzı anlamda statik tipli de değiller
  Buna rağmen modellerin her ikisinde de oldukça iyi, geçerli kod ürettiğini gördüm. Katı anlamda “derlenen” ya da “statik tipli” olmaları gerekmiyordu
  Sonuçta yapay zeka, kodu hızlıca doğrulayıp yinelemeyi sağlayan iyi araçlar olduğu sürece bu özellikleri çok da umursamıyor
Modular bu yılın sonunda derleyici de dahil olmak üzere tüm Mojo SDK’yı açık kaynak yapmayı planlıyor
“Mojo 1.0 bu yılın sonunda kesinleşecek; derleyicinin açılması ve dil kararlılığı da buna eşlik edecek” deniyor
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
Mojo’yu izlemeye devam ediyorum. Dürüst olmak gerekirse Python’da en sevmediğim şey sözdizimi
Burada başka biri Julia’dan bahsetmiş; bence iyi bir dil. Ama derleyici hata mesajları ve kütüphane dokümantasyonu, bu kadar olgun bir dilden beklediğim seviyede değil
Bir zamanlar okuduğum bir blogdaki doğruluk sorunları da beni endişelendiriyor. Ayrıca ikili dosya boyutu ve ilk çalıştırma süresi yüzünden istediğim türde bir Python modülünü Julia ile yapabileceğimi sanmıyorum
Yine de Mojo’nun bir seçenek olmasını umuyorum. Ama REPL’i seviyorum ve Python’un dinamik doğasını da seviyorum; bu yüzden performans için NumPy’nin dışına çıkmamam da mümkün
- Benim için tam tersi. Python’da sevdiğim tek şey sözdizimi
  Bu yüzden Nim’i gerçekten çok seviyorum. C düzeyinde hız, derleme zamanı yürütme, metaprogramlama, güçlü bir tip sistemi ve bellek güvenliği elde ederken kod da çoğu zaman kısa ve zarif kalıyor
  Mojo da ilginç ama şimdiye kadar genel amaçlı programlamadan çok makine öğrenmesine odaklanmış gibi görünüyor. Ayrıca bildiğim kadarıyla derleyicisi hâlâ açık kaynak değil
- Mojo’nun tasarımını çok beğeniyorum. Deterministik bellek yönetimi olduğu için Julia ile karşılaştırılamaz
  Ayrıca Mojo sanki endüstriyel ölçekte sağlam bir dil olmaya daha fazla odaklanıyor. Julia’nın ilk ön derleme uygulamasının dosya G/Ç sunmadığını görmek beni şaşırtmıştı

Mojo 1.0 Beta

Sürümler ve başlangıç kaynakları

GPU ve Python birlikte çalışabilirliği

GPU programlama

Python birlikte çalışabilirliği

Derleme zamanı metaprogramlama

Yol haritası ve açık kaynak

Phase 0

Phase 1

Phase 2

Phase 3

Öğrenme ve topluluk kaynakları

İlgili okumalar

1 yorum

Hacker News görüşleri