Mojo 1.0 बीटा

(mojolang.org)

3 पॉइंट द्वारा GN⁺ 7 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Mojo खुद को “Python की तरह लिखें, C++ की तरह चलाएँ” भाषा के रूप में पेश करता है, और वर्तमान में स्थिर संस्करण 1.0.0b1 (May 7) उपलब्ध कराता है
इसका लक्ष्य CPU से GPU तक विभिन्न हार्डवेयर पर तेज़ कोड लिखना है, वह भी किसी खास vendor पर निर्भर हुए बिना, और इसे आधुनिक AI सिस्टम्स के लिए उच्च-प्रदर्शन static type language के रूप में डिज़ाइन किया गया है
Python interoperability का native समर्थन होने से मौजूदा कोडबेस को पूरा दोबारा लिखे बिना केवल performance bottleneck वाले हिस्सों को Mojo में ले जाया जा सकता है, और यह Mojo code का Python import तथा Python libraries का import दोनों सपोर्ट करता है
उसी भाषा में GPU kernels लिखे जा सकते हैं, और runtime code जैसी ही भाषा का उपयोग करने वाली compile-time metaprogramming के जरिए हार्डवेयर-विशिष्ट optimization और zero-cost abstraction देने का लक्ष्य है
Mojo standard library GitHub पर पूरी तरह open source के रूप में उपलब्ध है और योगदान स्वीकार कर रही है, जबकि Mojo compiler को 2026 में open source करने की योजना है

संस्करण और शुरुआती संसाधन

वर्तमान स्थिर संस्करण 1.0.0b1 (May 7) है, और नवीनतम nightly May 9 है
Mojo को Python के सहज syntax, Rust की memory safety, और Zig की शक्तिशाली व सहज compile-time metaprogramming से प्रेरणा मिली है
एक compiled static type language के रूप में यह agentic programming के लिए भी उपयुक्त है
इसका लक्ष्य productivity और performance में से किसी एक को चुनने के बजाय दोनों देना है, ताकि सरल और परिचित programming pattern से शुरू करके जरूरत पड़ने पर जटिलता जोड़ी जा सके
शुरुआत के लिए Install Now, Quickstart, Releases, Roadmap, GitHub उपलब्ध हैं
पेज को Markdown में देखने के लिए URL में .md जोड़ा जा सकता है, और पूरा Mojo documentation index llms.txt में देखा जा सकता है

GPU और Python interoperability

GPU प्रोग्रामिंग
- Mojo का लक्ष्य GPU programming को vendor-specific libraries या अलग compile code के बिना सुलभ बनाना है
- CPU के लिए इस्तेमाल होने वाली उसी भाषा में उच्च-प्रदर्शन GPU kernels लिखे जा सकते हैं
- उदाहरण kernel vector_add TileTensor लेता है और global_idx.x के आधार पर result[i] = a[i] + b[i] चलाता है
```
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 interoperability
- Mojo, Python के साथ native interoperability देता है, जिससे मौजूदा कोड को पूरा दोबारा लिखे बिना performance bottleneck हटाए जा सकते हैं
- एक फ़ंक्शन से शुरुआत करके जरूरत के अनुसार performance-critical code को Mojo में शिफ्ट करने के तरीके से इसे बढ़ाया जा सकता है
- Mojo code को Python में स्वाभाविक रूप से import किया जा सकता है और इसे deployment package में साथ bundle भी किया जा सकता है
- इसके उलट, Mojo code के अंदर Python ecosystem की libraries भी import की जा सकती हैं
- उदाहरण फ़ंक्शन mojo_square_array PythonObject के ctypes.data से pointer लेता है, compile time पर SIMD width की गणना करता है, और array elements को square करता है
```
# 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 metaprogramming

Mojo की metaprogramming runtime code जैसी ही भाषा का उपयोग करके performance को अधिकतम करने वाला सहज सिस्टम देती है
conditional compilation से हार्डवेयर-विशिष्ट optimization बनाए जा सकते हैं, compile-time evaluation से memory safety सुनिश्चित की जा सकती है, और महंगे runtime branch हटाए जा सकते हैं
लक्ष्य है इरादे को स्पष्ट रूप से व्यक्त करते हुए zero-cost abstraction देना

