रूबिरसिया सम्मेलन के अध्यक्ष गॉडफ्रे चान के साथ साक्षात्कार

सभी को नमस्कार! 6 अक्टूबर को मॉस्को रूबिरसिया सम्मेलन की मेजबानी करेगा - अच्छे पुराने रेल्सक्लब, लेकिन एक नए नाम के साथ। इस साल के वक्ता: आरोन पैटरसन, चार्ल्स नट्टर, गॉडफ्रे चान, मैकियज मेन्सफेल्ड, मार्कस शिरप और बहुत कुछ। और निश्चित रूप से, 600 प्रतिभागियों, लॉबी में खड़ा है और पार्टी के बाद आग के साथ सबसे अच्छी कंपनियों।

परंपरागत रूप से, सम्मेलन से पहले, हम रूबी और रेल में सबसे अधिक प्रासंगिक विषयों के बारे में बात करते हैं। आज हम आपको गॉडफ्रे चैन से मिलवाते हैं - टिल्ड में काम करने वाली एक पूर्व-रेल कोर टीम, जहाँ वह स्मार्ट रेल्स प्रोफाइलर स्काईलाइट बनाने, Ember.js पर काम करने और TC39 पर जावास्क्रिप्ट विकसित करने के बीच फटी हुई है। एवरोन दिमित्री माटेव से टिम लीडर ने हमारे अतिथि से महत्वपूर्ण सवाल पूछे।




रूबिरसुइया पर अपनी रिपोर्ट के बारे में कुछ प्रश्नों के साथ शुरू करते हैं?

मैं सभी रहस्यों को उजागर नहीं करना चाहता हूं! मेरी रिपोर्ट को "धातु के नीचे गिरना" कहा जाता है। मैं जावास्क्रिप्ट के समान कुछ बनाने के लिए मेटाप्रोग्रामिंग का उपयोग करते हुए अजीब रब कोड लिखने के बारे में बात करूँगा। बेशक, हम पूर्ण रूप से जावास्क्रिप्ट पार्सर और रनटाइम लिखने में सक्षम नहीं होंगे, लेकिन मैं कुछ जादू दिखाऊंगा जो कि रूबी में मूल रूबी रनटाइम का उपयोग करके जावास्क्रिप्ट जैसे कोड को निष्पादित करेगा। यह मजेदार है, कम से कम मुझे वास्तव में यह पसंद है। यह वही तकनीक है जिसके साथ आप रूबी में rspec, rake, या अन्य DSLs जैसी चीजें लिख सकते हैं। मैं छात्रों को दिखाऊंगा कि रूबी कैसे अपना कोड चलाती है और किस हुक का उपयोग करती है। मुझे लगता है कि रिपोर्ट न केवल मजेदार होगी, बल्कि रूबी में मेटाप्रोग्रामिंग के बारे में कुछ उपयोगी बातें भी सिखाएगी।

कूल! यही है, व्यावहारिक सुझाव होंगे, है ना?

मुझे यकीन नहीं है कि उन पर ध्यान केंद्रित करना संभव होगा, लेकिन मुझे विश्वास है कि इन 30 मिनटों से आप अपने लिए कुछ उपयोगी सीखेंगे।

बहुत बढ़िया! मुझे लगता है कि रिपोर्ट अनुभवी प्रोग्रामर और शुरुआती दोनों के लिए दिलचस्प होगी। सच?

मुझे उम्मीद है। कम से कम मैं कोशिश करूंगा।

वैसे, कल मैंने आपके लेख को कंप्यूटर विज्ञान में शिक्षा की पुनर्विचार पर माध्यम पर पढ़ा। लेख बहुत दिलचस्प है, और मैं प्रोग्रामर के लिए शास्त्रीय विश्वविद्यालय शिक्षा और आधुनिक पाठ्यक्रमों के बीच अंतर पर विचारों से सहमत हूं। वैसे, आपने प्रोग्रामर बनने का फैसला क्यों किया?

