प्रोग्रामिंग भाषाएँ
विषय-सूची:
सारांश
मुद्दा
हमें अपने सॉफ़्टवेयर के लिए प्रोग्रामिंग भाषाएँ चुननी हैं। हमारी दो प्रमुख आवश्यकताएँ हैं: वेब एप्लिकेशन के लिए उपयुक्त फ्रंट-एंड प्रोग्रामिंग भाषा, और सर्वर एप्लिकेशन के लिए उपयुक्त बैक-एंड प्रोग्रामिंग भाषा।
निर्णय
हम फ्रंट-एंड के लिए TypeScript चुन रहे हैं।
हम बैक-एंड के लिए Rust चुन रहे हैं।
अवस्था
तय। नए विकल्पों के सामने आने पर हम उनके लिए खुले हैं।
विवरण
मान्यताएँ
फ्रंट-एंड एप्लिकेशन सामान्य हैं:
सामान्य उपयोगकर्ता और संवाद
सामान्य ब्राउज़र और प्रणालियाँ
सामान्य विकास और तैनाती
फ्रंट-एंड एप्लिकेशन के तेज़ी से विकसित होने की संभावना है:
हम तेज़, आसान विकास, तैनाती, पुनरावृत्ति आदि सुनिश्चित करना चाहते हैं।
हम सिद्ध किए जा सकने की क्षमता को महत्व देते हैं, जैसे टाइप सुरक्षा, और उसे प्राप्त करने के लिए थोड़ा अधिक काम करने को तैयार हैं।
हमें पुरानी प्रणालियों के साथ अनुकूलता की आवश्यकता नहीं है।
बैक-एंड एप्लिकेशन सामान्य से ऊँचे स्तर के हैं:
गुणवत्ता, विशेषकर सिद्ध किए जा सकने की क्षमता, विश्वसनीयता, सुरक्षा आदि के सामान्य से ऊँचे लक्ष्य।
निकट-रीयल-टाइम के सामान्य से ऊँचे लक्ष्य, यानी हम वर्चुअल मशीन गार्बेज कलेक्शन के कारण विराम नहीं चाहते।
फ़ंक्शनल प्रोग्रामिंग के सामान्य से ऊँचे लक्ष्य, विशेषकर समानांतरीकरण, मल्टी-कोर प्रोसेसिंग और मेमोरी सुरक्षा के लिए।
हम कंपाइल-समय की सुरक्षा और रनटाइम गति के पक्ष में कंपाइल-समय की कम गति स्वीकार करते हैं।
बाधाएँ
हमारे पास उन भाषाओं पर मज़बूत बाधा है जो प्रमुख क्लाउड प्रदाता सेवाओं के फ़ंक्शन, जैसे Amazon Lambda, के साथ उपयोग योग्य हैं।
रुख
हमने इन भाषाओं पर विचार किया:
C
C++
Clojure
Elixir
Erlang
Elm
Flow
Go
Haskell
Java
JavaScript
Kotlin
Python
Ruby
Rust
TypeScript
तर्क
प्रति भाषा सारांश:
C: कम सुरक्षा के कारण अस्वीकृत; Rust लगभग सब कुछ बेहतर कर सकती है।
C++: अव्यवस्थित होने के कारण अस्वीकृत; Rust लगभग सब कुछ बेहतर कर सकती है।
Clojure: उत्कृष्ट मॉडलिंग; सर्वश्रेष्ठ Lisp सन्निकटन; JVM पर बढ़िया रनटाइम।
Elixir: तैनाती-योग्यता और कॉन्करेंसी सहित उत्कृष्ट रनटाइम; उत्कृष्ट डेवलपर अनुभव; अपेक्षाकृत छोटा पारिस्थितिकी तंत्र।
Erlang: तैनाती-योग्यता और कॉन्करेंसी सहित उत्कृष्ट रनटाइम; चुनौतीपूर्ण डेवलपर अनुभव; अपेक्षाकृत छोटा पारिस्थितिकी तंत्र।
Elm: बहुत आशाजनक दिखती है; IBM अच्छे नतीजों वाले प्रमुख केस स्टडी प्रकाशित कर रहा है; छोटा पारिस्थितिकी तंत्र।
Flow: JavaScript पर दिलचस्प सुधार; हालाँकि, डेवलपर इससे दूर जा रहे हैं।
Go: उत्कृष्ट डेवलपर अनुभव; उत्कृष्ट कॉन्करेंसी; लेकिन खराब निर्णयों का रिकॉर्ड जो भाषा को पंगु बनाता है।
Haskell: सर्वश्रेष्ठ फ़ंक्शनल भाषा; छोटा डेवलपर समुदाय; पर्याप्त प्रकाशित उत्पादन सफलताएँ हासिल नहीं की हैं।
Java: उत्कृष्ट रनटाइम; उत्कृष्ट पारिस्थितिकी तंत्र; औसत से कम डेवलपर अनुभव।
JavaScript: अब तक की सबसे लोकप्रिय भाषा; सबसे व्यापक पारिस्थितिकी तंत्र।
Kotlin: Java की बहुत-सी कमियाँ दूर करती है; JetBrains का उत्कृष्ट समर्थन; Java से Kotlin में पोर्ट करने के अच्छे प्रकाशित मामले।
Python: सिस्टम प्रशासन के लिए सबसे लोकप्रिय भाषा; बढ़िया एनालिटिक्स उपकरण; अच्छे वेब फ़्रेमवर्क; लेकिन Google ने Go के पक्ष में इसे छोड़ दिया।
Ruby: अब तक का सर्वश्रेष्ठ डेवलपर अनुभव; सर्वश्रेष्ठ वेब फ़्रेमवर्क; सबसे अच्छा समुदाय; लेकिन बहुत धीमी; पैकेज करना कुछ कठिन।
Rust: सर्वश्रेष्ठ नई भाषा; शून्य-अमूर्तन पर ज़ोर; कॉन्करेंसी पर ज़ोर; हालाँकि अपेक्षाकृत छोटा पारिस्थितिकी तंत्र; और कुछ प्रकार के कंपाइलर त्वरण पर जानबूझकर सीमाएँ हैं, जैसे सीधी मेमोरी एक्सेस को स्पष्ट रूप से असुरक्षित (unsafe) होना चाहिए।
TypeScript: JavaScript में टाइप जोड़ती है; बढ़िया ट्रांसपाइलर; JavaScript से TypeScript में पोर्ट करने पर डेवलपरों का बढ़ता ज़ोर; Microsoft का मज़बूत समर्थन।
हमने तय किया कि VM के साथ समझौतों का एक समूह है जिसकी हमें अभी आवश्यकता नहीं है, जैसे अतिरिक्त जटिलता जो रनटाइम क्षमताएँ प्रदान करती है।
हमारा मानना है कि हमारा मूल निर्णय दो क्रॉस-कटिंग चिंताओं से प्रेरित है:
सबसे तेज़ रनटाइम गति और सबसे कसी हुई सिस्टम पहुँच के लिए, हम JavaScript और C चुनेंगे।
लगभग सबसे तेज़ रनटाइम गति और लगभग सबसे कसी हुई सिस्टम पहुँच के लिए, हम TypeScript और Rust चुनते हैं।
उन VM भाषाओं और वेब फ़्रेमवर्क को सम्मानजनक उल्लेख, जिन्हें हम तब चुनते यदि हमें VM भाषा चाहिए होती:
Clojure और Luminus
Java और Spring
Elixir और Phoenix
निहितार्थ
फ्रंट-एंड डेवलपरों को TypeScript सीखनी होगी। यदि डेवलपर का मुख्य अनुभव JavaScript का उपयोग है, तो यह संभवतः आसान सीखने की प्रक्रिया है।
बैक-एंड डेवलपरों को Rust सीखनी होगी। यदि डेवलपर का मुख्य अनुभव C/C++ का उपयोग है, तो यह संभवतः मध्यम सीखने की प्रक्रिया है, और यदि डेवलपर का मुख्य अनुभव Java, Python, Ruby या मेमोरी-प्रबंधित समान भाषाओं का उपयोग है, तो कठिन सीखने की प्रक्रिया है।
TypeScript और Rust दोनों अपेक्षाकृत नई हैं। इसका अर्थ है कि कई उपकरणों में अभी इन भाषाओं के लिए दस्तावेज़ीकरण नहीं है। उदाहरण के लिए, devops पाइपलाइन इन भाषाओं के लिए सेट करनी होगी, और अब तक, जिन devops उपकरणों का हम मूल्यांकन कर रहे हैं उनमें से किसी के पास इन भाषाओं के लिए डिफ़ॉल्ट उदाहरण नहीं हैं।
TypeScript और Rust के लिए कंपाइल समय काफ़ी धीमे हैं। इसका कुछ हिस्सा भाषाओं की नवीनता के कारण हो सकता है। हम देखना चाह सकते हैं कि धीमे कंपाइल समय को कैसे कम किया जाए, जैसे ज़रूरत पर कंपाइल करना, समवर्ती कंपाइल करना आदि।
इन भाषाओं के लिए IDE समर्थन अभी सर्वव्यापी और प्रथम श्रेणी का नहीं है। उदाहरण के लिए, JetBrains Python के प्रथम श्रेणी समर्थन के लिए PyCharm IDE बेचता है, लेकिन Rust के प्रथम श्रेणी समर्थन वाला IDE नहीं बेचता; इसके बजाय, JetBrains एक Rust प्लग-इन का उपयोग कर सकता है जो Python भाषा समर्थन की तुलना में शायद 80% Rust भाषा समर्थन देता है।
संबंधित
संबंधित निर्णय
हम ऐसे पारिस्थितिकी तंत्र चुनावों की ओर बढ़ेंगे जो इन भाषाओं के अनुरूप हों।
उदाहरण के लिए, हम ऐसा IDE चुनना चाहते हैं जिसमें इन भाषाओं के लिए अच्छी क्षमताएँ हों।
उदाहरण के लिए, अपने फ्रंट-एंड वेब फ़्रेमवर्क के लिए, हम ऐसा फ़्रेमवर्क चुनने की अधिक संभावना रखते हैं जो TypeScript की ओर झुका हो (जैसे Vue), बनिस्बत उस फ़्रेमवर्क के जो सादे JavaScript की ओर झुका हो (जैसे React)।
संबंधित आवश्यकताएँ
हमारी पूरी टूलचेन को इन भाषाओं का समर्थन करना होगा।
संबंधित कलाकृतियाँ
हम अपेक्षा करते हैं कि हम कुछ गोपनीय जानकारी को एनवायरनमेंट वेरिएबल में निर्यात कर सकते हैं।
संबंधित सिद्धांत
दो बार नापें, एक बार बनाएँ। हम कुछ गति की तुलना में कुछ सुरक्षा को प्राथमिकता दे रहे हैं।
रनटाइम कंपाइल समय से अधिक मूल्यवान है। हम डेवलपर उपयोग की तुलना में ग्राहक उपयोग को प्राथमिकता दे रहे हैं।
टिप्पणियाँ
यहाँ कोई भी टिप्पणी।