उदाहरण __eq__ implementation compile-time reflection से struct field names और types प्राप्त करती है, फिर जाँचती है कि सभी fields Equatable को संतुष्ट करते हैं या नहीं, और उसके बाद field-wise equality करती है

# 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

रोडमैप और open source

Mojo की शुरुआत 2022 के अंत में हुई थी, और अभी इसमें बहुत काम बाकी है
Phase 0
- शुरुआती आधार निर्माण चरण
- यह core parser, memory types, functions, structs, initializers, calling conventions और अन्य language foundations को लागू करने का चरण है
Phase 1
- यह वर्तमान में चल रहा चरण है
- लक्ष्य इसे CPU, GPU और ASIC पर high-performance kernels लिखने के लिए एक शक्तिशाली और expressive language बनाना है, साथ ही developers को Python को सहज रूप से extend करने देना है
Phase 2
- systems application programming चरण
- यह guaranteed memory safety model और systems programming developers की अपेक्षित अधिक abstraction capabilities के समर्थन तक विस्तार करने का चरण है
Phase 3
- dynamic object-oriented programming चरण
- यह Python code के साथ compatibility को अधिकतम करने के लिए classes, inheritance और untyped variables जैसी Python की dynamic features को अधिक समर्थन देने का चरण है
- अधिक जानकारी Mojo roadmap में देखी जा सकती है
- Mojo standard library GitHub पर पूरी तरह open source है और योगदान स्वीकार कर रही है
- Mojo compiler को 2026 में open source करने की योजना है
- पूरी Mojo stack को open source करने की नीति है, लेकिन भाषा अभी बहुत शुरुआती अवस्था में होने के कारण टीम का मानना है कि साझा दृष्टि वाले एक करीबी engineering group के साथ community-led मॉडल की तुलना में वे अधिक तेज़ी से आगे बढ़ सकते हैं
- भागीदारी के लिए developer community उपलब्ध है

सीखने और community संसाधन

Install और Quickstart guide: Mojo शुरू करने के संसाधन
Beginner tutorial: Game of Life बनाते हुए Mojo सीखें
GPU puzzles: puzzles हल करते हुए Mojo से GPU programming सीखें
Intro to Mojo: Mojo language features का व्यापक परिचय
Developer forum: Mojo से जुड़े प्रश्न और अपडेट
Events: events, meetups, talks, और hackathons की जानकारी
Contributions: open issues, documentation contribution, और project sharing की जानकारी

1 टिप्पणियां

GN⁺ 7 시간 전

Hacker News की राय

पिछले 2 सालों में मैंने मज़े के लिए Mojo काफी इस्तेमाल किया है, और यह सच में एक शानदार भाषा है
इसमें Rust जैसा ownership model, Zig से अधिक शक्तिशाली compile-time execution, समृद्ध type system, और first-class SIMD support जैसी चीज़ें हैं
performance के लिहाज़ से भी यह लंबे समय बाद सिर्फ़ एक साधारण LLVM wrapper नहीं, बल्कि एक असली language जैसी लगती है। LLVM का उपयोग अब भी होता है, लेकिन Rust या Zig से अलग तरीके से
इस साल के अंत में open source होने पर Mojo से काफ़ी उम्मीद है
- “Zig से अधिक शक्तिशाली compile-time execution” वाले हिस्से को थोड़ा और समझाया जाए तो अच्छा होगा
  अभी Mojo के docs देखकर उस निष्कर्ष तक पहुँचना मुश्किल है