बस एक लकीर, मैंने कभी प्रोग्रामर के रूप में काम करने की योजना नहीं बनाई थी, मेरे लिए यह थोड़ा शौक था। मुझे वास्तव में कंप्यूटर के साथ खिलवाड़ करना पसंद था, ऐसा करने के लिए कुछ करना आसान था - गलती से सिस्टम फ़ाइलों को हटा दें या विंडोज रजिस्ट्री में गहरी खुदाई करें। तब मुझे कुछ और चाहिए था। स्कूल के बाद, मैंने वेबसाइट विकास पर पाठ्यक्रम लेना शुरू किया। मुझे कंप्यूटर पर कुछ नया बनाने का अवसर मिला। लेकिन जल्द ही मैंने महसूस किया कि यह मेरे लिए पर्याप्त नहीं था। मैं HTML में कुछ प्रकार के कंप्यूटर गेम बना सकता था, लेकिन यह टूलकिट काफी सीमित था। एक दिन, मेरे शिक्षक ने मुझे PHP पर एक किताब दी। मैंने यह सब पढ़ा और अप्रत्याशित रूप से अपने लिए, संभावनाओं की एक पूरी नई दुनिया की खोज की, जो एचटीएमएल और सीएसएस की तुलना में बहुत अधिक है। यह बहुत अच्छा था, इसके बाद मैंने इस विषय पर अधिक से अधिक किताबें पढ़ना शुरू किया। मैंने जो अगली भाषा सीखी वह जावा थी। एक बार जब मैंने लिनक्स मैगज़ीन में रूबी के बारे में पढ़ा (वास्तव में रूबी के बारे में नहीं, बल्कि रेल्स के बारे में), और सोचा कि इसे सीखना बहुत अच्छा होगा। वहां से यह सब शुरू हुआ, और, स्नोबॉल की तरह, आज तक लुढ़कता है।

और इसलिए आपने रूबी पर स्विच किया, है ना?

मैंने रूबी को उस समय खोजा जब मैंने कॉलेज में कंप्यूटर साइंस की पढ़ाई शुरू की थी, इसलिए उसी समय मैं जावा, सी ++, हास्केल का भी अध्ययन कर रहा था और न केवल एक साथ कई प्रोग्रामिंग लैंग्वेज सीख रहा था। हमारी पढ़ाई के हिस्से के रूप में, हमारे पास रूबी असाइनमेंट नहीं थे, और मैं वास्तव में उसे पसंद करता था, इसलिए मैंने हमेशा उन कक्षाओं में इसका उपयोग करने की कोशिश की, जहाँ आप स्वयं तकनीक का चयन कर सकते थे। ठीक है, उनके तीसरे पक्ष की परियोजनाओं में भी। जब मैंने कॉलेज से स्नातक किया, तो मैंने रूबी से संबंधित नौकरी की तलाश करने का फैसला किया। यह सरल था, क्योंकि रेल तब लोकप्रियता के चरम पर थी: कई स्टार्टअप इस तकनीक का इस्तेमाल करते थे। इसलिए रुचि मेरा काम बन गई है।

अब क्या आप रूबी को अपने प्राथमिक उपकरण के रूप में उपयोग करते हैं? या आप किसी और चीज के साथ काम कर रहे हैं?

मेरे वर्तमान टिल्ड जॉब में, मैं पहले की तरह रूबी नहीं लिखता। मैं कहूंगा कि मेरा काम जावास्क्रिप्ट / टाइपस्क्रिप्ट, रस्ट, रूबी और कभी-कभी जावा का कॉकटेल है। लेकिन, वैसे भी, मैं जो भी काम करता हूं, वह रूबी से संबंधित है।

टिल्डे का मुख्य उत्पाद स्काईलाइट है। इसमें सभी घटक रूबी में नहीं लिखे गए हैं: फ्रंटएंड जावास्क्रिप्ट और एम्बर में है, बैकएंड रेल में है, लेकिन आने वाले सभी डेटा प्रोसेसिंग जावा और रस्ट हैं। लेकिन Skylight ही रेल अनुप्रयोगों के लिए एक प्रदर्शन निगरानी उपकरण है। इस अर्थ में, मैं जो भी काम करता हूं, वह अभी भी रूबी से संबंधित है।

