Architecture Decision Record

Active theme: Light

← فیصلہ ریکارڈ کی مثالیں

پروگرامنگ زبانیں

فہرست:

خلاصہ

مسئلہ

ہمیں اپنے سافٹ ویئر کے لیے پروگرامنگ زبانیں چننی ہیں۔ ہماری دو بنیادی ضروریات ہیں: ویب ایپلیکیشنز کے لیے موزوں فرنٹ اینڈ پروگرامنگ زبان، اور سرور ایپلیکیشنز کے لیے موزوں بیک اینڈ پروگرامنگ زبان۔

فیصلہ

ہم فرنٹ اینڈ کے لیے TypeScript چن رہے ہیں۔

ہم بیک اینڈ کے لیے Rust چن رہے ہیں۔

حالت

فیصلہ ہو گیا۔ ہم نئے متبادلات کے لیے، جب وہ سامنے آئیں، کھلے ہیں۔

تفصیلات

مفروضات

فرنٹ اینڈ ایپلیکیشنز عام ہیں:

  • عام صارفین اور تعاملات

  • عام براؤزرز اور سسٹمز

  • عام ڈویلپمنٹس اور ڈپلائمنٹس

فرنٹ اینڈ ایپلیکیشنز کے تیزی سے ارتقا پذیر ہونے کا امکان ہے:

  • ہم تیز اور آسان ڈویلپمنٹس، ڈپلائمنٹس، تکرار وغیرہ یقینی بنانا چاہتے ہیں۔

  • ہم ثابت پذیری (provability) کی قدر کرتے ہیں، جیسے ٹائپ سیفٹی، اور اسے حاصل کرنے کے لیے تھوڑا زیادہ کام کرنے میں ٹھیک ہیں۔

  • ہمیں لیگیسی مطابقت کی ضرورت نہیں۔

بیک اینڈ ایپلیکیشنز عام سے بلند تر ہیں:

  • معیار کے عام سے بلند تر اہداف، خاص طور پر ثابت پذیری، قابلِ اعتمادی، سیکیورٹی وغیرہ۔

  • قریب-ریئل ٹائم کے عام سے بلند تر اہداف، یعنی ہم ورچوئل مشین کی گاربیج کلیکشن کی وجہ سے رکاوٹیں نہیں چاہتے۔

  • فنکشنل پروگرامنگ کے عام سے بلند تر اہداف، خاص طور پر متوازی کاری، ملٹی کور پروسیسنگ اور میموری کی حفاظت کے لیے۔

ہم کمپائل کے وقت کی حفاظت اور رن ٹائم رفتار کے حق میں کم کمپائل رفتار قبول کرتے ہیں۔

پابندیاں

ہم پر ان زبانوں کے بارے میں مضبوط پابندی ہے جو بڑے کلاؤڈ فراہم کنندگان کی فنکشن خدمات، جیسے 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: ڈپلائمنٹ کی اہلیت اور concurrency سمیت بہترین رن ٹائم؛ بہترین ڈویلپر کا تجربہ؛ نسبتاً چھوٹا ماحولیاتی نظام۔

  • Erlang: ڈپلائمنٹ کی اہلیت اور concurrency سمیت بہترین رن ٹائم؛ مشکل ڈویلپر کا تجربہ؛ نسبتاً چھوٹا ماحولیاتی نظام۔

  • Elm: بہت امید افزا لگتا ہے؛ IBM اچھے نتائج کے ساتھ بڑے کیس اسٹڈیز شائع کر رہا ہے؛ چھوٹا ماحولیاتی نظام۔

  • Flow: JavaScript پر دلچسپ بہتری؛ تاہم ڈویلپرز اس سے دور ہو رہے ہیں۔

  • Go: بہترین ڈویلپر کا تجربہ؛ بہترین concurrency؛ لیکن زبان کو اپاہج کرنے والے برے فیصلوں کا ریکارڈ۔

  • Haskell: بہترین فنکشنل زبان؛ چھوٹی ڈویلپر کمیونٹی؛ پروڈکشن میں شائع شدہ کافی کامیابیاں حاصل نہیں کیں۔

  • Java: بہترین رن ٹائم؛ بہترین ماحولیاتی نظام؛ اوسط سے کم ڈویلپر کا تجربہ۔

  • JavaScript: اب تک کی سب سے مقبول زبان؛ سب سے وسیع ماحولیاتی نظام۔

  • Kotlin: Java کی بہت سی چیزیں ٹھیک کرتی ہے؛ JetBrains کی بہترین پشت پناہی؛ Java سے Kotlin میں منتقلی کی اچھی شائع شدہ مثالیں۔

  • Python: سسٹم ایڈمنسٹریشن کے لیے سب سے مقبول زبان؛ بہترین اینالیٹکس ٹولنگ؛ اچھے ویب فریم ورکس؛ لیکن Google نے Go کے حق میں اسے چھوڑ دیا۔

  • Ruby: اب تک کا بہترین ڈویلپر کا تجربہ؛ بہترین ویب فریم ورکس؛ سب سے خوشگوار کمیونٹی؛ لیکن بہت سست؛ پیکیج کرنا کسی حد تک مشکل۔

  • Rust: بہترین نئی زبان؛ صفر تجرید (zero-abstraction) پر زور؛ concurrency پر زور؛ تاہم نسبتاً چھوٹا ماحولیاتی نظام؛ اور کمپائلر کی بعض تیزیوں پر دانستہ حدود ہیں، مثلاً براہِ راست میموری تک رسائی صراحت سے غیر محفوظ (unsafe) ہونی چاہیے۔

  • TypeScript: JavaScript میں ٹائپس شامل کرتی ہے؛ بہترین ٹرانس پائلر؛ JavaScript سے TypeScript میں منتقلی پر ڈویلپرز کا بڑھتا ہوا زور؛ Microsoft کی مضبوط پشت پناہی۔