machine learning करते हुए performance में दिलचस्पी रखने वाले के तौर पर मैं चाहता हूँ कि Mojo सफल हो। खासकर एक ही भाषा में GPU code और CPU code को मिलाकर लिख पाने की बात उत्साहजनक है
लेकिन चिंता है कि मौजूदा बदलाव Python developers को दूर न कर दें। आख़िरी बार चलाकर देखा तो basic string manipulation जाँचने के लिए var x = 'hello'; print(x[3]) किया, लेकिन यह काम नहीं किया, और len(x) भी नहीं चला, जिससे मैं एक घंटे तक उलझा रहा
बाद में पता चला कि byte और codepoint representations को अधिक स्पष्ट रूप से अलग करने का फ़ैसला किया गया था, लेकिन docs वास्तविक implementation से टकरा रहे थे
उम्मीद है कि यह सामान्य machine learning के लिए भी उपयोगी स्थिति तक पहुँचे, लेकिन अभी यह काफ़ी सीमित लगता है। Tensor से जुड़ी कुछ अच्छी basic सुविधाएँ भी हटा दी गई हैं
फिलहाल मैं JAX इस्तेमाल करता रहूँगा और बीच-बीच में इसे देखता रहूँगा
- समझ नहीं आता कि अभी तक ऐसी कोई भाषा क्यों नहीं है जो साधारण compute-heavy code को बहुत कम अतिरिक्त syntax के साथ SIMD / multithread / multiprocessing / GPU code में बदल दे
  ऐसा तो compiler और language design में रुचि रखने वालों का सपना होना चाहिए
  ज़रूरी नहीं कि हर स्थिति में efficiency की गारंटी दे या cutting-edge performance दे, बस उसका अस्तित्व ही अच्छा होगा
  मेरी समझ में ऐसी भाषा बनाना संभव है, लेकिन शायद जो लोग बना सकते हैं उनकी इसमें रुचि नहीं जगी
- Mojo शानदार है, लेकिन समझ नहीं आता कि यह Python backward compatibility को क्यों पकड़े हुए है। उसी वजह से यह खुद अपने पैर में कुल्हाड़ी मार रहा है
  Kotlin की जो कमियाँ याद आती हैं, उनमें से लगभग सब Java compatibility की वजह से हैं। यहाँ इसे शायद अधिक स्पष्ट तरीके से बेहतर हल किया जा सकता था, लेकिन मौजूदा तरीका असफल होने के लिए ही बना लगता है
- अगर open source नहीं है, तो इसका ज़्यादा मतलब नहीं। ज़्यादातर Python developers वैसे भी नहीं आएँगे
- इस नज़रिए से देखें तो यह लगभग Nim programming language को फिर से बनाने जैसा लगता है
इसमें लिखा है, “Mojo को 2026 की शरद ऋतु में open source किया जाएगा”
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
- अच्छा होगा अगर हम किसी वास्तविक cutting-edge MLIR program का source code देख सकें
अफ़सोस की बात है कि इस बीच Nvidia भी चुप नहीं बैठा, और MLIR-आधारित मिलते-जुलते compiler stack के ज़रिए Python के लिए, और जल्द ही C++ के लिए, CuTile नाम का अगली पीढ़ी का CUDA बना लिया
portability न भी हो, तब भी Nvidia के मज़बूत push, dev tools में integration, और मौजूदा CUDA code के साथ काम करने की वजह से इसके Mojo से कहीं ज़्यादा इस्तेमाल होने की संभावना है
संभव है कि Tile IR, Mojo से ज़्यादा Triton के ख़तरे के जवाब के रूप में आया हो। खासकर इस नज़रिए से कि ठीक-ठाक performance वाले LLM kernels कितनी आसानी से लिखे जा सकते हैं
- पीछे न छूटने के लिए Intel और AMD भी इसी तरह की कोशिशें कर रहे हैं, और CPython JIT भी कई प्रयासों के बाद अब आख़िरकार वास्तविकता बन रहा है
  GraalPy और PyPy जैसी कोशिशें भी हैं
  ये सारी कोशिशें अभी Windows पर चलती हैं। जिस माहौल में कंपनी ज़्यादातर कर्मचारियों को Windows मशीन देती है और सिर्फ़ servers पर Linux distro चलता है, वहाँ यह काफ़ी महत्वपूर्ण है
  इससे बार-बार यह सोचने का मन होता है कि कहीं इसका अंत एक और Swift for Tensorflow जैसा न हो जाए
- कुछ Tile IR developers से बात करने पर पता चला कि मुख्य प्रेरणा PTX की तुलना में tensor core programming के लिए बेहतर portability देना था
  customer feedback के अलावा किसी ने यह नहीं कहा कि यह किसी और चीज़ की प्रतिक्रिया थी