सुपर! मैंने खुद एक प्रोजेक्ट के लिए कुछ दिनों पहले स्काईलाइट के साथ पंजीकरण कराया था, अब मैं इसका परीक्षण कर रहा हूं। यह दिलचस्प लगता है, और शुरुआत से ही यह स्पष्ट है कि सब कुछ कैसे काम करता है। मैंने अभी तक बहुत गहरा नहीं किया है, लेकिन मेरी योजना है कि अगले सप्ताह इसे बहुत कसकर उपयोग करना शुरू करें। मुझे उम्मीद है कि मैं इसके साथ कुछ समस्याओं को ठीक कर सकता हूं।

महान, यह प्रतिक्रिया सुनने के लिए बहुत अच्छा होगा!

रूबी की तुलना अन्य भाषाओं से करना दिलचस्प है। उदाहरण के लिए, जंग के साथ। रूबी बहुत अभिव्यंजक है, और कोड को पठनीय बनाने के लिए डिज़ाइन किया गया है। यदि आप इसकी तुलना पायथन से या C ++, C #, Java से करते हैं, तो, मेरी राय में, रूबी को पढ़ना उतना आसान नहीं है। आप इस बारे में क्या सोचते हैं?

मैं मान जाऊंगा। एक नई भाषा "सीखने" के दो तरीके हैं। पहला काफी सतही है: मैं वाक्य रचना की मूल बातों का अध्ययन करता हूं, उदाहरणों के साथ खेलता हूं, और फिर तुरंत इसके बारे में भूल जाता हूं। ऐसा ही था गो के साथ। मैंने इसे सप्ताहांत पर किया, फिर कुछ हफ़्ते के लिए मैंने इस पर छोटे प्रोजेक्ट लिखे। लेकिन तब मेरे पास गो पर प्रोग्रामिंग जारी रखने का कोई कारण नहीं था। मैंने सिर्फ जिज्ञासा के लिए इसका अध्ययन किया, और जल्दी से भूल गया।

दूसरी ओर, जावास्क्रिप्ट / टाइपस्क्रिप्ट, रस्ट और रूबी है, जो मैं हर समय उपयोग करता हूं। इनमें से प्रत्येक भाषा ने मेरे लिए नए अवसर खोले हैं, यह बहुत ही प्रेरक है।

उदाहरण के लिए, जब मैंने रूबी के साथ काम करना शुरू किया, तो मैं अभिव्यक्ति से आकर्षित हुआ। किसी अन्य भाषा ने आपको method_missing जैसी पागल चीजों को करने की अनुमति नहीं दी है। रूबी के बारे में प्यार करने वाली प्रमुख बातें मेट्रोपोग्रामिंग, स्पष्टता और कोड पठनीयता हैं। यह अन्य भाषाओं में हो सकता है तो अच्छा होगा।

लेकिन उनमें आप वे काम कर सकते हैं जो रूबी में असंभव हैं। उदाहरण के लिए, जावास्क्रिप्ट। रूबी के साथ सब कुछ उसके साथ बिल्कुल अलग था, जिसे मुझे पहली नजर में प्यार हो गया। मैंने आवश्यकतानुसार जावास्क्रिप्ट का उपयोग करना शुरू कर दिया, मुझे ब्राउज़र कोड लिखने की आवश्यकता थी। हम इसे पसंद करते हैं या नहीं, जेएस से दूर नहीं हो रहा है। यदि आप एक इंटरैक्टिव ब्राउज़र एप्लिकेशन लिखना चाहते हैं, जैसे कि स्काईलाइट (बस उस समय मेरी क्या दिलचस्पी थी), तो जावास्क्रिप्ट एकमात्र रास्ता है।

मैं उन विचारों को स्थानांतरित करना चाहता था जो मुझे रूबी में जावास्क्रिप्ट में पसंद थे, इसलिए अंत में मैंने एम्बर के साथ काम करना शुरू कर दिया। यह, बदले में, मुझे टाइपस्क्रिप्ट के लिए ले गया। जब आप जावास्क्रिप्ट में एक विशाल फ्रेमवर्क, जैसे कि एम्बर, लिखते हैं, तो त्रुटियों की जाँच के लिए प्रकार और एक संकलक वास्तव में मदद करता है। जावास्क्रिप्ट और टाइपस्क्रिप्ट ने मुझे यह समझने में मदद की।

