- language runtime या JIT जैसे वैकल्पिक इम्प्लीमेंटेशन प्रदर्शन में बेहतर होने पर भी canonical implementation के बदलावों और यूज़र की अपेक्षाओं के साथ लगातार तालमेल बनाए रखना पड़ता है, इसलिए उनका अपनाया जाना सीमित हो सकता है
- PyPy, LuaJIT और TruffleRuby ने तेज़ execution performance दिखाई, लेकिन compatibility gap और नए features को track करते रहने का बोझ वास्तविक deployment में बाधा बना
- YJIT ने अलग Ruby implementation बनने के बजाय CRuby के अंदर जाने का रास्ता चुना, जिससे उसे शुरुआत से ही CRuby features के साथ 100% compatibility मिल सके, और इसे Shopify, Discourse, GitHub आदि में deploy किया गया
- Crystal जैसा विकल्प, जो मौजूदा भाषा से बहुत मिलता-जुलता है लेकिन compatible नहीं है, यूज़र्स को बार-बार इस फ़र्क से जूझने पर मजबूर कर सकता है कि यह “लगभग Ruby है, लेकिन Ruby नहीं”
- JSON parser या JavaScript जैसी जगहों पर, जहाँ public standard implementation से अलग मौजूद होता है, वैकल्पिक इम्प्लीमेंटेशन का बोझ कम हो जाता है; लेकिन जिन ecosystem में canonical implementation ही व्यवहारिक standard हो, वहाँ अलग रणनीति चाहिए
बार-बार दोहराया जाने वाला वैकल्पिक इम्प्लीमेंटेशन का जाल
- सॉफ़्टवेयर दुनिया में अक्सर ऐसे प्रोजेक्ट दिखते हैं जो किसी मौजूदा सिस्टम के बेहतर वैकल्पिक इम्प्लीमेंटेशन के रूप में शुरू होते हैं, लेकिन आख़िरकार canonical implementation की छाया में फँस जाते हैं
- वैकल्पिक इम्प्लीमेंटेशन की तुलना उस canonical implementation से की जाती है जिसे features, performance, ecosystem और user expectations के स्तर पर standard जैसा माना जाता है
- अगर canonical implementation लगातार बदलता रहे, तो वैकल्पिक इम्प्लीमेंटेशन अपनी दिशा तय करने के बजाय उन बदलावों का पीछा करने में बहुत ऊर्जा खर्च करता है
- जब किसी पारंपरिक interpreter-आधारित भाषा में JIT implementation जोड़ा जाता है, तो नए features अक्सर interpreter में जल्दी आ जाते हैं, जिससे JIT पर उन्हें track करने का बोझ बढ़ जाता है
PyPy, LuaJIT और TruffleRuby में दिखा पैटर्न
- PyPy, Python के लिए एक उन्नत JIT compiler है जो CPython की तुलना में काफ़ी speedup दे सकता था, लेकिन वास्तविक उपयोग बहुत कम रहा
- Python एक moving target है, जहाँ नियमित रूप से नए CPython versions और features आते रहते हैं
- PyPy को इसका पीछा करने में कठिनाई हुई और वह हमेशा Python के कुछ versions पीछे रह गया
- Python software को PyPy-compatible बनाने के लिए इस्तेमाल किए जा सकने वाले Python features सीमित करने पड़ते थे, और ज़्यादातर Python programmers इस बारे में सोचना नहीं चाहते
- LuaJIT ने मूल interpreter-आधारित Lua implementation की तुलना में बड़ा performance gain दिया, इसलिए उसे काफ़ी सराहना और कुछ वास्तविक adoption मिला
- LuaJIT के निर्माता Mike Pall को बहुत से लोग एक शानदार programmer मानते हैं
- लेकिन Lua भाषा में लगातार नए features जुड़ते रहे और LuaJIT कई versions पीछे रह गया
- इसी वजह से कुछ Lua users, LuaJIT इस्तेमाल करने से हिचकते हैं
- Lua minimalism के लिए जानी जाती है, फिर भी नए features जोड़ने की रफ़्तार कम करने या Mike Pall के साथ तालमेल बैठाने की कोशिश नहीं हुई
- TruffleRuby ने Ruby JITs में सबसे प्रभावशाली performance numbers दिखाए, लेकिन इसकी deployment सीमित रही
- एक व्यावहारिक कारण यह था कि TruffleRuby का warm-up time CRuby की तुलना में काफ़ी लंबा है
- CRuby लगातार features जोड़ता रहा, इसलिए TruffleRuby contributors को उसका पीछा करना पड़ता था
- Ruby users, CRuby को canonical implementation मानते हैं, और जो implementation पूरी तरह compatible न हो उसे वे कम मूल्यवान समझते हैं
YJIT ने जो अलग रास्ता चुना
- YJIT भी एक और Ruby JIT के रूप में शुरू हुआ, लेकिन अलग implementation बनने के बजाय इसे CRuby के भीतर ही बनाया गया
- इस चुनाव से design-level trade-offs ज़रूर आए, लेकिन इससे YJIT शुरुआत से ही CRuby के सभी features के साथ 100% compatible रह सका
- आज YJIT, Ruby का “official” JIT है और Shopify, Discourse, GitHub आदि में deploy किया जा चुका है
- github.com या किसी Shopify store पर जाने वाले users ने वास्तव में YJIT के साथ interaction किया है
- अब तक Ruby JIT compilers में YJIT ने सबसे बड़ी सफलता हासिल की है, और इस सफलता में compatibility की निर्णायक भूमिका रही है
“हरा नहीं सकते तो साथ आ जाओ” भी काफ़ी नहीं
- अगर आप खुद को एक वैकल्पिक इम्प्लीमेंटेशन के रूप में position करते हैं, तो संभावना ज़्यादा है कि आप canonical implementation की छाया में लगातार catch-up game खेलते रहेंगे
- canonical project अगर लगातार evolve करता रहे, तो वैकल्पिक इम्प्लीमेंटेशन के पास अपनी दिशा को लेकर सीमित निर्णय-शक्ति ही बचती है
- canonical implementation में शामिल हो जाना बेहतर नतीजे दे सकता है, लेकिन हर स्थिति का समाधान सिर्फ़ इससे नहीं होता
- Ruby ecosystem का Crystal, Ruby-जैसी syntax वाली एक statically compiled language है जो type inference इस्तेमाल करती है
- Crystal ने जानबूझकर Ruby compatibility को लक्ष्य नहीं बनाया और Ruby से अलग दिशा में गया
- Rubyists के लिए यह “लगभग Ruby, लेकिन पूरी तरह Ruby नहीं” जैसी भाषा लगती है, और वास्तव में इसमें कई सूक्ष्म फ़र्क और incompatibilities हैं
- यह समानता users की expectations को अस्थिर करती है और भ्रम पैदा करती है
- अगर Crystal को शुरू से Ruby-जैसा कहकर market न किया गया होता, तो शायद उसका नतीजा बेहतर होता
प्रतिस्पर्धा से बचना और अपनी दिशा रखना
- Peter Thiel का “competition is for losers” अक्सर इस संदर्भ में इस्तेमाल होता है कि खुद को अनावश्यक प्रतिस्पर्धा वाली स्थिति में नहीं डालना चाहिए
- इससे यह सलाह निकलती है कि अगर नई programming language बनानी हो, तो Python का subset या किसी मौजूदा भाषा के बहुत सतही तौर पर मिलते-जुलते विकल्प बनाने से बचना बेहतर है
- अगर आप अपनी अलग चीज़ बनाते हैं, तो आपको किसी दूसरी implementation के performance, feature set या library ecosystem की बराबरी करने की अपेक्षा से बँधना नहीं पड़ता, और आप अपने सिस्टम को अपनी गति और दिशा में विकसित कर सकते हैं
- यह सलाह उन स्थितियों पर लागू होती है जहाँ किसी भाषा या system की canonical implementation मौजूद हो
- public standard वाले क्षेत्र इसका अपवाद हो सकते हैं
- JSON parser के लिए एक अपेक्षाकृत छोटा, स्पष्ट और बहुत तेज़ी से न बदलने वाला specification होता है, इसलिए उसका स्वतंत्र implementation बनाना संभव है
- JavaScript में कई browser-based implementations मौजूद हैं, और यह इसलिए संभव है क्योंकि JS specification को संभालने वाली एक बाहरी standards body है
- JS standard पर काम करने वाले लोग समझते हैं कि JIT compiler implementations performance के लिए महत्वपूर्ण हैं, और वे भाषा के विकास को उसी हिसाब से आगे बढ़ाते हैं
- वे जितनी जल्दी हो सके उतने नए features जोड़ने वाला खेल नहीं खेल रहे
1 टिप्पणियां
Hacker News की रायें
OP ने एक और अहम बात छोड़ दी है। वैकल्पिक implementation बनाते समय आम तौर पर उसका architecture reference implementation से अलग होता है, और जो काम reference implementation में आसान है, वह आपके implementation में बहुत मुश्किल हो सकता है
उदाहरण के लिए मान लें कि वित्तीय reports के लिए कोई proprietary software दस्तावेज़ों को किसी अजीब binary format में save करता है। एक free alternative बनाते समय आपने ऐसा architecture चुना कि पूरा document memory में पढ़ा जाए और save करते समय पूरी file फिर से लिखी जाए; जबकि मूल software उस दौर में बना था जब RAM कम होती थी, इसलिए वह सिर्फ वही section पढ़ता-लिखता था जिस पर user काम कर रहा हो, और in-place modification भी कर सकता था
बाद में अगर मूल software documents में attachments डालने की सुविधा जोड़ता है, तो investor call recordings या सैकड़ों pages वाले scanned PDF जैसी बड़ी files भी section-wise loading की वजह से ठीक चलती हैं। दूसरी ओर, आपका implementation पूरे document को deserialize करता है, इसलिए जैसे ही document user की RAM से बड़ा होता है, समस्या आ जाती है; और जो बदलाव मूल software में एक developer एक हफ्ते में कर सकता था, उसके लिए आपको पूरे software को redesign करना पड़ सकता है
उल्टा, कुछ features मूल में implement करना ज्यादा कठिन था, लेकिन second implementation में वे मामूली हो गए। बड़ा redesign सिर्फ एक बार हुआ, और वह भी मूल implementation में था, जिसमें ऐसी assumptions थीं जो exponential blow-up पैदा करती थीं
एक सार्वजनिक उदाहरण Linux पर Windows applications चलाने की समस्या है। Linux kernel, NT से पूरी तरह अलग implementation है और compatibility को लक्ष्य भी नहीं बनाता, लेकिन Windows apps चलाने के लिए पूरे kernel redesign की जरूरत नहीं होती। कुछ अपेक्षाकृत सामान्य kernel features और user-space compatibility layer काफी होते हैं। Wine को लिखने और maintain करने में बहुत मेहनत लगती है, लेकिन Windows के अपने implementation से बहुत कम, और यह ऐसे platform पर चलता है जिसे Windows compatibility के लिए बनाया ही नहीं गया था। हालांकि लेख में कहे अनुसार, Windows का लगातार पीछा करना पड़ता है, और reference implementation के bugs पर निर्भर code भी बन जाता है; इसलिए bug-compatible होने के लिए पहले यह पता लगाना पड़ता है कि कौन से bugs implement करने हैं
इसलिए कोई भी code runtime में दूसरी चीज़ों को बदल सकता है। व्यवहार में लोग इसका बहुत ज्यादा उपयोग नहीं करते, लेकिन अगर इसे हटाने की कोशिश करें तो लोग हंगामा कर देते हैं। Python को सचमुच compile करने वाले implementation को उस स्थिति तक संभालनी पड़ती है जहाँ कोई thread अचानक किसी दूसरे thread के नीचे की कोई चीज़ बदल दे
यह उन तरीकों में से एक है जिससे छोटी company बड़ी company का बोझ बढ़ाती है, और ऐसी company भी ऐसा कर सकती है जिसने technical debt को कम अनदेखा किया हो। यह management को technical debt साफ तौर पर दिखाने के दुर्लभ मौकों में से भी एक है, क्योंकि आप कह सकते हैं, “Acme की तुलना में इस feature को implement करने में हमें ज्यादा समय लगेगा”
“Python का subset बनाने की कोशिश न करें” वाली बात से मैं सहमत हूँ। “Python, लेकिन X बेहतर है” के तौर पर market किए जाने वाले projects के लिए reference implementation से compete करना हमेशा मुश्किल होता है, खासकर जब X speed हो। Dynamic typed language इस्तेमाल करने वाले लोग अंततः execution speed की बहुत ज्यादा परवाह नहीं करते
लेकिन alternative implementation हमेशा fail नहीं होते। MicroPython Python 3.4 level से आगे लगभग support नहीं करता, फिर भी काफी सफल लगता है। क्योंकि इसे microcontrollers पर चलने के लिए design किया गया है, इसलिए यह CPython से नहीं बल्कि दूसरे microcontroller programming environments से compete करता है
हालांकि MicroPython maintainers को शायद अधिक नए Python features के requests बहुत मिलते होंगे। एक समय मैंने applications में embed करने के लिए हल्के और embedding-focused Python alternative implementation के बारे में सोचा था; उस मामले में भी मुकाबला CPython से नहीं बल्कि Lua से होना था। लेकिन नंबर 1 feature request था: “क्या यह NumPy support करता है?”
साथ ही CPython side पर भी frontend में बेहतर चलाने का काम हो रहा लगता है, और मुख्य pain point package size है
startup बनाते हुए मैंने भी कुछ ऐसा ही सीखा। अगर फिर से करता, तो अपने क्षेत्र की basic entry-ticket features से actively बचता
इसके बजाय इतना न्यूनतम बनाना चाहिए था जिससे भरोसा मिले कि हमारी architecture enterprise-style requirements को support कर सकती है, और सारी energy उन differentiators पर लगानी चाहिए थी जिनसे प्रतिक्रिया मिले, “अच्छा, समझ आ रहा है यह कहाँ तक जा सकता है।” उन features पर नहीं जिनसे लगे, “यह तो बस X की copy है”
आपकी strategy basic required features implement करने, लेकिन उसके बाद की “common” extensions में ज्यादा गहराई तक न जाने जैसी है। तरीका यह है कि interesting features के कारण लोग फिर संपर्क करें, और साथ ही इतना basic functionality हो कि जरूरी elements न होने से आप reject न हो जाएँ
सभी wrapper code के बारे में कुछ ऐसा ही महसूस होता है। कभी-कभी कोई कहता है, “इस API का internal-use version चाहिए”
वजहें अलग-अलग हो सकती हैं, लेकिन अक्सर बात कुछ ऐसी होती है कि “भरोसा नहीं किया जा सकता कि लोग official API को ठीक से इस्तेमाल करेंगे।” ऐसा हो सकता है, लेकिन internal version कम standard होता है और उसकी documentation भी खराब होती है
कभी-कभी वजह “extra functionality चाहिए” होती है, तो ऐसे में पूरे API को wrap करने के बजाय बस 3 functions जोड़ देने चाहिए। समय बीतने पर codebase का 99% polyfill बन सकता है
मूल बात यह है कि अगर आप defaults इस्तेमाल नहीं करते, तो बाद में codebase संभालने वाले व्यक्ति के लिए यह बड़ी तकलीफ बन जाता है
उदाहरण के लिए Zig में Python native modules लिखने वाली ziggy-pydust library सामान्य Python.h import की तुलना में साफ तौर पर बेहतर दिखती है। फिर भी इसमें
.ffiभी है, जिससे उन functions तक सीधे पहुंच मिलती है जो अभी implement नहीं हुए हैं लेकिन Python.h में मौजूद हैंअगर ऐसा विकल्प न हो, तो आम तौर पर ऐसी library छोड़कर original को prefer करने का मन होता है। हालांकि यह भी एक अर्थ में wrapper ही है, यानी native module, और development speed के लिए कभी-कभी सीधे ctypes इस्तेमाल करना बेहतर हो सकता है
अच्छा लेख है और इसमें कई शानदार सीखें हैं, लेकिन एक मुख्य ingredient गायब है। यह किसी product के competitive alternative जैसा ही है
यह कुछ ऐसा कहने जैसा है कि Amazon इसलिए fail हुआ क्योंकि उसके पास लोगों की आदत वाली offline bookstores नहीं थीं, जबकि असल में ऐसा नहीं हुआ
इन JIT alternatives के fail होने और लगातार catch-up करते रहने की वजह यह है कि practical तौर पर X language developers में से ज्यादातर JIT को इतना महत्वपूर्ण नहीं मानते। ज्यादा सही कहें तो वे language features और interoperability को JIT से ज्यादा महत्वपूर्ण मानते हैं
इसलिए compete करने के बजाय “join” करने वाला product जीतता है। वजह यह है कि वे अधिक stability या interoperability नहीं दे पाते
मैं लंबे समय से languages और compilers के साथ काम करता आया हूं, और यह लेख बहुत दिलचस्प लगा। इसी विचार को दूसरे ढंग से कहें तो language, सिर्फ compile speed से कहीं ज्यादा चीजों का नाम है
compile speed बहुत महत्वपूर्ण है, और निश्चित रूप से top 10 dimensions में आती है। खासकर compile speed बढ़ाने से developer feedback loop तेज होता है, और core team बाकी सभी dimensions को भी तेजी से improve कर सकती है
फिर भी programming languages में 30 से ज्यादा और भी बेहद महत्वपूर्ण dimensions होते हैं
ऐसे projects कैसे सफल हो सकते हैं, इस पर conclusion अच्छा है, लेकिन कई projects क्यों traction नहीं पा पाते, इस बारे में एक factor अभी भी कम चर्चा में है। alternative implementations की compatibility अक्सर दावे से कम होती है, और पुराने language features में भी ऐसा ही होता है
उदाहरण के लिए Ruby और Python apps में dependencies के किसी न किसी हिस्से में native C extension होना बहुत आम है, और जहां तक मुझे पता है, major alternative implementations ने इन्हें कभी support नहीं किया। कोशिशें हुई हैं, लेकिन साफ technical reasons की वजह से सफल नहीं रहीं, और libraries से multiple implementations देने की उम्मीद रखने वाले alternative का इतिहास भी आसान नहीं रहा
इसके साथ यह तथ्य जोड़ दें कि ये languages अक्सर CRUD websites में इस्तेमाल होती हैं, जहां performance factor में CPU से ज्यादा I/O मायने रखता है, तो तेज alternative की appeal काफी घट जाती है
सचमुच शानदार लेख है। technology की sociology बहुत रोचक है
language implementation maintainers users के लिए उपयोगी नए features design और ship करते समय अधिकतम flexibility चाहते हैं। वे नहीं चाहते कि feature release करने से पहले कई implementations की सहमति लेनी पड़े और वे अटक जाएं। उदाहरण के तौर पर देखें कि JavaScript का evolution कई सालों तक कितना हिमनद जैसा धीमा लगा, और TypeScript उसके मुकाबले कितनी तेजी से evolve होता है
साथ ही alternative implementation इस बात का संकेत भी हो सकता है कि language ecosystem मजबूत है, इसलिए इसके फायदे भी हैं। अगर alternative implementation वाकई अच्छा है, तो भले ही वह कुछ niche जरूरतों वाले users के लिए ही अच्छा हो, ecosystem में वास्तविक value जोड़ सकता है
इसलिए अगर आप language designer या maintainer हैं, तो आप alternative implementations के प्रति सक्रिय रूप से hostile शायद नहीं होंगे, लेकिन इनके downsides हैं। आम तौर पर users का feedback नए features release करने और language को आगे बढ़ाने की दिशा में आएगा। PyPy, IronRuby, LuaJIT आदि को catch up करने देने के लिए गति धीमी करने की मांग ज्यादा नहीं होगी
जब language consumers यह चुनते हैं कि किस implementation पर build करना है, तो उनकी सबसे बड़ी priority आम तौर पर safety और stability होती है। कोई नहीं चाहता कि उसका million-line codebase किसी ऐसे alternative implementation के subtle behavior traits पर निर्भर हो जाए, जिसे कभी किसी बहुत smart PhD student ने बनाया था लेकिन अब वह दूसरे project पर चला गया है। इसलिए users सबसे ज्यादा इस्तेमाल होने वाले implementation की ओर इकट्ठा होते हैं, और यही तथ्य फिर दूसरे users को आकर्षित करता है, जिससे मजबूत positive feedback loop बनता है
नतीजतन, अगर उल्टी दिशा में धकेलने वाली कोई मजबूत ताकत न हो, तो ज्यादातर languages एक reference implementation पर converge हो जाती हैं। यह भी तर्क दिया जा सकता है कि यह अच्छी बात है, क्योंकि language implementation में लगने वाली लगभग सारी engineering effort कई implementations में बंटने के बजाय सभी users को फायदा देती है। हालांकि downside यह है कि implementation local optimum में फंस सकता है
LuaJIT का जिक्र हुआ है, लेकिन यह इस बात का उदाहरण भी है कि चीजें हमेशा लेख के conclusion जैसी नहीं होतीं। कई लोगों और projects ने LuaJIT को Lua के बजाय जानबूझकर चुना
luajittexexecutable भीluatexके साथ-साथ आसानी से मिल जाता हैशायद यह कम लोकप्रिय विचार हो, लेकिन लोगों को, खुद को भी शामिल करते हुए, कभी-कभी अपने अहम की जांच करनी चाहिए। मौजूदा open source project में योगदान देने की तुलना में “मेरा अपना” समानांतर project बनाना आसान हो सकता है, लेकिन यह पूछना चाहिए कि यह किसके लिए किया जा रहा है
क्या यह project maintainers के लिए है, खुद project के लिए, users के लिए, या अपने अहम के लिए। अगर आखिरी बात पर गुस्सा आता है, तो शायद उसका संबंध हो सकता है
किसी मौजूदा language में JIT जोड़ना बड़ा काम है, इसलिए reference implementation द्वारा स्वीकार करने के मानक भी ऊंचे होंगे। फिर भी मुझे लगता है कि लक्ष्य वही होना चाहिए। fork करना या नया बनाना भी बड़ा काम करने की आज़ादी देता है, लेकिन अक्सर उसे अस्थायी मानना चाहिए
अगर लक्ष्य यह दिखाना है कि मैं क्या कर सकता हूं, तो संभव है कि बात बहुत आगे न जाए। अगर लक्ष्य कुछ बेहतर बनाना है, तो आप दूसरों की constraints के भीतर काम करना सीखते हैं
मुझे लगता है यह लेख दिखाता है कि Python, Lua, Ruby ने ऐसा approach अपनाकर कई लोगों को कैसे निराश किया। नतीजतन हजारों developers और लाखों users को धीमे development और software को सहना पड़ा। इसलिए नहीं कि यह असंभव है, बल्कि इसलिए कि प्रशासनिक रूप से ऐसा करने का incentive नहीं है