- बहुत से लोग Mojo को बस GPU code लिखने के लिए अच्छी syntax समझ लेते हैं, और मान लेते हैं कि Nvidia के Python frameworks पहले से यह काम कर रहे हैं
  लेकिन क्या CuTile AMD GPU या Apple Silicon पर भी चलेगा? Nvidia कुछ भी करे, vendor lock-in तो बना ही रहता है
- CuTile का प्रभाव कितना बड़ा होगा, यह जानने की जिज्ञासा है
जब मैंने पहली बार Mojo के बारे में सुना था, तो लगा था कि इसे मौजूदा Python code के compatible बनाने की कोशिश हो रही है
लेकिन निकट भविष्य में यह उस लक्ष्य से बहुत दूर दिखता है। Python और Mojo के बीच आना-जाना और call करना संभव हो सकता है, लेकिन Mojo खुद मौजूदा Python code नहीं चला सकता
- शुरुआती प्रचार में तो यही साफ़ तौर पर मुख्य बातों में से एक था। बात कुछ ऐसी थी कि Python code में type hints जोड़कर बड़ी speedup मिल सकती है
  लेकिन लगता है कि बनाते-बनाते दिशा बदल गई
- अगर याद सही है तो equivalent Python की तुलना में 36,000x speedup का भी विज्ञापन किया गया था, लेकिन यह बिल्कुल साफ़ नहीं किया गया कि यह सिर्फ़ बहुत extreme edge cases में ही संभव है
  Python ecosystem को बेहतर बनाने की ईमानदार कोशिश से ज़्यादा यह किसी pump-and-dump crypto योजना जैसा लगा
- अगर बहुत ध्यान से देखा जाए, तो शुरू से ही साफ़ था कि विचार अगली पीढ़ी की systems language बनाने का था
  Swift और Rust से सीख लेना, CPU/GPU/heterogeneous targets को निशाना बनाना, और MLIR को केंद्र में रखना इसका आधार था
  साथ ही, इसकी बनावट में यह भी सोचा गया था कि कभी Python को अपेक्षाकृत आसानी से embed या extend किया जा सके, और Python framing ने funding जुटाने में लगभग निश्चित रूप से मदद की होगी
  Chris Lattner ने Python और Mojo के रिश्ते से ज़्यादा MLIR और Mojo के रिश्ते की बात की थी
- शुरुआती विज्ञापन तो ऐसा ही था। यह Python के लिए Kotlin जैसा कुछ बनना चाहता था, लेकिन जल्दी ही दिशा बदल ली
  इसी वजह से और पूरी तरह open source न होने वाले development model की वजह से यह हमेशा कुछ हद तक vaporware जैसा लगा
- साइट पर यह लिखा है
  Python interoperability: “Mojo Python के साथ native interoperability देता है, इसलिए सब कुछ दोबारा लिखे बिना आप मौजूदा code के performance bottlenecks को दूर कर सकते हैं। आप एक function से शुरुआत कर सकते हैं और ज़रूरत के अनुसार performance-critical code को Mojo में ले जाकर इसे बढ़ा सकते हैं। Mojo code को स्वाभाविक रूप से Python में import किया जा सकता है और deployment के लिए साथ package किया जा सकता है। इसी तरह Python ecosystem की libraries को Mojo code में import किया जा सकता है”