Rust ने मुझे जो विचार सिखाए हैं वे टाइपस्क्रिप्ट के समान हैं। पूरे कार्यक्रम को संकलित करने में सक्षम होना अच्छा है, और सुनिश्चित करें कि यह काम करता है। मेरे लिए, यह सिर्फ भयानक है। मैंने पहले संकलित भाषाओं के साथ काम किया है: जावा और सी के साथ। आपको कोड संकलन तक उनका भी इंतजार करना चाहिए, लेकिन यह बहुत काम का नहीं है, क्योंकि इन भाषाओं में टाइप सिस्टम बहुत अच्छी तरह से त्रुटियों को पकड़ नहीं पाता है। लेकिन रस्ट में, कंपाइलर गारंटी दे सकता है कि कार्यक्रम मेमोरी समस्याओं का कारण नहीं होगा, और यह कि इसके निष्पादन के दौरान कोई विभाजन त्रुटियां (सीगफॉल्ट) नहीं होंगी। C प्रोग्रामिंग में सबसे मुश्किल चीजों में से एक है मेमोरी प्रॉब्लम्स, जिनसे बचना बहुत मुश्किल है। मेरे लिए रस्ट की मुख्य विशेषता इसके बारे में चिंता किए बिना निम्न-स्तरीय प्रोग्रामिंग करने की क्षमता है।

वैसे, रूस्त में मेरी रुचि रूबी से संबंधित थी। मैंने सिर्फ टिल्ड में काम करना शुरू किया, और मुझे पता था कि रोस्ट में स्काइलाइट रत्न लिखा गया था। मुझे लगा कि इस तरह से रूबी के लिए देशी एक्सटेंशन लिखना सीखना बहुत अच्छा होगा। मैं सीखना चाहता था कि रस्ट में कैसे लिखना है ताकि मैं कस्टम चॉप प्रक्रियाओं को तोड़ने के बारे में चिंता न करूं, जैसा कि तब होता है जब सी में गलत तरीके से अंकन किया जाता है। इसलिए, मेरे लिए जंग सीखने का मुख्य लक्ष्य, वास्तव में, रूबी के लिए मूल एक्सटेंशन लिखना था।

आज सुबह, मैं टिल्डे से पीटर वेगेनेट के साथ एक प्रोजेक्ट पर काम कर रहा था, और शोपिफ़ और कोर रेल्स टीम से सीन ग्रिफिन। शॉन धीमी भागों को गति देने के लिए रस्ट में सक्रिय रिकॉर्ड के एक नए संस्करण पर काम कर रहा है। और इस साक्षात्कार से ठीक पहले, मैं Rust में libcruby-sys नामक एक परियोजना पर काम कर रहा था, जो आपको रूबी के लिए Rust में मूल एक्सटेंशन लिखने की अनुमति देता है।

अंत में, हम कह सकते हैं कि सभी भाषाएँ जुड़ी हुई हैं। मैं जिन भाषाओं को सीखता और प्रोग्राम करता हूं, वे सिर्फ ऐसे उपकरण हैं जो मुझे वह बनाने की अनुमति देते हैं जो मेरे मन में है।

बहुत दिलचस्प! कूल कि ActiveRecord बहुत तेज हो जाएगा। जहां तक ​​मैं समझता हूं, ActiveRecord का विचार नहीं बदलेगा। मेरा मतलब है, क्या यह वही ActiveRecord होगा, और डेटा मैपर जैसा कुछ नहीं होगा?

रूबी पर सक्रिय रिकॉर्ड, निश्चित रूप से, कहीं भी नहीं जाएगा, यह सक्रिय रूप से विकसित हो रहा है, इसका उपयोग किया जाता है। JRuby के मामले में, यह पहली पसंद है। शॉन का कार्यान्वयन मूल एपीआई के साथ 100% संगत है। इंटर्न को रस्ट में फिर से लिखा गया है, इसलिए सब कुछ तेजी से काम करता है, लेकिन अंतिम उपयोगकर्ता के लिए एपीआई नहीं बदलेगा।

