- Chris Lattner LLVM और Swift भाषा के प्रमुख डेवलपर हैं, और आधुनिक ML hardware की performance का अधिकतम उपयोग करने के लिए नई भाषा Mojo विकसित कर रहे हैं
- Mojo का लक्ष्य ऐसी भाषा डिज़ाइन करना है जो usability और hardware के fine-grained control, दोनों दे सके, और type-safe metaprogramming के जरिए hardware की बारीकियों को कुशलता से संभालने में मदद करे
- GPU, TPU, ASIC जैसे AI accelerator ecosystem के fragmentation की समस्या को हल करना, और किसी खास vendor पर निर्भरता घटाने के लिए unified computing platform बनाना इसका मुख्य बैकग्राउंड है
- मौजूदा GPU software stack (CUDA, ROCm, XLA आदि) की compatibility और complexity की समस्याओं के कारण अगली पीढ़ी की high-performance और portable language विकसित करना ज़रूरी है
- Modular Mojo को मुफ़्त में उपलब्ध करा रहा है, और unified hardware support तथा enterprise services जैसी व्यावहारिक समस्याओं के समाधान पर केंद्रित business model आगे बढ़ा रहा है
Chris Lattner का परिचय और करियर
- Chris Lattner के पास LLVM, Clang, MLIR, Swift, Mojo जैसे computing क्षेत्र के कई प्रमुख प्रोजेक्ट्स का नेतृत्व करने का अनुभव है
- Apple, Tesla, Google, SiFive, Modular जैसी विभिन्न संस्थाओं में काम करते हुए उन्होंने compiler और programming language design में व्यापक व्यावहारिक अनुभव हासिल किया
- शुरुआती दौर में उन्होंने BASIC जैसी सरल भाषाओं और PC environment से शुरुआत की, और गेम्स/graphics के जरिए hardware performance को अधिकतम करने में रुचि विकसित की
- विश्वविद्यालय के समय संयोग से compiler में विशेषज्ञ एक प्रोफ़ेसर के प्रभाव से उन्हें systems और large-scale software architecture की आकर्षक दुनिया का अनुभव हुआ
कंपाइलर और भाषा डिज़ाइन के बीच आवाजाही
- Chris Lattner ने compiler engineering और language design दोनों में काम किया, और इन दोनों क्षेत्रों के संगम पर बड़ी उपलब्धियाँ हासिल कीं
- उदाहरण के लिए LLVM एक intermediate representation है जिसे कई भाषाएँ इस्तेमाल कर सकती हैं; यह सिर्फ C++ implementation तक सीमित नहीं रहा बल्कि Rust, Julia आदि में भी व्यापक रूप से अपनाया गया
- Swift का विकास भी मौजूदा C++ implementation की सीमाओं और थकान को पार करने की कोशिश से शुरू हुआ, और pattern matching जैसे practical features की ज़रूरत को महत्व दिया गया
- programming language innovation में वे गणितीय सिद्धांत से अधिक वास्तविक समस्या-समाधान और utility पर आधारित डिज़ाइन दृष्टिकोण को प्राथमिकता देते हैं
प्रोग्रामिंग भाषा सिद्धांत और व्यावहारिकता
- Chris गणितीय कठोरता से अधिक problem-solving centered सोच को महत्व देते हैं, और PL papers में सिद्धांत से ज़्यादा practical examples और use cases में रुचि रखते हैं
- वे मानते हैं कि मजबूत mathematical foundations वाली language features में consistency और composability के फायदे होते हैं, लेकिन वास्तविक adoption का प्रमुख कारण उपयोग में दिखने वाला लाभ होता है
- उनका कहना है कि नई भाषा या तकनीक बनाते समय complexity के "grain of sand" को यथासंभव कम करना चाहिए ताकि डिज़ाइन सरल और scalable बन सके
AI hardware ecosystem की संरचनात्मक समस्याएँ
- पारंपरिक compiler infrastructure (LLVM) CPU-केंद्रित था, लेकिन AI/machine learning में GPU, TPU, ASIC, FPGA जैसे विविध specialized hardware की ज़रूरत होती है
- हर vendor अपना विशिष्ट software stack (CUDA, ROCm, XLA आदि) बनाता है, जिससे compatibility की कमी और ecosystem fragmentation पैदा होता है
- ML software (जैसे PyTorch आदि) को हर hardware vendor के लिए अलग optimization चाहिए, जिससे maintenance और expansion बहुत कठिन हो जाते हैं
- हर hardware का stack, language और tool ecosystem अलग होने से software developers की productivity और portability पर गंभीर असर पड़ता है
Modular और Mojo की भूमिका
- Modular टीम इन समस्याओं को हल करने के लिए general-purpose और unified software platform बनाने पर केंद्रित है
- Mojo को modern GPU architecture (tensor cores आदि) की performance specialization के साथ-साथ कई तरह के hardware के लिए portable kernels लिखने के लक्ष्य से डिज़ाइन किया गया है
- Mojo, MAX (high-performance LLM serving आदि), Mammoth (cluster/Kubernetes management) जैसी multi-layered structure के जरिए एकीकृत AI infrastructure उपलब्ध कराया जाता है
Mojo की ज़रूरत और भाषा डिज़ाइन के फ़ैसले
- मौजूदा भाषाएँ high-performance ML kernels की portability और vendor optimization — इन दोनों ज़रूरतों को एक साथ पूरा नहीं कर पातीं
- Mojo को hardware की आंतरिक संरचना, जैसे अलग-अलग data types (8-bit floating point आदि) और tensor cores जैसी तेज़ी से बदलती hardware क्षमताओं के प्रति dynamic response देने में सक्षम होना चाहिए
- type safety सुनिश्चित करने वाला metaprogramming model जटिल hardware control को अधिक कुशल और साझा किए जा सकने वाले रूप में बदलता है
hardware और kernel design में बदलाव
- आधुनिक datacenter के CPU कई cores तक फैल चुके हैं, जबकि GPU ने SM (Streaming Multiprocessor) संरचना, Warp (32 threads का संचालन) जैसी parallel processing optimized design के साथ तेज़ विकास किया है
- tensor cores जैसे AI-विशेष compute units hardware में आने से पारंपरिक CUDA से अलग एक नई hardware programming paradigm की ज़रूरत पैदा हुई
- एक ही vendor के भीतर भी architecture generation के अनुसार compatibility में लगातार बदलाव आते रहते हैं (जैसे Nvidia Volta/Hopper/Blackwell), और software stack उनका साथ नहीं दे पाता
business model और open ecosystem strategy
- Modular भाषा को बेचने पर ध्यान नहीं देता, बल्कि Mojo को मुफ़्त में उपलब्ध कराता है
- इसका मुख्य revenue model integrated hardware management और enterprise ग्राहकों के लिए platform/services उपलब्ध कराने पर आधारित है
- इसके जरिए vendor lock-in के बिना shared ecosystem बनाने की चुनौती ली जा रही है, साथ ही विविध hardware support और कुशल infrastructure management दोनों को साधने की कोशिश की जा रही है
निष्कर्ष
- Chris Lattner और Modular का Mojo प्रोजेक्ट machine learning की उन्नति, AI hardware innovation और ecosystem fragmentation को पार करने के लिए नई programming language और platform बनाने का महत्वपूर्ण प्रयास है
- innovative language design और open ecosystem के विस्तार के जरिए यह AI ecosystem के democratization और productivity बढ़ाने में योगदान देने की रणनीति है
1 टिप्पणियां
Hacker News राय
Mojo और पॉडकास्ट में दिलचस्पी लेने वाले सभी लोगों का धन्यवाद कहना चाहता हूँ। अगर आप Mojo के बारे में और जानना चाहते हैं, तो FAQ में अक्सर पूछे जाने वाले सवाल देख सकते हैं (इसमें ‘Julia को ही बेहतर क्यों नहीं बनाया?’ का जवाब भी है)। दस्तावेज़ भी यहाँ उपलब्ध हैं, और open source code भी कई लाख लाइनों के पैमाने पर सार्वजनिक है। Mojo community भी वास्तव में शानदार है, इसलिए Discourse forum या Discord chat में ज़रूर जुड़ें — यह Chris Lattner की टिप्पणी है
मैं प्रशंसक हूँ। मैंने Mojo पर कई प्रस्तुतियाँ देखी हैं, और हालाँकि कहा जाता है कि Mojo अत्याधुनिक compiler तकनीक का उपयोग करता है, लेकिन मैंने इसके ठोस उदाहरण कभी नहीं सुने। मैं compiler developer नहीं हूँ, फिर भी अगर 20% ही समझ पाऊँ तो भी उस उन्नत तकनीक की असली झलक देखना चाहूँगा, इसलिए कृपया एक बहुत गहरी और तकनीकी blog post लिखें
FAQ में "क्या Mojo Playground अभी भी उपलब्ध है?" पूछने पर उसी playground की ओर भेजा गया, लेकिन वहाँ जाकर बताया जाता है कि 'अगले 25.6 release में Playground हटा दिया जाएगा'। 'क्या यह उपलब्ध है' वाले FAQ का जवाब ऐसे फीचर की ओर भेजना जो जल्द हटने वाला है, मुद्दे से चूकता हुआ लगता है। असल जवाब शायद यह है कि 'ज़्यादा समय तक उपलब्ध नहीं रहेगा'
Chris, यहाँ आपसे मिलकर अच्छा लगा। मैंने पहले Light Table के ज़रिए निवेश भी किया था, तो जानना चाहता हूँ कि कोई update है क्या। (मैं यह पूरी गंभीरता से नहीं पूछ रहा, और Mojo वाकई काफ़ी अच्छा दिखता है।) लेकिन ऐसे प्रोजेक्ट की लंबी अवधि की स्थिरता कैसी है, और भरोसा करने लायक आधार क्या है, यह जानना चाहता हूँ
Python का ML क्षेत्र में प्रभुत्व इसलिए है क्योंकि आधुनिक ML application सिर्फ़ computation scripts नहीं हैं, बल्कि उन्हें व्यापक functionality और मज़बूत ecosystem चाहिए। तरह-तरह की data preprocessing (ETL), अलग-अलग format के data का handling, high-performance computing cluster पर distributed processing, visualization और GUI/DB integration — इन सबको एक साथ समेटने वाली भाषा Python के अलावा नहीं है। numerical computation के लिए NumPy, PyTorch, JAX आदि अंदर ही अंदर C/C++/FORTRAN का उपयोग करते हैं, इसलिए वे बहुत तेज़ हैं, और performance-critical code को अलग से C/C++ में implement करना भी आसान है। Python का C/C++ FFI system भी दूसरी भाषाओं की तुलना में काफ़ी व्यावहारिक है। दूसरी भाषाओं (जैसे Julia) में पूरे ecosystem को फिर से बनाने की तुलना में यह कहीं ज़्यादा फायदेमंद है
Python ecosystem का कोई मुकाबला नहीं, लेकिन Elixir/Nx संयोजन भी Mojo के वादों का बड़ा हिस्सा पहले से पूरा कर रहा है। EXLA के ज़रिए GPU/TPU compilation संभव है, Explorer/Polars से dataframe काम हो सकता है, और Pythonx से Python libraries embed भी की जा सकती हैं। फ़र्क यह है कि Elixir शुरू से distributed systems बनाने के लिए बना था, इसलिए BEAM/OTP विशाल concurrent requests और GPU nodes के बीच coordination भी संभाल सकता है। अगर आप वास्तविक ML service बना रहे हैं, तो Phoenix, LiveView और Nx के साथ एक मज़बूत stack से अत्यधिक fault tolerance और scalability पाना, मामूली hardware performance से ज़्यादा महत्वपूर्ण हो सकता है
inference के मामले में मेरा थोड़ा अलग दृष्टिकोण है। CUDA kernels को सीधे छेड़कर बनाना आसान है, और नया CUTLASS 3 या आधुनिक C++ अब बहुत सुविधाजनक हो गया है। उसके ऊपर Torch एक पतली layer की तरह बैठा है, लेकिन यही हिस्सा build करना मुश्किल बनाता है और reference counting जैसी कई समस्याओं के कारण जटिलता बढ़ाता है। असली core implementation नीचे के kernels में है, इसलिए मैं जल्द ही इस ‘torch cover’ हिस्से को हटाकर इसे साफ़ C++ program से स्पष्ट रूप से जोड़कर इस्तेमाल करने की सोच रहा हूँ
यह चिंता GPU kernels को लेकर है, लेकिन ऐसे kernels वैसे भी Python में नहीं लिखे जाते। Python, ML के लिए एक ‘glue’ language है। “सिर्फ़ Python ही सब कुछ देता है” इस दावे से मैं सहमत हूँ, लेकिन यह थोड़ा अफ़सोसजनक है कि ecosystem किसी बेहतर भाषा के बजाय Python के इर्द-गिर्द बढ़ा
Python का ML की प्रतिनिधि भाषा बनना एक ‘virtuous cycle’ है। ecosystem बड़ा इसलिए हुआ क्योंकि उसे पहले ही चुन लिया गया था, लेकिन शुरू में उसे क्यों चुना गया, इसके लिए अलग व्याख्या चाहिए। आज यह इतना बड़ा हो चुका है कि इसे पार करना असंभव-सा लगता है, लेकिन यह बताने के लिए कि शुरुआत से ही Python क्यों था, यह तर्क काफ़ी नहीं है
विडंबना यह है कि Python उन सभी कामों के लिए सबसे खराब भाषा है जिनका आपने ज़िक्र किया। packaging और binaries (wheel) दोनों पीड़ादायक हैं, और हमेशा कुछ-न-कुछ टूटता रहता है। अकेली scripts के लिए यह ठीक है, लेकिन अगर Python को ML की मुख्य भाषा बनाने के इरादे से डिज़ाइन किया गया होता, तो कोई भी यह रूप नहीं चाहता
एपिसोड सुनकर मैं चौंक गया। 2025 के सितंबर तक भी class support को mid-term goal कहा जा रहा है, यह हैरान करने वाला था। पहले Mojo को ‘Python का strict superset’ कहकर बहुत प्रचारित किया गया था, लेकिन मौजूदा प्रगति की रफ़्तार देखकर यह सिर्फ़ एक आदर्श लक्ष्य जैसा लगता है
वास्तव में ‘Python superset’ कभी लक्ष्य था ही नहीं। यह लोगों का ध्यान खींचने के लिए एक slogan भर था, जिसे शुरुआती दौर में ज़ोर से कहा गया और फिर चुपचाप पीछे कर दिया गया
शायद वजह speed नहीं, बल्कि यह है कि उन्हें OOP खुद पसंद नहीं है
यह हमेशा से long-term goal था
शायद यह थोड़ा घिसा-पिटा सवाल हो, लेकिन मैं जानना चाहता हूँ कि Lisp क्यों नहीं। अगर मान लें कि भविष्य का ML code अंततः machines (या natural language आधारित automatic transformation systems) द्वारा लिखा जाएगा, तो Lisp S-Expressions लगभग AST के बराबर हैं, इसलिए यह मशीनों के लिए सबसे स्वाभाविक भाषा है। REPL environment भी आमतौर पर पूरा होता है, इसलिए Python replacement के रूप में भी यह काफ़ी उपयुक्त लगता है
Yann LeCun आदि ने Lush नाम का ML के लिए Lisp बनाया था। 2000 के दशक में वह बेहतरीन था, और Python (Theano) या Lua (Torch) आने से पहले उसका कोई विकल्प नहीं था। आज भी इच्छा है कि Lisp फिर से ध्यान पाए। Python की libraries शानदार हैं, लेकिन भाषा खुद अभी भी कई जगह सुधार चाहती है
LLM (large language models) अभी भी parentheses गिनने में कमज़ोर हैं ;)
पिछली AI boom के समय Lisp के नज़रअंदाज़ होने का अनुभव रहा है, इसलिए बहुत-से developers आज भी सिर्फ़ Emacs + SBCL का उपयोग करते हैं। जबकि वास्तव में LispWorks, Allegro, Clozure जैसे दूसरे उन्नत Lisp implementations भी हैं, लेकिन बहुत लोगों ने उन्हें आज़माया नहीं है
Mojo का license शुरू से ही मुझे पसंद नहीं है
मैंने भी देखा, और Mojo license में कहा गया है कि CPU या Nvidia उपयोग तथा अन्य ‘accelerators’ (TPU, AMD आदि) के बीच फ़र्क किया गया है, और commercial use के लिए अलग license चाहिए blog देखें
मेरी नज़र में अगर कोई भाषा (Mojo) पूरी तरह किसी एक कंपनी के नियंत्रण में है, तो उसे business में अपनाने का कोई कारण नहीं है। Java license बदलाव के समय कई कंपनियों को समस्याएँ झेलनी पड़ी थीं। Python की जगह Mojo पर business खड़ा करना बहुत ज़्यादा जोखिम भरा है
Mojo FAQ को देखें तो सख़्त अर्थ में वह Python superset होने का लक्ष्य बताता है, लेकिन roadmap में लिखा है कि “यह Python code और familiarity देगा, पर पूर्ण superset नहीं हो सकता”, जिससे उलझन और बढ़ती है। अगर Python compatibility लक्ष्य नहीं है, तो बार-बार Python का ज़िक्र क्यों किया जा रहा है, समझ नहीं आता। और यह भी जानना है कि file extension में emoji इस्तेमाल करने की बात सच है या नहीं
जहाँ तक मुझे पता है, Mojo सिर्फ़ Python-style syntax और Python के साथ interoperability चाहता है। उससे ज़्यादा Python-जैसा होने का दावा ज़्यादातर marketing है
emoji extension वाली बात के बारे में, हाँ, यह सही है। U+2615 (coffee emoji)
मैं जानना चाहता हूँ कि Mojo, Julia से बेहतर किस मायने में है। Julia में interface या ecosystem की सीमाएँ हो सकती हैं, लेकिन Python के साथ उसका integration भी काफ़ी अच्छा है, इसलिए Mojo मुझे विशेष रूप से बेहतर नहीं लगता
खासकर Julia में JuliaGPU, Reactant जैसी अच्छी GPU ecosystem मौजूद है Reactant.jl देखें
Python compatibility में Mojo थोड़ा बेहतर हो सकता है, लेकिन वास्तव में PythonCall.jl के माध्यम से Julia में भी Python libraries को काफ़ी स्थिरता से बुलाया जा सकता है। ML frameworks (Lux.jl, Flux.jl) भी Julia के भीतर अच्छे से चलते हैं। Mojo में अभी वैसी native ML framework परिपक्वता नहीं दिखती
Mojo शायद कहीं ज़्यादा low-level भाषा जैसा एहसास, अधिक control, और robustness को लक्ष्य बना रहा है। Julia semantics या performance के लिहाज़ से predictability कम देता है, इसलिए core software foundation के रूप में कम उपयुक्त है, जबकि Mojo उस मामले में बेहतर हो सकता है
मैंने Python modules को Julia में बनाने की कोशिश की, लेकिन लगा कि समर्थन अभी अपर्याप्त है। Mojo में यह हिस्सा मुख्य feature है
Julia code को पूरी तरह native binary में (लगभग Rust या C++ की तरह) compile करने की क्षमता अभी भी सीमित है
मुझे लगता है कि Mojo को बहुत बड़ा ध्यान न मिलना और PyTorch का उपयोग जारी रहना इस बात का संकेत हो सकता है कि license issue वास्तव में अपेक्षा से बड़ा है
Mojo शायद अपने क्षेत्र को लेकर बहुत आशावादी रहा है। Julia का वास्तविक commercial उपयोग भी धीरे-धीरे बढ़ रहा है और GPU support भी अच्छा है। भले Python का JIT compiler कमज़ोर हो, Nvidia, Intel आदि Python DSL के माध्यम से GPGPU programming को काफ़ी optimize कर रहे हैं, इसलिए Python के भीतर भी C++-स्तर के काफ़ी करीब पहुँचा जा सकता है। अंततः Mojo की अलग पहचान कमज़ोर लगती है
systems नज़रिए से देखें तो Chris और उनकी team का Mojo के माध्यम से multi-language FFI समस्याओं को पूरी तरह बेहतर बनाने का प्रयास प्रभावशाली है। लेकिन open source होने से पहले न निवेश पर चर्चा शुरू की जा सकती है और न adoption पर
यह अभी general-purpose programming language के रूप में इस्तेमाल के लिए तैयार नहीं है। Modular ने भी MAX engine पर Mojo API लागू करने की कोशिश की थी, लेकिन भाषा इतनी तेज़ी से बदल रही थी कि निवेश छोड़ दिया गया। roadmap के अनुसार phase 1 पूरा होने के बाद ही गंभीर adoption की उम्मीद है
मुझे नहीं पता कि इसे वास्तव में सार्वजनिक कहा जा सकता है या नहीं। हाल तक open source न होने के कारण commercial proprietary software पर निर्भर होना मुझे असहज लगा
लेख की शुरुआत में कहा गया है कि ‘state-of-the-art kernels’ इस्तेमाल किए जा सकते हैं। अंततः लगता है कि Mojo kernel development में C++ से प्रतिस्पर्धा करना चाहता है। PyTorch या Julia में आम तौर पर kernels सीधे नहीं लिखे जाते, बल्कि ज़्यादातर high-level coding की जाती है
Chris Lattner के साथ Lex Fridman पॉडकास्ट के कुछ एपिसोड मौजूद हैं:
Mojo का प्रयास अपने आप में साहसिक और दिलचस्प है, लेकिन अगर यह Matlab जैसी बंद भाषा है, तो मेरे ही नहीं बल्कि बहुत-से लोगों के लिए यह गंभीर आपत्ति का कारण है