Mojo ठीक लग रहा है, लेकिन CPU और GPU दोनों को कवर करने वाले high-performance numerical computing के लिए मैं अभी Julia से काफ़ी संतुष्ट हूँ
Python जैसी syntax को छोड़ दें तो लगता है यह niche काफ़ी हद तक पहले ही सुलझ चुका है। ख़ुद Python में भी Numba और Triton जैसे tools हैं जो कम जटिल और अधिक standalone तरह की समस्याओं पर असरदार हैं
अगर उद्देश्य वही है, तो Julia ज़्यादा mature है, और पिछले साल से Nvidia CUDA में Python tools और C++ tools के बीच feature parity ला रहा है
Python cuTile JIT compiler के साथ आप लगभग pure Python की तरह CUDA kernels लिख सकते हैं
AMD और Intel भी इसी तरह का approach अपना रहे हैं
Mojo समय पर पहुँचकर व्यापक adoption हासिल कर पाएगा या नहीं, यह अभी देखना बाकी है
- यह कहना सही नहीं कि Python cuTile JIT compiler pure Python में CUDA kernels लिखने देता है। अभी भी यह pure Python नहीं है, और आगे भी नहीं हो सकता
  इस तरह की “performance-friendly” Python dialects — जैसे Triton, Pythran, CuTile, Numba, Pycell, cuPy — ऊपर-ऊपर Python जैसी दिखती हैं, लेकिन सतह खुरचते ही साफ़ हो जाता है कि ये Python नहीं हैं
  ये ऐसी Python-जैसी DSLs हैं जिन्हें optimization और type inference बेहतर करने के लिए बनाया गया है। वास्तव में इस्तेमाल करने पर यही महसूस होता है। इनमें से हर एक में Python की कई, शायद ज़्यादातर सुविधाएँ इस्तेमाल नहीं की जा सकतीं, फिर भी Python की मूल समस्याएँ आपको झेलनी पड़ती हैं
  सच कहें तो Python efficiency और performance के लिए मूल रूप से अच्छा नहीं है
  यह बात GIL से कहीं आगे जाती है। dynamic typing, reference semantics, monkey patching, बेहद dynamic object model, CPython ABI, default BigInt, runtime module system जैसी चीज़ें छोटे scripting language के लिए तो ठीक हैं, लेकिन high-performance computing और efficiency के लिए बहुत ख़राब हैं
  NumPy/SciPy ecosystem खुद भी साधारण CPU-bound tensor arithmetic के लिए Python की सीमाओं को bypass करने वाले hacks जैसा है
  Python की मूल performance इतनी ख़राब है कि साधारण for loop भी Excel को racehorse जैसा दिखा देता है
  Mojo अलग है
  Mojo मौजूदा समस्याग्रस्त आधार पर hacks करने के बजाय clean slate से शुरू करना चाहता है
  और 30 साल पुराने Python के बजाय, पिछले language design अनुभवों पर आधारित, अच्छी तरह डिज़ाइन की गई भाषा के साथ “Python-जैसा अनुभव” देना चाहता है
  सिर्फ़ इसी वजह से मैं चाहता हूँ कि यह सफल हो
आजकल लगता है कि कम से कम कुछ लोगों के लिए AI native को सामने रखकर marketing करना ज़रूरी हो गया है
लेकिन मुझे यह थोड़ा खटकता है। क्योंकि यह व्यवहार में लगभग कुछ भी न कहने वाला वाक्यांश लगता है
“यह compiled और statically typed language है, इसलिए agentic programming के लिए भी ideal है” — AI के प्रति उत्साहित लोग क्या समझा सकते हैं कि यह क्यों और किस अर्थ में सही है?
- AI के उभरने के बाद इन उत्पादों और services के landing pages पर दिखने वाली बेचैनी वास्तव में काफ़ी दिलचस्प रही है
  व्यक्तिगत रूप से मुझे सबसे मज़ेदार वह लगा जब मैंने IBM DB2 product page खोला और उस पर AI database लिखा देखा
  शायद इसका मतलब यह है कि compile time पर ज़्यादा errors पकड़ लेने से agents unit tests या दूसरे tests के बिना भी अपने काम को statically जल्दी verify कर सकते हैं
- मौजूदा LLMs को पुराने code की विशाल libraries पर train किया गया है। इसलिए निकट भविष्य में वे नई भाषाओं की तुलना में पहले से स्थापित भाषाओं में बेहतर काम करेंगे
  खासकर Python जैसी भाषाओं में, जहाँ उपलब्ध open source code बहुत ज़्यादा है। जिन नए entrants के पास training के लिए मौजूदा code नहीं है, उनके लिए यह बड़ी समस्या है
  इसलिए “agentic” दुनिया में relevant दिखने के लिए इस तरह की हताश AI native marketing की ज़रूरत पड़ सकती है। यह काफ़ी होगी या नहीं, यह समय बताएगा