इस परियोजना के साथ एक ही बात है कि मैं पिछले कुछ वर्षों से काम कर रहा हूं। इसे हेलिक्स कहा जाता है, और रूबी के लिए मूल एक्सटेंशन बनाने के लिए रस्ट के साथ मेरे प्रयोगों से जुड़ा हुआ है। स्मृति सुरक्षा समस्याओं के एक समूह की वजह से इसे शुरू करना बहुत मुश्किल था जिसे संबोधित करने की आवश्यकता थी। हेलिक्स आपको केवल रस्ट में कोड लिखने पर ध्यान केंद्रित करने की अनुमति देता है, वह रूबी-विस्तार में इसे संकलित करने का ध्यान रखता है।

मुझे लगता है कि कई ने रूबी में JSON रत्न का उपयोग किया। वास्तव में, इस रत्न के दो अलग-अलग कार्यान्वयन हैं। एक शुद्ध रूबी कार्यान्वयन और एक सी एक्सटेंशन है जो एक ही एपीआई को लागू करता है। यह ध्यान देने योग्य नहीं है, लेकिन यदि आप लिखते हैं कि 'json की आवश्यकता है', तो सबसे अधिक संभावना है कि C संस्करण लोड किया जाएगा। यदि वर्तमान प्लेटफ़ॉर्म समर्थित नहीं है, तो यह एक रूबी संस्करण होगा। लेकिन, फिर से, एपीआई का उपयोग दोनों मामलों में बिल्कुल उसी तरह किया जाता है। अंतर केवल इतना है कि उनमें से एक के लिए आंतरिक घटक सी में लागू किए जाते हैं, इसलिए यह तेजी से काम करता है। उच्च प्रदर्शन के अलावा, कोई मतभेद नहीं हैं। यह ऐसी सभी परियोजनाओं का लक्ष्य है - रूबी का उपयोग करने में सक्षम होना, जिसे हम प्यार करते हैं, लेकिन आवश्यक होने पर देशी कोड के प्रदर्शन लाभ प्राप्त करना।

यह बहुत अच्छा है कि रूबी तेज हो जाएगी। हालांकि एक राय है कि निष्पादन की गति रूबी कार्यक्रमों के लिए बहुत महत्वपूर्ण नहीं है, लेकिन मुझे यकीन है कि प्रदर्शन में वृद्धि होने पर हर कोई खुश होगा।

अधिकांश भाग के लिए मैं सहमत हूं। सामान्य तौर पर, यह ऐसा है। लेकिन, उत्पादकता में गंभीरता से वृद्धि होने पर, हम उन चीजों को कर सकते हैं जो पहले इस मंच पर असंभव थे। जैसा कि मैंने कहा, मैंने जावास्क्रिप्ट सीखा क्योंकि मैं ब्राउज़र के लिए कार्यक्रम लिखना चाहता था, और अन्यथा ऐसा करना असंभव है। मुझे लगता है कि प्रदर्शन के लिए भी यही सच है। मुझे परवाह नहीं है अगर कोड 20% तेजी से चलता है। यह अच्छा है, लेकिन यह इतना महत्वपूर्ण नहीं है। लेकिन जब कोड 10 गुना तेजी से चलता है, तो यह पूरी तरह से नई संभावनाओं को खोलता है।

उदाहरण के लिए, यदि आप मशीन सीखने में लगे हुए हैं, तो आपको बहुत सारी जटिल गणनाएँ करनी होंगी। सबसे अधिक संभावना है, आप इसे रूबी पर लागू नहीं कर पाएंगे, क्योंकि रूबी बहुत धीमी है। लेकिन अगर देशी मशीन लर्निंग लाइब्रेरी के साथ आसानी से बातचीत करने के लिए एक इंटरफ़ेस है, तो आप रूबी पर भी एमएल के साथ काम कर सकते हैं। आप रूबी में गणना के साथ सभी प्रक्रियाओं को ऑर्केस्ट्रेट करने के लिए कोड लिख सकते हैं, इसकी सभी अभिव्यक्तियों और रत्नों के पारिस्थितिकी तंत्र के साथ। मेरे लिए, प्रदर्शन नई सुविधाओं को लाने के लिए एक उपकरण है।

