પ્રોગ્રામિંગ ભાષાઓ

સામગ્રી:

• સારાંશ
  • સમસ્યા
  • નિર્ણય
  • સ્થિતિ
• વિગતો
  • ધારણાઓ
  • મર્યાદાઓ
  • વલણો
  • દલીલ
  • અસરો
• સંબંધિત
  • સંબંધિત નિર્ણયો
  • સંબંધિત જરૂરિયાતો
  • સંબંધિત આર્ટિફેક્ટ્સ
  • સંબંધિત સિદ્ધાંતો
• નોંધો

સારાંશ

સમસ્યા

અમારે અમારા સોફ્ટવેર માટે પ્રોગ્રામિંગ ભાષાઓ પસંદ કરવાની જરૂર છે. અમારી બે મુખ્ય જરૂરિયાતો છે: વેબ એપ્લિકેશનો માટે યોગ્ય ફ્રન્ટ-એન્ડ પ્રોગ્રામિંગ ભાષા, અને સર્વર એપ્લિકેશનો માટે યોગ્ય બેક-એન્ડ પ્રોગ્રામિંગ ભાષા.

નિર્ણય

અમે ફ્રન્ટ-એન્ડ માટે 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 પસંદ કરવા માગીએ છીએ જેની પાસે આ ભાષાઓ માટે સારી ક્ષમતાઓ હોય.

ઉદાહરણ તરીકે, અમારા ફ્રન્ટ-એન્ડ વેબ ફ્રેમવર્ક માટે, અમે સાદા JavaScript તરફ ઝુકતા ફ્રેમવર્ક (દા.ત. React) કરતાં TypeScript તરફ ઝુકતા ફ્રેમવર્ક (દા.ત. Vue) પર નિર્ણય કરવાની શક્યતા વધુ છે.

સંબંધિત જરૂરિયાતો

અમારી સંપૂર્ણ ટૂલચેઇને આ ભાષાઓને સપોર્ટ કરવી જોઈએ.

સંબંધિત આર્ટિફેક્ટ્સ

અમે અપેક્ષા રાખીએ છીએ કે અમે કેટલીક ગુપ્ત માહિતી પર્યાવરણ ચલોમાં નિકાસ કરી શકીએ.

સંબંધિત સિદ્ધાંતો

બે વાર માપો, એકવાર બનાવો. અમે કેટલીક ઝડપ કરતાં કેટલીક સુરક્ષાને અગ્રતા આપી રહ્યા છીએ.

રનટાઇમ કમ્પાઇલ સમય કરતાં વધુ મૂલ્યવાન છે. અમે ડેવલપર ઉપયોગ કરતાં ગ્રાહક ઉપયોગને અગ્રતા આપી રહ્યા છીએ.

નોંધો

અહીં કોઈપણ નોંધો.