- Chris Lattner, LLVM ve Swift dilinin kilit geliştiricilerinden biri ve en yeni ML donanımının performansını en üst düzeye çıkarmak için yeni bir dil olan Mojo'yu geliştiriyor
- Mojo, hem kullanım kolaylığı hem de donanımın ayrıntıları üzerinde denetim sunan bir dil olarak tasarlanıyor; tip güvenli metaprogramlama ile donanım ayrıntılarının verimli biçimde ele alınmasını destekliyor
- GPU, TPU, ASIC gibi yapay zeka hızlandırıcı ekosistemindeki parçalanma sorununu çözmek ve belirli satıcılara bağımlılığı azaltmak için birleşik bir hesaplama platformu kurmak temel motivasyonlardan biri
- Mevcut GPU yazılım yığınlarında (CUDA, ROCm, XLA vb.) görülen uyumluluk ve karmaşıklık sorunları, yeni nesil yüksek performanslı ve taşınabilir bir dilin geliştirilmesini zorunlu kılıyor
- Modular, Mojo'yu ücretsiz sunarken birleşik donanım desteği ve kurumsal hizmetler gibi gerçek sorunların çözümüne odaklanan bir iş modeli izliyor
Chris Lattner'a giriş ve kariyeri
- Chris Lattner, LLVM, Clang, MLIR, Swift, Mojo gibi bilgi işlem alanındaki birçok kilit projeye liderlik etmiş bir isim
- Apple, Tesla, Google, SiFive, Modular gibi farklı kurumlarda çalışarak derleyici ve programlama dili tasarımı konusunda geniş çaplı pratik deneyim edindi
- İlk olarak BASIC gibi basit diller ve PC ortamıyla başladı; oyunlar ve grafikler aracılığıyla donanım performansını en üst düzeye çıkarma konusuna ilgi duydu
- Üniversite yıllarında, tesadüfen bir derleyici uzmanı profesörün etkisiyle sistemlerin ve büyük ölçekli yazılım mimarisinin cazibesini keşfetti
Derleyici ile dil tasarımı arasında gidip gelmek
- Chris Lattner, derleyici mühendisliği ve dil tasarımını birlikte deneyimleyerek bu iki alanın kesişiminde önemli başarılar elde etti
- Örneğin LLVM, farklı dillerin kullanabildiği bir ara dil olarak yalnızca C++ uygulamalarında değil Rust, Julia gibi alanlarda da geniş kullanım yarattı
- Swift'in geliştirilmesi de mevcut C++ tabanlı yaklaşımın sınırlarını ve yorgunluğunu aşma girişimi olarak başladı; pattern matching gibi pratik özelliklerin gerekliliğine önem verdi
- Programlama dili yeniliğinde, matematiksel teoriden çok gerçek sorun çözme ve fayda temelli bir tasarım yaklaşımını tercih ediyor
Programlama dili teorisi ve pratiklik
- Chris, matematiksel katılıktan ziyade sorun çözme odaklı bir düşünce yapısını benimsiyor; PL makalelerinde teorinin kendisinden çok pratik örnekler ve kullanım senaryolarıyla ilgileniyor
- Matematiksel temeli güçlü dil özelliklerinin tutarlılık ve birleştirilebilirlik açısından avantajlı olduğunu kabul ediyor, ancak gerçek benimsemenin itici gücü görünür kullanım faydası
- Yeni bir dil ya da teknolojide, karmaşıklığın "kum tanesini (grain of sand)" olabildiğince azaltarak tasarımın sadeleşmesini ve ölçeklenebilirliğini hedeflemenin önemli olduğunu vurguluyor
Yapay zeka donanım ekosisteminin yapısal sorunları
- Geleneksel derleyici altyapısı (LLVM) CPU merkezliyken, AI/makine öğrenimi GPU, TPU, ASIC, FPGA gibi çeşitli özel amaçlı donanımlar gerektiriyor
- Her satıcının kendine özgü yazılım yığınını (CUDA, ROCm, XLA vb.) geliştirmesi, uyumluluk eksikliği ve ekosistem parçalanmasına yol açıyor
- ML yazılımları (ör. PyTorch vb.) donanım satıcısına göre ayrı optimizasyon gerektirdiğinden bakım ve genişletme çok zor hale geliyor
- Her donanımın farklı bir yığın, dil ve araç ekosistemine sahip olması, yazılım geliştiriciler açısından verimlilik ve taşınabilirlik kaybını yaygınlaştırıyor
Modular ve Mojo'nun rolü
- Modular ekibi, bu sorunları çözmek için genel amaçlı ve birleşik bir yazılım platformu kurmaya odaklanıyor
- Mojo, en yeni GPU mimarilerinin (tensor core vb.) performans özelliklerinden yararlanmanın yanı sıra, farklı donanımlarda taşınabilir çekirdekler yazmayı hedefleyen bir dil olarak tasarlanıyor
- Mojo, MAX (yüksek performanslı LLM serving vb.), Mammoth (küme/Kubernetes yönetimi) gibi çok katmanlı bir yapı üzerinden birleşik bir yapay zeka altyapısı sunuyor
Mojo'nun neden gerekli olduğu ve dil tasarımı kararları
- Mevcut diller, yüksek performanslı ML çekirdeklerinin taşınabilirliği ile satıcıya özel optimizasyon gereksinimlerini aynı anda karşılayamıyor
- Mojo'nun, donanımın ayrıntılı yapısına; örneğin çeşitli veri tiplerine (8 bit floating point vb.) ve tensor core gibi hızla değişen donanım yeniliklerine dinamik olarak uyum sağlayabilmesi gerekiyor
- Tip güvenli bir metaprogramlama modeli, karmaşık donanım denetimini daha verimli ve paylaşılabilir bir yapıya dönüştürüyor
Donanım ve çekirdek tasarımındaki değişim
- Modern veri merkezlerindeki CPU'lar çok sayıda çekirdeğe ölçeklenirken, GPU'lar SM (Streaming Multiprocessor) yapısı ve Warp (32 iş parçacıklı çalışma) gibi paralel işlem odaklı tasarımlarla hızlı biçimde gelişti
- Tensor core gibi AI'ya özel işlem birimlerinin donanıma eklenmesi, geleneksel CUDA'dan tamamen farklı bir donanım programlama paradigmasını gerekli kıldı
- Aynı satıcı içinde bile mimari nesiller arasında uyumluluk değişimleri sık yaşanıyor (ör. Nvidia Volta/Hopper/Blackwell değişimleri) ve yazılım yığını buna ayak uyduramıyor
İş modeli ve açık ekosistem stratejisi
- Modular, dilin kendisini satmaya odaklanmıyor; Mojo'yu ücretsiz yayımlıyor
- Temel gelir modeli, birleşik donanım yönetimi ve kurumsal müşterilere yönelik platform/hizmet sunumuna dayanıyor
- Böylece satıcı kilidine yol açmayan ortak bir ekosistem kurmayı hedeflerken, aynı anda farklı donanım desteği ve verimli altyapı yönetimini amaçlıyor
Sonuç
- Chris Lattner ve Modular'ın Mojo projesi, makine öğreniminin ilerlemesi, yapay zeka donanımındaki yenilikler ve ekosistem parçalanmasının aşılması için yeni bir programlama dili ve platformu oluşturma açısından önemli bir girişim
- Yenilikçi dil tasarımı ve açık ekosistemin yaygınlaşmasıyla yapay zeka ekosisteminin demokratikleşmesine ve verimliliğin artmasına katkı sunmayı amaçlıyor
1 yorum
Hacker News görüşleri
Mojo ve podcast’e ilgi gösteren herkese teşekkür etmek istiyorum. Mojo hakkında daha fazlasını merak ediyorsanız SSS sayfasında sık sorulan soruları görebilirsiniz (“neden Julia’yı daha iyi hale getirmiyorsunuz” sorusunun yanıtı da var). Belgeleri de burada inceleyebilirsiniz ve açık kaynak kodu da yüz binlerce satırlık ölçeğiyle yayımlanmış durumda. Mojo topluluğu da gerçekten harika; Discourse forumuna ya da Discord sohbetine katılırsanız sevinirim - Chris Lattner’ın görüşü
Hayranıyım. Mojo hakkında çeşitli sunumlar izledim ama Mojo’nun ileri düzey derleyici teknolojilerinden yararlandığı söylenmesine rağmen buna dair somut örnekler pek duymadım. Derleyici geliştiricisi olmasam da %20’sini anlasam bile bu ileri teknolojilerin gerçek gücünü hissetmek isterim; o yüzden gerçekten derin ve teknik bir blog yazısı yazmanızı isterim
SSS’de "Mojo Playground hâlâ kullanılabiliyor mu?" diye sorulunca ilgili playground’a yönlendiriyor, ama oraya gidince de “bir sonraki 25.6 sürümünde Playground kaldırılacak” deniyor. “Bu kullanılabiliyor mu” sorusuna, yakında kaldırılacak bir özelliği işaret eden SSS yanıtı bence meseleyi kaçırıyor. Gerçekte yanıt galiba “çok uzun süre değil”
Chris, burada seni görmek güzel. Zamanında Light Table üzerinden yatırım da yapmıştım; acaba bununla ilgili bir güncelleme var mı merak ediyorum. (Bunu çok ciddi sormuyorum, Mojo gerçekten havalı görünüyor.) Bu tür projelerin uzun vadeli sürdürülebilirliği konusunda güvenilebilir bir dayanak var mı, onu merak ediyorum
Python’ın ML alanına hakim olmasının nedeni, modern ML uygulamalarının sadece hesaplama script’leri değil, geniş işlev setleri ve sağlam bir ekosistem gerektirmesidir. Her türlü veri ön işleme (ETL), farklı formatlardaki verileri işleme, yüksek performanslı hesaplama kümelerinde dağıtık çalışma, görselleştirme ve GUI/DB entegrasyonu gibi her şeyi kapsayan Python dışında bir dil yok. Sayısal hesaplama tarafında NumPy, PyTorch, JAX gibi araçlar içeride C/C++/FORTRAN kullandığı için çok hızlı ve performans kritik kodu ayrıca C/C++ ile yazmak da kolay. Python’ın C/C++ FFI sistemi de diğer dillere kıyasla yeterince pratik. Başka bir dilde (Julia vb.) tüm ekosistemi baştan kurmaktan çok daha fazla avantaj sunuyor
Python ekosistemi rakipsiz ama Elixir/Nx kombinasyonu da Mojo’nun vaat ettiği şeylerin önemli bir bölümünü zaten yapıyor. EXLA ile GPU/TPU derlemesi mümkün, Explorer/Polars ile dataframe işleri yapılabiliyor, Pythonx ile de Python kütüphaneleri gömülebiliyor. Fark şu ki Elixir en baştan dağıtık sistem kurmak için tasarlandı; BEAM/OTP çok büyük eşzamanlı istekleri ve GPU düğümleri arasındaki koordinasyonu da kaldırabiliyor. Gerçek bir ML servisi kuruyorsanız Phoenix, LiveView ve Nx ile tek ve sağlam bir stack üzerinden aşırı hata toleransı ve ölçeklenebilirlik elde etmek, ufak donanım performansı farklarından daha önemli olabilir
Ben inference tarafında biraz farklı düşünüyorum. CUDA kernel’larını doğrudan elden geçirip yazmak kolay ve güncel CUTLASS 3 ya da modern C++ çok daha kullanışlı hale geldi. Bunun üstünde Torch ince bir katman olarak duruyor ama bu kısım hem derlemesi zor hem de reference counting başta olmak üzere çeşitli sorunlarla karmaşıklık ekliyor. Asıl kritik uygulama alttaki kernel’larda; yakında bu tür “torch kaplamasını” kaldırıp temiz bir C++ programıyla doğrudan ve net biçimde bağlayarak kullanmayı düşünüyorum
Bu mesele GPU kernel’larıyla ilgili ve zaten böyle kernel’lar baştan Python’da yazılmıyor. Python, ML için bir “glue” dili. “Tüm işlevleri yalnızca Python sağlıyor” iddiasına katılıyorum ama ekosistemin daha iyi bir dil yerine Python etrafında büyümüş olması yine de biraz üzücü
Python’ın ML’in ana dili haline gelmesi bir “erdemli döngü”. Zaten seçilmiş olduğu için ekosistem büyüdü; ama ilk başta neden seçildiği ayrı açıklanmalı. Şu an aşılması imkansız görünecek kadar büyüdü ama neden en başta Python olduğu için gerekçe olarak bu tek başına yeterli değil
İronik biçimde Python, bahsedilen tüm işler için en kötü dil. Paketleme de binary/wheel işi de tam bir çile ve sürekli bir şeyler bozuluyor. Tek başına script yazmak için fena değil ama hedef baştan ML’in ana dili olmak olsaydı, Python’ı kimse böyle tasarlamak istemezdi
Bölümü dinleyince şaşırdım. 2025 Eylül’üne gelindiğinde bile class desteğinin hâlâ orta vadeli hedef olarak anılması gerçekten sürprizdi. Eskiden Mojo sık sık “Python’ın üst kümesi” diye tanıtılıyordu ama mevcut ilerleme hızına bakınca bu daha çok ideal bir hedef gibi görünüyor
Aslında “Python üst kümesi” hiçbir zaman gerçek hedef değildi. Bu daha çok insanların ilgisini çekmek için kullanılan bir slogandı; başlarda vurgulandı, sonra sessizce geri çekildi
Belki de mesele hız değil, OOP’nin kendisini sevmemeleri
Bu zaten hep uzun vadeli bir hedefti
Belki biraz klişe bir soru ama neden Lisp olmadığını merak ediyorum. Gelecekteki ML kodunun sonuçta makine (veya doğal dil tabanlı otomatik dönüştürme sistemleri) tarafından yazılacağını varsayarsak, Lisp S-Expression’ları fiilen AST ile aynı şey olduğundan makineler için en doğal dil gibi duruyor. REPL ortamı da genelde tam olduğu için Python yerine geçecek bir seçenek olarak çok iyi uyuyor gibi
Yann LeCun ve diğerleri zamanında Lush diye ML için bir Lisp yapmıştı. 2000’lerde mükemmeldi ve Python (Theano) ya da Lua (Torch) çıkmadan önce gerçek bir alternatif yoktu. Bugünlerde Lisp’in yeniden ilgi görmesini isterim. Python’ın kütüphaneleri harika ama dilin kendisinde geliştirilecek çok şey var
LLM’ler (büyük dil modelleri) hâlâ parantez saymakta pek iyi değil ;)
Geçmişteki AI patlaması sırasında Lisp dışarıda bırakıldığı için birçok geliştirici hâlâ sadece Emacs + SBCL kullanıyor. Oysa LispWorks, Allegro, Clozure gibi başka gelişmiş Lisp uygulamaları da var ama çoğu kişi bunları hiç denemedi
Mojo’nun lisansını en baştan sevmiyorum
Ben de baktım; Mojo lisansı CPU ya da Nvidia kullanımıyla diğer “hızlandırıcılar”ı (TPU, AMD vb.) ayırıyor ve ticari kullanımda ayrıca lisans gerektiğini söylüyor blog yazısına bakın
Benim açımdan bir şirket tarafından mutlak biçimde kontrol edilen bir dili (Mojo) işimde kullanmak için hiçbir neden yok. Java lisans değişikliklerinde birçok şirketin sorun yaşadığına dair örnekler zaten var. Python yerine Mojo üzerine iş kurmak gereksiz derecede riskli
Mojo SSS’sine bakınca, teknik olarak Python üst kümesi olmayı hedeflediği söyleniyor ama yol haritasında da “Python kodu ve aşinalığı sağlar, ancak tam bir üst küme olamaz” deniyor; bu da kafa karışıklığını artırıyor. Python uyumluluğu hedef değilse neden Python’dan bu kadar söz ediliyor anlamıyorum. Bir de dosya uzantısı olarak emoji kullanıldığına dair söylentinin gerçek olup olmadığını merak ediyorum
Bildiğim kadarıyla Mojo yalnızca Python tarzı sözdizimi ve Python ile birlikte çalışabilirlik istiyor. Bunun ötesinde Python’a benzerlik vurgusu daha çok pazarlama amaçlı
Emoji uzantısı konusunda evet, doğru. U+2615 (kahve emojisi)
Mojo’nun Julia’dan ne açıdan daha iyi olduğunu merak ediyorum. Julia’nın da arayüz ve ekosistem sınırları var ama Python’la entegrasyonu gayet iyi; bu yüzden Mojo’nun belirgin biçimde daha iyi olduğunu hissetmiyorum
Özellikle Julia’nın JuliaGPU ve Reactant gibi güçlü bir GPU ekosistemi var Reactant.jl’ye bakın
Python ile uyumluluk Mojo’da biraz daha iyi olabilir ama pratikte Julia’da da PythonCall.jl ile Python kütüphanelerini çağırmak oldukça istikrarlı. ML framework’leri (Lux.jl, Flux.jl) de Julia içinde iyi çalışıyor. Mojo’da ise benzer seviyede yerel bir ML framework’ü henüz yok gibi
Mojo daha düşük seviyeli bir dil hissi, daha fazla kontrol ve daha yüksek sağlamlık hedefliyor gibi. Julia ise anlam veya performans açısından öngörülebilir olmadığı için çekirdek yazılım temeli olmaya çok uygun değil; Mojo bu konuda daha avantajlı
Python modüllerini Julia ile oluşturmayı denedim ama desteğin hâlâ yetersiz olduğunu hissettim. Mojo’da ise bu kısım temel özelliklerden biri
Julia kodunu Rust ya da C++’taki gibi tamamen yerel binary’ye derleme yeteneği hâlâ zayıf
Mojo’nun beklenen kadar büyük ilgi görmemesi ve PyTorch kullanımının sürmesi, lisans meselesinin gerçekte sanılandan daha büyük olduğuna dair bir işaret olabilir diye düşünüyorum
Mojo kendi alanını fazla iyimser tanımlamış olabilir. Julia da gerçek ticari kullanımda yavaş yavaş artıyor ve GPU desteği de iyi. Python’ın JIT derleyicileri eksik olsa bile Nvidia, Intel gibi şirketler Python DSL’leriyle GPGPU programlamayı oldukça iyi optimize ediyor; yani Python içinde bile C++ seviyesine yakın çalışmak mümkün. Sonuç olarak Mojo’nun fark yaratması zor
Sistemler açısından bakınca Chris ve ekibinin Mojo ile çok dilli FFI sorunlarını kökten iyileştirmeye çalışması etkileyici. Ama açık kaynak olmadan önce ne yatırım ne de değerlendirme tarafında bir şey başlatabilirim
Henüz genel amaçlı programlama dili olarak kullanıma hazır değil. Modular da MAX motoruna Mojo API’sini uygulamaya çalışmış ama dil o kadar hızlı değişmiş ki yatırımdan vazgeçmiş. Yol haritasındaki 1. aşama tamamlandıktan sonra daha ciddi benimsenme bekleniyor
Gerçekten açık yayımlandı mı emin değilim. Yakın zamana kadar açık kaynak yapılmamış olması, ticari ve kapalı bir yazılıma bağımlı kalma konusunda beni rahatsız ediyordu
Yazının başında “state-of-the-art kernel” kullanılabileceği söyleniyor. Sonuçta Mojo sanki kernel geliştirme tarafında C++ ile rekabet etmek istiyor. PyTorch ya da Julia’da ise doğrudan kernel yazmak yerine daha çok yüksek seviyeli kod yazılıyor
Chris Lattner’ın yer aldığı bazı Lex Fridman podcast bölümleri var:
Mojo girişiminin kendisi cesur ve ilginç ama Matlab gibi kapalı bir dil olacaksa, benim için olduğu kadar birçok kişi için de bu ciddi bir kusur