- मैं खुद को AI power user नहीं मानता, लेकिन इसका इस्तेमाल करता हूँ
  agents को जितना ज़्यादा feedback मिलता है, वे उतना बेहतर काम करते हैं। type checking बेवकूफ़ी भरी ग़लतियों को अपने-आप काफ़ी हद तक पकड़ लेने में मददगार है
  मूल बात यह है कि agent को जितने अधिक hints मिलें, आम तौर पर उतना बेहतर होता है
- पता नहीं यह किस मतलब में लिखा गया है, और मैं इस बात से सहमत हूँ कि ऐसी programming language के लिए “AI native” कुछ हद तक अर्थहीन अभिव्यक्ति है
  compile और static typing वाली बात पर, agentic programming करते समय compile time पर समस्याएँ पकड़ पाना सच में बहुत मददगार होता है
  इससे runtime पर मिलने वाली दिक्कतें कम हो जाती हैं, और वे हालात भी कम होते हैं जिन्हें agent के लिए हल करना मुश्किल होता है। unit tests कुछ हद तक इस gap को भर सकते हैं, लेकिन पूरी तरह नहीं
  वेबसाइट पर यह नहीं लिखा है कि Mojo, agentic programming के लिए शायद उल्टा खराब विकल्प हो सकता है। क्योंकि अभी Mojo training data बहुत कम है
- यह नया “...on the blockchain” है
  Python+ruff+pycheck और TypeScript machine code में नहीं, bytecode में compile होते हैं। और ये Rust जैसी strict static typing भी नहीं रखते
  फिर भी मैंने models को दोनों में काफ़ी अच्छा valid code बनाते देखा है। सख़्ती से “compiled” या “statically typed” होना ज़रूरी नहीं था
  आख़िरकार AI को बस code को जल्दी verify और iterate करने के लिए अच्छे tools चाहिए, इन गुणों की उसे उतनी परवाह नहीं होती
Modular इस साल के अंत में compiler समेत पूरा Mojo SDK open source करने वाला है
इसमें लिखा है, “Mojo 1.0 इस साल के अंत में finalize होगा, और compiler release तथा language stability भी साथ आएगी”
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
मैं Mojo पर नज़र बनाए हुए हूँ। सच कहूँ तो Python में मुझे सबसे कम पसंद उसकी syntax है
यहाँ किसी और ने Julia का ज़िक्र किया, और मुझे लगता है कि वह एक अच्छी भाषा है। लेकिन compiler error messages और library documentation उस स्तर के नहीं हैं जिसकी ऐसी mature भाषा से उम्मीद की जाती है
पहले पढ़े गए blogs की accuracy को लेकर भी चिंता है। साथ ही binary size और first-run time की वजह से मुझे नहीं लगता कि मैं Julia में वैसा Python module बना पाऊँगा जैसा चाहता हूँ
फिर भी आशा है कि Mojo एक विकल्प बने। लेकिन मुझे REPL पसंद है और Python की dynamic nature भी पसंद है, इसलिए performance के लिए NumPy से बाहर जाना शायद मैं अंततः न करूँ
- मेरे लिए तो उल्टा है। Python में मुझे केवल उसकी syntax ही पसंद है
  इसलिए मुझे Nim बहुत पसंद है। C-level speed, compile-time execution, metaprogramming, शक्तिशाली type system, और memory safety मिलती है, और code भी अक्सर छोटा और elegant रहता है
  Mojo भी दिलचस्प है, लेकिन अभी तक यह general-purpose programming से ज़्यादा machine learning पर केंद्रित लगता है। और जहाँ तक मुझे पता है, compiler अभी open source नहीं है
- मुझे Mojo का design बहुत पसंद है। इसमें deterministic memory management है, इसलिए इसे Julia से तुलना नहीं की जा सकती
  ऐसा भी लगता है कि Mojo का ज़ोर industrial-strength robust language बनने पर ज़्यादा है। Julia की पहली precompilation implementation में file I/O न होना देखकर मैं हैरान रह गया था

Mojo 1.0 बीटा

संस्करण और शुरुआती संसाधन

GPU और Python interoperability

GPU प्रोग्रामिंग

Python interoperability

compile-time metaprogramming

रोडमैप और open source

Phase 0

Phase 1

Phase 2

Phase 3

सीखने और community संसाधन

संबंधित पढ़ाई

1 टिप्पणियां

Hacker News की राय