30 مارس 2025·8 دقيقة
غرايدون هور وRust: التحول نحو أنظمة آمنة للذاكرة
من تجربة غرايدون هور عام 2006 إلى منظومة Rust اليوم، تعرف كيف أعادت فكرة أمان الذاكرة بدون جامع قمامة تشكيل برمجة الأنظمة.
من تجربة غرايدون هور عام 2006 إلى منظومة Rust اليوم، تعرف كيف أعادت فكرة أمان الذاكرة بدون جامع قمامة تشكيل برمجة الأنظمة.
تروي هذه المقالة قصة أصل مركزة: كيف تحوَّل اختبار شخصي لغرايدون هور إلى Rust، ولماذا كانت اختيارات تصميم Rust مهمة إلى درجة أنها أعادت تشكيل توقعات برمجة الأنظمة.
"برمجة الأنظمة" قريبة من الجهاز—وقريبة من مخاطر منتجك. تظهر في المتصفحات، محركات الألعاب، مكونات نظم التشغيل، قواعد البيانات، الشبكات، والبرمجيات المدمجة—أماكن تطلب عادةً:
تاريخيًا، دفعت هذه المجموعة الفرق نحو C و C++، إضافة إلى قواعد ومراجعات وأدوات واسعة للحد من أخطاء الذاكرة.
وعد Rust الوجيز سهل القول وصعب التنفيذ:
أمان الذاكرة بدون جامع قمامة.
تهدف Rust إلى منع حالات فشل شائعة مثل use-after-free و double-free وأنواع كثيرة من سباقات البيانات—دون الاعتماد على وقت تشغيل يقوم بين الحين والآخر بإيقاف البرنامج لجمع الذاكرة. بدلاً من ذلك، تنقل Rust معظم هذا العمل إلى وقت الترجمة عبر الملكية والاقتراض.
ستحصل على التاريخ (من الأفكار المبكرة إلى تدخل موزيلا) والمفاهيم الرئيسية (الملكية، الاقتراض، فترات الحياة، الآمن مقابل غير الآمن) موضحة بلغة بسيطة.
ما لا ستحصل عليه هو درس Rust كامل أو جولة كاملة في الصياغة أو إعداد مشروع خطوة بخطوة. فكر في هذا كـ"لماذا" وراء تصميم Rust، مع أمثلة موجزة لجعل الأفكار ملموسة.
ملاحظة الكاتب: القطعة الكاملة تستهدف نحو 3000 كلمة، تاركة مجالًا لأمثلة قصيرة دون أن تتحول إلى دليل مرجعي.
لم تبدأ Rust كلغة مصممة بواسطة لجنة لتكون "C++ التالية". بدأت كتجربة شخصية لغرايدون هور في 2006—عمل تابع له مستقلاً قبل أن يجذب انتباهًا أوسع. هذا الأصل مهم: كثير من قرارات التصميم الأولى تبدو كحلول لأوجاع يومية، وليس كجهد "لنيل" نظرية لغات.
كان هور يستكشف كيف يكتب برمجيات منخفضة المستوى وعالية الأداء دون الاعتماد على جامع قمامة—مع تجنّب أكثر مسببات الأعطال والثغرات في C و C++. التوتر هنا مألوف لمطوري الأنظمة:
اتجاه Rust "أمان الذاكرة بدون جامع" لم يكن مجرد شعار تسويقي في البداية. كان هدفًا تصميميًا: الحفاظ على خصائص الأداء المناسبة للعمل الأنظامي، مع جعل فئات كثيرة من أخطاء الذاكرة صعبة التعبير.
من المعقول التساؤل لماذا لم تكن هذه "مجرد مترجم أفضل" لـ C/C++. أدوات مثل التحليل الساكن، وsanitizers، والمكتبات الأكثر أمانًا تمنع الكثير من المشاكل، لكنها عمومًا لا تستطيع الضمان الكامل لأمان الذاكرة. اللغات الأساسية تسمح بأنماط يصعب أو يستحيل ضبطها بالكامل من الخارج.
رهان Rust كان نقل قواعد رئيسية إلى اللغة ونظام الأنواع بحيث يصبح الأمان نتيجة افتراضية، مع السماح بالتحكم اليدوي في مخارج محددة وواضحة.
بعض تفاصيل الأيام الأولى لـ Rust تدور كحكايات تُعاد مرارًا في المحاضرات والمقابلات. عند سرد هذه القصة، من المفيد فصل المعالم الموثقة على نطاق واسع—مثل بدء المشروع في 2006 وتبني موزيلا لاحقًا—عن الذكريات الشخصية والسرد الثانوي.
للمصادر الأولية، ابحث عن وثائق Rust المبكرة وملاحظات التصميم، محادثات/مقابلات غرايدون هور، ومنشورات حقبة موزيلا/سيرفو التي تصف سبب استلام المشروع وكيف صيغت أهدافه. قسم "قراءة إضافية" جيد يمكن أن يوجّه القراء إلى هذه الأصول (انظر /blog للروابط ذات الصلة).
برمجة الأنظمة غالبًا ما تعني العمل قريبًا من العتاد. هذه القربّة هي ما يجعل الكود سريعًا وفعّالًا في استخدام الموارد. لكنها أيضًا ما يجعل أخطاء الذاكرة مؤذية للغاية.
بعض الأخطاء الكلاسيكية تتكرر مرارًا:
هذه الأخطاء ليست دائمًا واضحة. قد يعمل البرنامج "أسابيع" ثم يتعطل فقط تحت نمط توقيت أو إدخال نادر.
الاختبار يبرهن أن شيء ما يعمل للحالات التي جربتها. أخطاء الذاكرة كثيرًا ما تختبئ في الحالات التي لم تجربها: إدخالات غير عادية، عتاد مختلف، تغيّر طفيف في التوقيت، أو إصدار مترجم جديد. يمكن أن تكون غير حتمية خاصة في البرامج متعددة الخيوط—فتختفي المشكلة عند إضافة تسجيل أو ربط مصحح الأخطاء.
عندما يخطئ النظام في الذاكرة، لا تحصل على خطأ نظيف فحسب. تحصل على حالة مفسدة، أعطال غير متوقعة، وثغرات أمنية يبحث عنها المهاجمون بنشاط. تصرف الفرق جهدًا هائلًا لتعقب أعطال يصعب إعادة إنتاجها وتشخيصها.
البرمجيات منخفضة المستوى لا تستطيع دائمًا "دفع ثمن" الأمان بفحوصات زمن تشغيل مكثفة أو مسحات ذاكرة مستمرة. الهدف أقرب إلى استعارة أداة من ورشة مشتركة: يمكنك استخدامها بحرية، لكن القواعد يجب أن تكون واضحة—من يملكها، من يمكنه مشاركتها، ومتى تُعاد. لغات الأنظمة تقليديًا تركت هذه القواعد للتأديب البشري. تبدأ قصة أصل Rust بالتشكيك في هذا المقايضة.
جامع القمامة وسيلة شائعة تمنع أخطاء الذاكرة: بدل أن تحرر الذاكرة يدويًا، يتتبع وقت التشغيل أي الكائنات ما زالت قابلة للوصول ويستعيد الباقي تلقائيًا. هذا يلغي فئات كاملة من المشاكل—use-after-free، double-free، والعديد من التسريبات—لأنه يصعب على البرنامج "نسيان" التنظيف بنفس الطريقة.
جامع القمامة ليس "سيئًا"، لكنه يغيّر ملف الأداء للبرنامج. معظم الجامعات تضيف مزيجًا من:
بالنسبة لتطبيقات مثل الخلفيات، برامج الأعمال، أو أدوات التطوير، قد تكون هذه التكاليف مقبولة أو غير مرئية. الجامعات الحديثة ممتازة وتزيد إنتاجية المطورين بشكل كبير.
في برمجة الأنظمة، الأسوأ قد يكون المهم. يحتاج محرك المتصفح إلى رسم سلس؛ قد يكون لمتحكم مدمج قيود زمنية صارمة؛ قد يتم ضبط خادم زمن الوصول المنخفض للحفاظ على الكمون الطرفي تحت الحمل. في هذه البيئات، "سريع عادةً" يمكن أن يكون أقل قيمة من "متوقع باستمرار".
الوعد الكبير لـ Rust كان: حافظ على تحكم شبيه بـ C/C++ في الذاكرة وتخطيط البيانات، لكن قدم أمان الذاكرة دون الاعتماد على جامع قمامة. الهدف هو خصائص أداء متوقعة بينما تجعل الشفرة الآمنة الخيار الافتراضي.
هذا ليس حجة أن الجامعات أقل قيمة. إنه رهان على وجود مساحة متوسطة مهمة: برامج تحتاج تحكمًا منخفض المستوى ومع ضمانات أمان حديثة.
الملكية هي أبسط فكرة كبيرة في Rust: لكل قيمة مالك واحد مسؤول عن تنظيفها عندما لا تعود مطلوبة.
تستبدل تلك القاعدة الكثير من تتبع "من يحرر هذه الذاكرة؟" اليدوي الذي كان مطوري C/C++ يحتفظون به في رؤوسهم. بدلًا من الاعتماد على الانضباط، تجعل Rust التنظيف متوقعًا.
عندما تنسخ شيئًا، تحصل على نسختين مستقلتين. عندما تنقل شيئًا، تسلّم الأصل—وبعد النقل لا يَسمح للمتغير القديم باستخدامه.
تعامل Rust العديد من القيم المخصصة على الكومة (مثل السلاسل، البافرات، أو المتجهات) على أنها تُنقل افتراضيًا. نسخها بلا تمييز قد يكون مكلفًا، والأهم مربكًا: إذا ظن متغيران أنهما "مالكان" لنفس التخصيص ستكون قد مهدت الطريق لأخطاء الذاكرة.
فيما يلي الفكرة في شيفرة توضيحية قصيرة (محصورة داخل كتلة كود):
buffer = make_buffer()
ownerA = buffer // ownerA owns it
ownerB = ownerA // move ownership to ownerB
use(ownerA) // not allowed: ownerA no longer owns anything
use(ownerB) // ok
// when ownerB ends, buffer is cleaned up automatically
لأن هناك دائمًا مالكًا واحدًا، تعرف Rust بالضبط متى ينبغي تنظيف القيمة: عندما يخرج مالكها من النطاق. هذا يعني إدارة ذاكرة تلقائية (لا تستدعي free() في كل مكان) دون الحاجة إلى جامع قمامة يمسح البرنامج ويستعيد الذاكرة عند التشغيل.
تمنع قاعدة الملكية فئة كبيرة من المشاكل الكلاسيكية:
نموذج الملكية في Rust لا يشجع فقط عادات أكثر أمانًا—بل يجعل حالات كثير من الحالات غير الآمنة غير قابلة للتمثيل، وهو أساس بقية ميزات الأمان في Rust.
الملكية تفسر من يملك القيمة. الاقتراض يشرح كيف يمكن لأجزاء أخرى من البرنامج استخدامها مؤقتًا دون أخذها.
عندما تقترض شيئًا في Rust، تحصل على مرجع إليه. يظل المالك الأصلي مسؤولًا عن تحرير الذاكرة؛ المقترض يحصل فقط على إذن لاستخدامها لفترة.
لدى Rust نوعان من الاقتراض:
&T): وصول للقراءة فقط.&mut T): وصول للقراءة والكتابة.قاعدة الاقتراض المركزية سهلة القول وفعّالة في التطبيق:
تمنع هذه القاعدة فئة شائعة من الأخطاء: جزء من البرنامج يقرأ البيانات بينما يغيرها جزء آخر من تحته.
المرجع آمن فقط إذا لم يتجاوز العمر الزمنية للشيء المشار إليه. تسمي Rust تلك المدة فترة الحياة—الزمن الذي يكون المرجع مضمونًا خلاله.
لا تحتاج إلى رسمية كبيرة لاستخدام هذه الفكرة: يجب ألا يبقى المرجع بعد مالكه.
تفرض Rust هذه القواعد في وقت الترجمة عبر مدقق الاقتراض. بدل أن تعتمد على الاختبارات لإيجاد مرجع سيء أو تعديل خطير، ترفض Rust بناء شفرة قد تستخدم الذاكرة بشكل غير صحيح.
فكر في مستند مشترك:
التزامن هو المكان الذي تختبئ فيه أخطاء "يعمل على جهازي". عندما تعمل خيوطان في نفس الوقت، يمكن أن تتفاعل بطرق مفاجئة—خاصة عند مشاركة البيانات.
سباق البيانات يحدث عندما:
النتيجة ليست مجرد مخرج خاطئ؛ قد تُفسد الحالة، يتعطل البرنامج، أو تظهر ثغرات أمنية. والأسوأ أن تكون منقطعة الحدوث: قد تختفي عند إضافة تسجيل أو تشغيل المصحح.
تتخذ Rust موقفًا غير مألوف: بدل الوثوق بكل مبرمج لتذكر القواعد في كل مرة، تحاول جعل أنماط التزامن غير الآمنة غير قابلة للتمثيل في الشفرة الآمنة.
على مستوى عالٍ، قواعد الملكية والاقتراض لا تتوقف عند الشفرة أحادية الخيط. تشكّل أيضًا ما يُسمح بمشاركته عبر الخيوط. إذا لم يستطع المترجم البرهان أن المشاركة منظمة، فلن يسمح بترجمة الشفرة.
هذا ما يقصده الناس بـ "التزامن الآمن" في Rust: لا تزال تكتب برامج متزامنة، لكن فئة كاملة من أخطاء "آه، خيطان كتبا نفس الشيء" تُكتشف قبل تشغيل البرنامج.
تخيل خيطين يزيدان نفس العداد:
Rust لا يحظر حيل التزامن منخفضة المستوى. بل يعزلها. إذا احتجت فعلًا لشيء لا يستطيع المترجم التحقق من سلامته، يمكنك استخدام كتل unsafe، التي تعمل كملصقات تحذير: "مسؤولية بشرية هنا". هذا الفصل يحافظ على معظم القاعدة البرمجية في النطاق الآمن بينما يتيح القوة المطلوبة حيث تستدعي الحاجة.
سمعة Rust في الأمان قد تبدو مطلقة، لكنها أدق عندما نقول أن Rust توضح الحد الفاصل بين البرمجة الآمنة وغير الآمنة—وتسهّل مراجعته.
معظم شفرات Rust هي "آمنة". هنا، يفرض المترجم قواعد تمنع أخطاء الذاكرة الشائعة: use-after-free، double-free، المؤشرات المعلقة، وسباقات البيانات. لا يزال بإمكانك كتابة منطق خاطئ، لكن لا يمكنك بالميزات العادية كسر سلامة الذاكرة بطريق الخطأ.
نقطة مهمة: Rust الآمنة ليست "أبطأ Rust". العديد من البرامج عالية الأداء تُكتب بالكامل بـ Rust الآمنة لأن المترجم يمكنه إجراء تحسينات قوية عندما يثق بأن القواعد مطبّقة.
وجود unsafe لأن برمجة الأنظمة أحيانًا تحتاج قدرات لا يستطيع المترجم برهان سلامتها بشكل عام. الأسباب النموذجية تشمل:
استخدام unsafe لا يلغي كل الضوابط؛ بل يسمح بمجموعة محدودة من العمليات (مثل فك مؤشرات خام) التي كانت ممنوعة سابقًا.
تجبر Rust على وسم الكتل والدوال غير الآمنة، مما يجعل الخطر واضحًا في مراجعات الشيفرة. نمط شائع هو الاحتفاظ بـ "جوهر" غير آمن صغير ملفوف بواجهة آمنة، لذلك تبقى معظم قاعدة الشيفرة في نطاق Rust الآمنة بينما يضمن جزء صغير الحفاظ على الفرضيات اللازمة.
عامل unsafe كأداة قوية:
unsafe صغيرة ومحددة.عند استخدامها جيدًا، تصبح Rust غير الآمنة واجهة محكومة للأجزاء التي تحتاج دقة يدوية—دون التنازل عن فوائد الأمان في بقية المشروع.
لم تصبح Rust "حقيقية" لأن لديها أفكارًا ذكية على الورق—بل لأن موزيلا ساعدت على اختبار تلك الأفكار تحت ضغط واقعي.
أبحاث موزيلا كانت تبحث عن طرق لبناء مكونات متصفح حرجة للأداء مع أخطاء أمنية أقل. محركات المتصفح معقدة جدًا: تعالج مدخلات غير موثوقة، تدير كميات هائلة من الذاكرة، وتعمل بأحمال متوازية. هذا المزيج يجعل عيوب أمان الذاكرة وسباقات البيانات شائعة ومكلفة.
دعم موزيلا لـ Rust تماشى مع هذا الهدف: الحفاظ على سرعة برمجة الأنظمة مع تقليل فئات كاملة من الثغرات. كما أن مشاركة موزيلا أعطت إشارة للعالم أن Rust ليست مجرد تجربة شخصية لغرايدون هور، بل لغة يمكن تجربتها على أحد أصعب قواعد الشيفرة على الكوكب.
أصبح مشروع محرك المتصفح التجريبي Servo مكانًا بارزًا لتجربة Rust على نطاق. لم يكن الهدف "اقتحام" سوق المتصفحات. عمل سيرفو كمختبر حيث يمكن تقييم ميزات اللغة، تشخيصات المترجم، وأدوات التطوير وفقًا لقيود حقيقية: أزمنة البناء، الدعم عبر المنصات، تجربة المطور، ضبط الأداء، والصحة تحت التوازي.
وبشكلٍ مهم، ساهم سيرفو أيضًا في تشكيل منظومة اللغة: المكتبات، أدوات البناء، الاتفاقيات، وممارسات التصحيح التي تهم حين تنتقل من برامج تجريبية إلى مشاريع حقيقية.
المشروعات الواقعية تخلق حلقات تغذية راجعة لا يمكن لتصميم اللغة تقليدها. عندما يصطدم المهندسون بصعوبات—رسائل خطأ غير واضحة، مكتبات ناقصة، أنماط محرجة—تظهر نقاط الألم بسرعة. مع الزمن، ساعد هذا الضغط المستمر Rust على النضوج من مفهوم واعد إلى شيء يمكن للفرق الوثوق به لبناء برمجيات حرجة الأداء.
إذا أردت استكشاف تطور Rust بعد هذه المرحلة، انظر /blog/rust-memory-safety-without-gc.
تقف Rust في وسط فاصل: تسعى لتحقيق أداء وتحكم متوقعين كما في C و C++، لكنها تحاول إزالة فئة كبيرة من الأخطاء التي تتركها تلك اللغات للتأدب، الاختبار، والحظ.
في C و C++، يدير المطورون الذاكرة مباشرةً—التخصيص، التحرير، والتأكد من بقاء المؤشرات صحيحة. تلك الحرية قوية لكنها تجعل من السهل خلق use-after-free و double-free وbuffer overflows وأخطاء فترات الحياة. المترجم عمومًا يثق بك.
تقلب Rust هذه العلاقة. لا تزال تحصل على تحكم منخفض المستوى (قرارات الستاك مقابل الهيب، تخطيطات متوقعة، نقل واضح للملكية)، لكن المترجم يفرض قواعد حول من يملك القيمة وإلى متى يمكن أن تعيش المراجع. بدلًا من "كن حذرًا مع المؤشرات"، تقول Rust "أثبت الأمان للمترجم"، ولن يترجم الشيفرة التي قد تكسر هذه الضمانات في Rust الآمنة.
لغات الجامع القمامة (مثل Java، Go، C#، أو لغات البرمجة النصية) تتاجر بالتحكم اليدوي من أجل الراحة: تُفنى الكائنات تلقائيًا عندما لا تكون قابلة للوصول. هذا قد يكون دفعة إنتاجية كبيرة.
وعد Rust—"أمان الذاكرة بدون جامع"—يعني أنك لا تدفع ثمن جامع قمامة وقت التشغيل، ما يساعد حين تحتاج دقة في الكمون، حجم الذاكرة، وقت البدء، أو تشغيل في بيئات مقيدة الموارد. المقايضة هي أنك تصف الملكية صراحة وتدع المترجم يفرضها.
قد يبدو Rust أصعب في البداية لأنها تعلم نموذجًا ذهنيًا جديدًا: التفكير بمصطلحات الملكية، الاقتراض، وفترات الحياة، بدلًا من "مرّر مؤشرًا واطمئن". يظهر الاحتكاك الأولي كثيرًا عند نمذجة حالة مشتركة أو رسوم كائنات معقدة.
تتفوق Rust عادة للفرق التي تبني برمجيات حساسة للأمن والحساسة للأداء—متصفحات، شبكات، التشفير، المدمج، وخدمات خلفية تحتاج موثوقية صارمة. إذا كانت فريقك يفضل أسرع تكرار على التحكم منخفض المستوى، فقد تظل لغة بجامع قد تكون الخيار الأفضل.
Rust ليست بديلًا عالميًا؛ إنها خيار قوي عندما تريد أداء شبيه بـ C/C++ مع ضمانات أمان يمكن الاعتماد عليها.
لم تجذب Rust الانتباه بكونها "C++ ألطف". غيّرت الحديث من خلال إصرارها أن الكود منخفض المستوى يمكن أن يكون سريعًا، آمنًا للذاكرة، وصريحًا بشأن التكاليف في الوقت نفسه.
قبل Rust، اعتادت الفرق أن تعامل أخطاء الذاكرة كضريبة مقابل الأداء، ثم تعتمد على الاختبار، مراجعة الشيفرة، والتصحيحات بعد الحوادث لإدارة المخاطر. جعلت Rust رهانًا مختلفًا: تشفير قواعد شائعة (من يملك البيانات، من يغيرها، متى تظل صالحة) داخل اللغة بحيث تُرفض فئات كاملة من الأخطاء في وقت الترجمة.
هذا التحول كان مهمًا لأنه لم يطلب من المطورين أن يكونوا "مثاليين". طلب منهم أن يكونوا واضحين—ثم يدع المترجم يفرض تلك الوضوح.
تظهر تأثيرات Rust في مزيج من الإشارات أكثر منها عنوانًا واحدًا: اهتمام متزايد من شركات تشحن برمجيات حساسة للأداء، زيادة وجودها في مقررات جامعية، وأدوات تبدو أقل "مشروع بحثي" وأكثر "أداة يومية" (إدارة الحزم، التنسيق، التنبيهات، وعمليات التوثيق تعمل مباشرة).
لا يعني هذا أن Rust دائمًا الخيار الأفضل—لكن يعني أن الأمان كخاصية افتراضية صار توقعًا واقعيًا، لا مجرد امتياز.
كثيرًا ما تُقيَّم Rust من أجل:
لا يعني "المعيار الجديد" أن كل نظام سيُعاد كتابته بـ Rust. يعني أن المعيار تحرّك: الفرق تسأل أكثر فأكثر، لماذا نقبل افتراضات غير آمنة للذاكرة عندما لا نحتاج لذلك؟ حتى عندما لا تُعتمد Rust، دفعت نموذجها النظام البيئي لتفضيل واجهات آمنة، فروض أكثر وضوحًا، وأدوات أفضل للصحة correctness.
إذا أردت المزيد من قصص الهندسة الخلفية مثل هذه، تصفح /blog للمنشورات ذات الصلة.
قصة أصل Rust تحمل خطًا بسيطًا: مشروع جانبي لشخص واحد (تجربة غرايدون هور للغة جديدة) اصطدم بمشكلة برمجة أنظمة عنيدة، وكان الحل صارمًا وعمليًا في الوقت نفسه.
إعادة صياغة مقايضة اعتبرها كثيرون حتمية:
التحول العملي ليس مجرد "Rust أكثر أمانًا". إنه أن الأمان يمكن أن يكون خاصية افتراضية للغة بدلًا من انضباط يُحكم عبر المراجعات والاختبارات.
إذا كنت فضوليًا، لست بحاجة لإعادة كتابة ضخمة حتى تتعرف على شعور Rust:
إذا أردت طريقًا لطيفًا، اختر هدفًا "شريحة رقيقة"—مثلاً "اقرأ ملفًا، حوّله، اكتب المخرجات"—وركّز على كتابة شفرة واضحة بدلًا من شيفرة ذكية. إذا كنت تدرِّج مكوّن Rust داخل منتج أكبر، قد يساعدك إبقاء الأجزاء المحيطة سريعة (واجهة إدارة، لوحات، طائرة التحكم) بينما تجعل منطق الأنظمة الصارم بـ Rust.
منصات مثل Koder.ai يمكن أن تُسرّع هذا النوع من تطوير "الغراء" عبر سير عمل محادثي—تمكينك من توليد واجهات React، خوادم Go، ومخططات PostgreSQL بسرعة، ثم تصدير المصدر والتكامل مع خدمتك المكتوبة بـ Rust عبر حدود واضحة.
إذا رغبت في منشور ثانٍ، ما سيكون الأكثر فائدة؟
unsafe بمسؤولية في مشاريع حقيقيةردّ مع سياقك (ما تبنيه، ما اللغة الحالية لديك، وما الذي تحاول تحسينه)، وسأصيغ الفصل التالي وفقًا لذلك.
برمجة الأنظمة هي عمل قريب من مستوى العتاد ومناطق المنتج عالية المخاطر — مثل محركات المتصفح، قواعد البيانات، مكونات نظام التشغيل، الشبكات، والبرمجيات المدمجة.
عادةً ما تتطلب هذه البيئات أداءً متوقعًا، تحكمًا منخفض المستوى في الذاكرة والبنية، وموثوقية عالية حيث تكون الأعطال والثغرات الأمنية مكلفة للغاية.
يعني أن Rust تهدف إلى منع أخطاء الذاكرة الشائعة (مثل use-after-free و double-free) بدون الاعتماد على جامع قمامة وقت التشغيل.
بدلاً من قيام جامع القمامة بمسح الذاكرة وجمعها أثناء تشغيل البرنامج، تدفع Rust كثيرًا من قواعد الأمان إلى وقت الترجمة عبر قواعد الملكية والاقتراض.
أدوات مثل المحللات الساكنة وsanitizers يمكنها أن تكتشف الكثير من المشاكل، لكنها نادرًا ما تستطيع أن تضمن أمان الذاكرة عندما تسمح اللغة بأنماط مؤذية في المؤشرات وفترات الحياة.
Rust تبني قواعد أساسية داخل اللغة ونظام الأنواع حتى يقدر المترجم على رفض فئات كاملة من الأخطاء افتراضيًا، مع توفير مخارج واضحة عندما تكون هناك حاجة لاستثناءات مقصودة.
جامع القمامة قد يضيف حملًا في وقت التشغيل، والأهم أنه قد يغيّر خصائص الكمون ويضيف فترات توقف أو عمل جمع في أوقات غير متوقعة.
في مجالات مثل المتصفحات أو المتحكمات في الزمن الحقيقي أو خدمات زمن الوصول المنخفض، سلوك أسوأ حالات التشغيل مهم جدًا، لذا تستهدف Rust الأمان مع الحفاظ على خصائص أداء أكثر توقعًا.
الملكية تعني أن كل قيمة لها «مالك» واحد مسؤول عن تنظيفها عندما لا تعود مطلوبة.
عندما يخرج المالك من النطاق، تُنظف القيمة تلقائيًا. هذا يجعل عملية التنظيف متوقعة ويمنع حالات حيث يعتقد موقعان أنهما مالكان لنفس الذاكرة.
الـ"نقل" ينقل الملكية من متغير إلى آخر؛ لا يمكن للمتغير الأصلي استخدام القيمة بعد النقل.
هذا يمنع حادثة وجود «مالكين اثنين لنفس التخصيص»، وهي سبب شائع لخطأ double-free و use-after-free في لغات الذاكرة اليدوية.
الاقتراض يسمح للشفرات باستخدام قيمة مؤقتًا عبر مراجع دون أخذ الملكية.
القاعدة الأساسية: قراء متعددون أو كاتب واحد — يمكنك أن تملك مراجع مشاركة متعددة (&T) للقراءة فقط، أو مرجعًا وحيدًا قابلًا للتغيير (&mut T) للقراءة-الكتابة، لكن ليس كلا النوعين في الوقت نفسه. هذا يمنع فئة واسعة من أخطاء التعديل أثناء القراءة والاقترانات الخاطئة.
الفترة (lifetime) هي "مدة صلاحية المرجع". يجب ألا يعيش المرجع بعد الشيء الذي يشير إليه.
مدقق الاقتراض (borrow checker) يتحقق من ذلك في وقت الترجمة، فيرفض الشفرات التي قد تنتج مراجع معلقة قبل تشغيل البرنامج.
سباق البيانات يحدث عندما يصل أكثر من مؤشر إلى نفس الذاكرة في وقت واحد، على الأقل أحدهما يكتب، ولا يوجد تنسيق أو قفل لتنظيم التوقيت.
قواعد الملكية والاقتراض في Rust تمتد إلى البرمجة المتزامنة أيضًا؛ فإذا لم يستطع المترجم البرهان أن المشاركة منظمة، فلن يسمح بترجمة الشفرة. هذا يدفعك لاستخدام بنى تزامن واضحة (قفل، أو تمرير رسائل) ويجعل فئة من أخطاء سباقات البيانات غير قابلة للتعبير في الشفرة الآمنة.
معظم الشفرة تُكتب بـ "Rust الآمنة" حيث يفرض المترجم قواعد تمنع أخطاء الذاكرة الشائعة.
unsafe هو مخرج مرئي وواضح للعمليات التي لا يستطيع المترجم برهان سلامتها عمومًا (مثل بعض استدعاءات FFI أو التعامل مع مؤشرات خام). ممارسة شائعة هي إبقاء كتل unsafe صغيرة ومغلفة بواجهات آمنة، ما يجعلها أسهل للمراجعة والاختبار.