ہم نے فیصلہ کیا کہ VMs کے سمجھوتوں کا ایک سیٹ ہے جس کی ہمیں ابھی ضرورت نہیں، جیسے اضافی پیچیدگی جو رن ٹائم کی صلاحیتیں فراہم کرتی ہے۔

ہمارا ماننا ہے کہ ہمارا بنیادی فیصلہ دو عمومی تشویشوں سے چلتا ہے:

  • تیز ترین رن ٹائم رفتار اور سخت ترین سسٹم رسائی کے لیے ہم 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 کے کمپائل کے اوقات کافی سست ہیں۔ اس کا کچھ حصہ زبانوں کی نئی ہونے کی وجہ سے ہو سکتا ہے۔ ہم دیکھنا چاہ سکتے ہیں کہ سست کمپائل کے اوقات کو کیسے کم کیا جائے، جیسے مانگ پر کمپائل، کمپائل concurrency وغیرہ۔

ان زبانوں کے لیے IDE سپورٹ ابھی ہر جگہ نہیں اور ابھی اعلیٰ درجے کی نہیں۔ مثلاً JetBrains، Python کی اعلیٰ درجے کی سپورٹ کے لیے PyCharm IDE بیچتی ہے، لیکن Rust کی اعلیٰ درجے کی سپورٹ والی IDE نہیں بیچتی؛ اس کی بجائے JetBrains ایک Rust پلگ اِن استعمال کر سکتی ہے جو Python زبان کی سپورٹ کے مقابلے میں شاید 80% Rust زبان کی سپورٹ فراہم کرتا ہے۔

متعلقہ

متعلقہ فیصلے

ہم ماحولیاتی نظام کے ایسے انتخابات کی طرف جائیں گے جو ان زبانوں سے ہم آہنگ ہوں۔

مثلاً ہم ایسی IDE چننا چاہتے ہیں جس کی ان زبانوں کے لیے اچھی صلاحیتیں ہوں۔

مثلاً اپنے فرنٹ اینڈ ویب فریم ورک کے لیے، ہمارے ایسے فریم ورک پر فیصلہ کرنے کا امکان جو TypeScript کی طرف مائل ہو (مثلاً Vue)، خالص JavaScript کی طرف مائل فریم ورک (مثلاً React) سے زیادہ ہے۔

متعلقہ تقاضے

ہماری پوری ٹول چین کو ان زبانوں کی سپورٹ کرنی چاہیے۔

متعلقہ آرٹیفیکٹس

ہم توقع کرتے ہیں کہ ہم کچھ راز ماحولیاتی متغیرات میں برآمد کر سکتے ہیں۔

متعلقہ اصول

دو بار ناپو، ایک بار بناؤ۔ ہم کچھ رفتار پر کچھ حفاظت کو ترجیح دے رہے ہیں۔

رن ٹائم کمپائل کے وقت سے زیادہ قیمتی ہے۔ ہم ڈویلپر کے استعمال پر صارف کے استعمال کو ترجیح دے رہے ہیں۔

نوٹس

یہاں کوئی بھی نوٹس۔