यह बिलकुल सच है! मैंने कई बार खराब प्रदर्शन रूबी कार्यक्रमों के साथ संघर्ष किया है। मुझे चीजों को गति देने के लिए, डेटाबेस पक्ष में तर्क का हिस्सा स्थानांतरित करने के लिए बहुत सारे एसक्यूएल कोड लिखना पड़ा, क्योंकि यह सैकड़ों गुना तेजी से काम करता है।

यह सही है, लेकिन मैं समस्याग्रस्त कोड को मूल एक्सटेंशन तक ले जाने के बजाय इसे गो या मास्केल पर माइक्रोसेर के रूप में फिर से लिखूंगा। मुझे लगता है कि जितना संभव हो उतना रूबी कोड लिखने में सक्षम होना अच्छा है, और प्रदर्शन-महत्वपूर्ण भागों को कहीं स्थानांतरित करना है जो आप आसानी से रूबी में बातचीत कर सकते हैं। अवसर ही अद्भुत है।

हां, यह व्यावसायिक कार्यों के संदर्भ में अधिक तेज और आसान होना चाहिए। विभिन्न कौशल और स्टैक के साथ प्रोग्रामर को काम पर रखने की आवश्यकता नहीं है, क्योंकि सब कुछ रूबी में लिखा जा सकता है। यह आशाजनक लगता है। आप रेल के भविष्य के बारे में क्या सोचते हैं? हर साल, ऐसी अफवाहें आती हैं कि रेल मर रही है ...

मैं पक्षपाती हूं क्योंकि मैं एक ऐसी कंपनी के लिए काम करता हूं, जिसका मुख्य उत्पाद रेल में एक प्रदर्शन निगरानी उपकरण है। व्यक्तिगत रूप से, मुझे नहीं लगता कि वे मर रहे हैं, लेकिन रेल निश्चित रूप से अधिक परिपक्व हो गई है, "परिपक्व"। समुदाय के कई लोगों के लिए, यह मौलिक रूप से नया है। हम में से कई रेल और रूबी समुदाय में शामिल हो गए जब रेल एक प्रचार विषय था। बहुत सारे उत्साह, बहुत सारे नवाचार थे। यद्यपि, हमारे कई "नवाचार" अन्य, अधिक वयस्क, पारिस्थितिक तंत्रों में सामान्य थे। तब बहुत कुछ असंभव था, क्योंकि पारिस्थितिकी तंत्र अभी भी अपरिपक्व था।

यह बहुत ही रोमांचक समय था। हर सोमवार, मैं RailsCasts के एक नए प्रकरण का इंतजार कर रहा था। हर हफ्ते नया रत्न। उदाहरण के लिए, इस सप्ताह हम पीडीएफ फाइलें बनाते हैं, अगले सप्ताह हम एक फाइल अपलोड करते हैं, और फिर कुछ नया दिखता है, जैसे कि बंडलर, उदाहरण के लिए। यह नए विचारों का समय था, रोमांचक, सभी में बहुत ऊर्जा थी। बहुत से लोग सोचते हैं कि रेल या रूबी मर रहे हैं क्योंकि ये भावनाएं दूर हो गई हैं।

और मेरी राय में, पारिस्थितिकी तंत्र अभी परिपक्व हो गया है और अधिक स्थिर हो गया है। हमने फ़ाइलों को अपलोड करने के लिए पहले से ही 5 अलग-अलग तरीकों से प्रयोग किया है, और हमें हर सप्ताह ऐसा करने की आवश्यकता नहीं है। भावनाओं के संदर्भ में, मैं निश्चित रूप से उन समयों को याद करता हूं। लेकिन मुझे नहीं लगता कि अब यह बदतर है। हम यह कह सकते हैं: “ठीक है, हम इन सभी कारनामों से गुज़रे, विभिन्न तरीकों की कोशिश की, सबक हासिल किया। और अब हमने सबसे अच्छा विकल्प चुना है जिसका उपयोग हर कोई करेगा। ” मुझे लगता है कि यह बहुत अच्छा है।

मेरा एक हिस्सा निश्चित रूप से उस ड्राइव को याद करता है, जो उस समय रूबी समुदाय में परिवर्तन और प्रगति की निरंतर भावना थी। अब मैं इसे रस्ट समुदाय में देखता हूं। वहां मैं उसी भावनाओं का अनुभव कर सकता हूं। हां, रूबी में, जुनून कम हो गया। लेकिन उत्पादकता और वास्तविक कार्य के दृष्टिकोण से - यह बिल्कुल भी बुरा नहीं है। मैं समझता हूं कि एक व्यक्ति जो लगातार नई चीजें सीखना पसंद करता है, उसे ऐसी भावनाओं की आवश्यकता होती है। मैं उन्हें अन्य पारिस्थितिक तंत्रों में ढूंढता और खोजता हूं। समुदाय पक रहा है, और कम परिवर्तन हैं। लेकिन व्यक्तिगत रूप से यह मुझे सूट करता है।

मुझे लगता है कि यह चीजों का स्वाभाविक क्रम है, और रेल अभी भी सुंदर है। जो कुछ भी होता है - वाणिज्यिक अनुप्रयोगों को विकसित करने वाले वास्तविक व्यवसाय को लाभ होता है। मुझे यह पसंद है कि रेल अलग-अलग तरीकों की अनुमति देती है। उदाहरण के लिए, रेल्स के संदर्भ में रहते हुए आप ट्रेलब्लेज़र या ड्राई-आरबी रत्नों का उपयोग कर सकते हैं। आप अपने कोड में विभिन्न प्रकार के सार का उपयोग कर सकते हैं, लेकिन अंततः यह अभी भी एक रेल अनुप्रयोग होगा। मुझे यही पसंद है।

मैं आपसे निश्चित रूप से सहमत हूं। मुझे लगता है कि पूरा पारिस्थितिकी तंत्र बड़ा हो रहा है। उस समय, जिसे अब हम रेल के "शिखर" कहते हैं, कई नए स्टार्टअप दिखाई दिए। किसी ने भी स्थिरता और स्थिरता की परवाह नहीं की। तब आपको नई भावनाओं और ऊर्जा का निरंतर प्रवाह मिलता है। अब इनमें से कई कंपनियां बड़े निगमों जैसे गीथूब या शोपिज़ में विकसित हो गई हैं, और स्थिरता के बारे में परवाह करना शुरू कर दिया है। यह कई लोगों के लिए सच है।

एक समुदाय के रूप में, हमने सामूहिक रूप से प्रयोगों पर स्थिरता को प्राथमिकता देने का फैसला किया। भाषा के दृष्टिकोण से, अभी भी प्रयोग के लिए बहुत जगह है क्योंकि रूबी वही रहती है। रूबी महान प्रयोग के लिए कारण कहीं नहीं गया था। हालांकि, समुदाय ने रेल पर काम करने वाली चीजों को बनाने पर ध्यान केंद्रित करने का फैसला किया, क्योंकि रेल लंबे समय से सक्रिय रूप से उपयोग की जाती है। जब आप एक मणि लिखते हैं, तो आप रेल के कई संस्करणों के लिए समर्थन करने की संभावना रखते हैं, क्योंकि कई कंपनियां हैं जो उनका उपयोग करती हैं। नतीजतन, रेल खुद भी अधिक सावधान हो जाते हैं, अनावश्यक रूप से अपने एपीआई को नहीं तोड़ते हैं। निजी तौर पर, मैं इस प्रक्रिया का हिस्सा बनकर खुश हूं।

व्यावसायिक दृष्टिकोण से, स्थिरता बहुत महत्वपूर्ण है। खासकर भारी भरकम सिस्टम के लिए। फ्रेमवर्क इंटरफेस की स्थिरता काम को आसान बनाती है। मुझे वह समय याद है जब रेल के एक संस्करण से दूसरे संस्करण में स्विच करना बहुत मुश्किल था। उदाहरण के लिए, उस समय जब अनुप्रयोग असंगत एन्कोडिंग के कारण त्रुटियों का एक गुच्छा फेंकना शुरू कर देता है।

ट्रेलब्लेज़र एक महान उदाहरण है जो समुदाय और पारिस्थितिकी तंत्र की वर्तमान स्थिति को दर्शाता है। एक ओर, यह तथ्य कि यह मौजूद है बहुत अच्छा प्रमाण है कि रूबी समुदाय में प्रयोग के लिए अभी भी बहुत जगह है। लेकिन मुझे लगता है कि अगर यह 5 साल पहले निकला था, तो यह अधिक लोकप्रिय होगा, क्योंकि अब हमने बहुत सारे रत्नों के साथ रेल के चारों ओर एक बहुत बड़ा पारिस्थितिकी तंत्र बनाया है।

अंत में, आप इस बारे में अधिक परवाह करते हैं कि आप परिचित स्टैक के साथ क्या कर सकते हैं। जब आपको बस एक एप्लिकेशन लिखने की आवश्यकता होती है जो चालान कर सकता है, पीडीएफ फाइलें बना सकता है और वेब सॉकेट का उपयोग कर सकता है, तो कई लोग उपयोग करना पसंद करेंगे जो दूसरे पहले से ही उपयोग करते हैं - इस मामले में, आप रत्नों, चर्चाओं को साझा कर सकते हैं, स्टैकऑवरफ्लो के उत्तर पा सकते हैं, आदि।

इस अर्थ में, हम कह सकते हैं कि रूबी समुदाय का हिस्सा मर गया है। 5-10 साल पहले, आपने लगातार नई चीजें कीं, संगतता के बारे में बहुत ज्यादा चिंता नहीं की, नवीनतम और सबसे अच्छे रत्नों का उपयोग किया, क्योंकि आपकी पीठ के पीछे कोई "सामान" नहीं था। अब, "सामान" के समुदाय में अधिकांश परियोजनाएं शालीनता से जमा हुई हैं। और जो लोग प्रयोग और नवाचार से प्यार करते हैं, वे अन्य समुदायों और पारिस्थितिक तंत्रों में चले गए हैं।

मुझे लगता है कि यह सामान्य है।

मुझे कोई आपत्ति नहीं है। यह बड़े होने जैसा है, जीवन का एक और चरण है।

स्टैटिक टाइपिंग से आप क्या समझते हैं? क्या रूबी में इस दृष्टिकोण का लाभ मिलने की कोई संभावना है?

मैं इसके लिए तत्पर हूं क्योंकि मैंने टाइपस्क्रिप्ट के साथ जावास्क्रिप्ट पारिस्थितिकी तंत्र में पहले से ही इस चीज के लाभों का अनुभव किया है। जावास्क्रिप्ट रूबी के समान है। , , . TypeScript — JavaScript , JavaScript . , , , , . TypeScript, JavaScript.

, . TypeScript. Ruby. , TypeScript JavaScript, , JavaScript . . , . , , . JavaScript, , , , - JavaScript. , TypeScript JavaScript, , .

, Ruby, . , , , , , , , , Rails, , , , . , Ruby .

. , . : . , , . , , , , . , .

, , . , TypeScript . . , JavaScript . , - , .

, — . , . TypeScript , . , Ruby. , Ruby , .

, RailsClub . , , . , . , .

, , , , , , , , - .

, , , , .

, . , , Rails, . . - , , Rails. , JavaScript , . , Ember, TypeScript. , , JavaScript . , , . , .

? 5 ?

, . 2 .

-, , «», , . , , . Ruby, , . , Ruby , open source, . . , . , , , .

Medium. , , , — . , , , , , . — , , .

, . , . . , . , . ?

, . . «». - «», . , - , , . , , .

, , . . , Ruby. , , Rust Ruby. . , . , . , , , , , . — .

, ?

, . , — , . , .

, . , Rust . Java Rust. , Rust. , . Rust — , .

, — . -, .

Rust, , . , , , , -, . , , , , . .

, «This Week in Rails» .

धन्यवाद! , , . , , . , , .

, , 2 . , Rails!

! , .

धन्यवाद! . RubyRussia . ?

, , , . , . , , . ? -, ?

-, , , . : , , . ! , , .

! - , . , . , !

.

!

! ! ! !

! ( :) 6 . , . 8000 .

hype.codes .

, Ruby- :

— Toptal
— Gett
— Instamart , UCHi.ru , JetBrains
— Bookmate InSales