Rust for Python developers

توی ۷-۸ روز اخیر پروژه لینوکس کرنل یک مینتینرهایی رو داشت از دست میداد که نباید (لاشخورها هم نشسته بودن رو هوا بزنند‌ها؛ ویندوز و مک) بگذریم. کار به جایی رسید که اومدن برای این موضوع قانون گذاری کردند.
https://rust-for-linux.com/

مثل سری قبلی نظرات شخصی هم داشت وارد می‌شد؛ که بعضی مینتینرها داشتن می‌کفتند نمی‌خواند کد Rust ببینند و Accept کنند چون ممکنه باعث باگ بشه؛ توسعه دهنده‌های Rust که توی برخی موارد مینتینر بخش‌های دیگری از کرنل هم هستند با حفظ سمت داشتن می‌کفتند که بابا ما این کد Rust رو برای شما زدیم چون باگهای مموری شما مارو سرویس کرده و همین بحث که ما اضاقه نمی‌کنیم چون ممکنه باعث باگ بشه؛ اوناهم که خب چون باگ داری و توان فیکس ندارید ما کد دونیت کردیم و این شده بود یک loop تا قانون اضافه شد.

الان مشخص شده همین قانون هم خودش یک سلسله ایمیلی بوده (راستی همه‌ی ایمیل‌های بحث‌های توسعه کرنل لینوکس بطور کامل روی kernel.org هست؛ بعله حتی فحش ناموسی‌هایی که به دولوپر تازه‌کارا سر اشتباهاتشون دادن؛ اکثرا هم کار خود لینوس هستا؛ حالا ما اینجا به دولوپر میگیم بیشتر دقت کن گریه می‌کنه میره خونشون یا با اولیاش میاد)

داستان اینه لینوس شخصا می‌دونه که Rust باید بیاد توی کرنل چون باعث پیشرفت می‌شه و از رقیبا عقب نمیوفته ولی بعضی از مینتینرهای قدیمی که نمی‌تونند Rust رو یاد بگیرند دارند احمقانه باهاش مبارزه می‌کنند. (از حق نگذریم حدود ۱۰٪ هم حق دارند و منطقی توضیح می‌دهند که باید توی فلان بخش فعلا روی C بمونیم)؛ یک گروه دیگه هم هستند منطقی‌های C بلد که میگن کدهای اصلی که روی C نوشته شده بذاریم باشه (بالای ۳۰ میلیون خط کد هست کرنل) ولی کدهای جدید و ... رو باید بریم روی Rust اگر کسی توی دنیای Rust گردن نگرفت با C میزنیم و مثال هایی هم هست که توسعه Rust هفته‌ها جلوتر از C بوده مخصوصا برای سخت‌افزارهای جدید چون باگ کمتر داشته و کد زدن توی Rust برای سخت‌افزار به مراتب سریعتر از C هست؛ و خب بنظرم صحبت‌های این دسته ۱۰۰٪ منطقی هست ولی با همینم مخالفت می‌کنند.

دسته دیگری هم هستن که با دیتا صحبت می‌کنند؛ که بیشترین مشکل ما توی باگ‌هایی که باعث نفوذ به سرور شده توی 15+ سال قبل همش مربوط به مدیریت مموری توی C و خطای دولوپر بوده (اینا بهترین دلوپرهای دنیا هستنا) پس منطقی هست که سعی کنیم بریم سراغ Rust بدون شک و تردید در آینده باید این اتفاق بیوفته اینا با اینکه توسعه دهنده Rust نیستند ولی به اندازه تیم توسعه لینوکس کرنل با Rust موافق اضافه شدن Rust به کرنل هستند و کامل حمایت می‌کنند.

دعوا شدیدا بالا گرفته و نظرات شخصی خیلی خیلی داره روی کرنل لینوکس و البته آینده کاربرهاش تاثیر میذاره و بازم من با سخنرانی حذف شده یکی از maintainer های قبلی اشاره می‌کنم که این مزمون رو داشت (بعد از۳۵ دقیقه کل‌کل توی سخنرانیش) :

توی تیم Kernel فسیل‌های احمق و خودخواهی هستند که چون شعور و قدرت یادگیری زبان جدید (Rust) رو ندارند حاضرند این دستاورد (منظور پیشرفت‌های لینوکس بعد از سال‌ها و ورود بیشترش به دنیای دسکتاپ هست) رو با خودشون به نابودی ببرند.

این توی یکی از سخنرانی‌ها بود؛ موج اول خدافظی از Linux Rust Kernel رو بهمراه داشت؛ سخنرانی بعد ازین بحث تموم شد و ویدئو این بخش هم از یوتیوبشون حذف شد (اون روز بحث کردیم راجبش).

فعلا شخص لینوس تروالدز وارد شده و بنظر می‌رسه خودش موضوعات مربوط به Rust رو گردن بگیره که بسیار بسیار خوشحال کننده هست ولی کاش زودتر بود.

پینوشت:

کدی که سرش این دعوا اخیر بوجود اومد تایید شده و maintainer مخالف از این بخش (کل نه‌ها فقط همین بخش) حذف شد؛ دلیلشم این بود که مخالفتش غیر منطقی بوده (خود لینوس تروالدز این کدپ رو تایید کرده)

Rust 1.85.0:

بهترین چیزی که اضافه شده بنظرم؛ async closure هست.

let mut vec: Vec<String> = vec![];

let closure = async || {
    vec.push(ready(String::from("")).await);
};

#5min_Rust

درنهایت نکات مهمی که راجب Stack باید یادتون بمونه :

۱- سرعت بالاتری داره نسبت به heap؛ چون برای دیتاهاش نیازی نداره به سیستم عامل بگه براش حافظه پیدا کنه ( system call کمتری داره )
۲- داده‌هایی می‌تونند روی Stack قرار بگیرند که از قبل سایزشون مشخص باشه؛ یعنی بدونیم چقدر فضای حافظه رو نیاز دارند.
۳- نمی‌تونیم از یک تابع به داده‌ای داخل تابع دیگر که روی استک هست اشاره کنیم؛ چون همونطور که دیدیم وقتی اجرا اون بخش کد تموم بشه تمام مقادیر از Stack حذف میشه و ما می‌مونیم و اشاره‌گر به خانه حافظه‌ای که یا خالی هست یا نباید بهش اشاره می‌شده و این موضوع امن نیست.

#5min_Rust

خب توی این مثال؛ اول از همه یک مقدار حافظه از Stack به تابع main اختصاص داده می‌شه؛ توی اولین دستور داخل main یک متغییر داریم به اسم a و مقدار 22 که داخل Stack قرار می‌گیره (نوع داده int چون سایزش زمان کامپایل مشخص هست همیشه داخل stack قرار میگیره)

بعد از اون برای بدست آوردن مقدار b باید تابع دیگری صدا زده بشه؛ که اینبار add_one هست و یک فضای اختصاصی روی Stack بهش داده می‌شه؛ و کاری که می‌کنه اینه که ورودی رو +1 می‌کنه و برای کسی که صداش زده برمی‌گردونه پس یک متغییر به اسم i داره که آرگومان ورودی تابع هست و توی استک قرار میگیره و خروجی هم توسط return برای آدرس b توی main ارسال میشه 0x23f توی این مثال؛ توی این بازه که داشتیم روی add_one کار میکردیم پشت صحنه SP هم جابجا شد و بجای اینکه به آخر main روی stack اشاره کنه به انتهای آدرس add_one اشاره میکرد.
وقتی کارمون با تابع add_one تموم شد و مقدارش رو برگردوندیم؛ این بخش از Stack حذف میشه؛ باتمام متغییرها و مقادیری که توی این بخش بود (درک این موضوع به lifetime, ownership, ... کمک می‌کنه پس یادتون بمونه)
و SP دوباره بر میگرده و انتهای main رو نشون میده و b 23 داخل استک main قرار میگیره.

بعد از اون متغییر answer_universe رو داریم؛ این مقدار رو چون می‌خواستیم بمونه و با حذف Stack پاک نشه تصمیم گرفتیم بفرستیمش روی Heap اما یادتون باشه بالاتر گفتم int روی stack جا داره چون سایزش از قبل معلوم هست؛ برای اینکه به زور ببریمش روی Heap از چیزی به اسم Box استفاده می‌کنیم (درآینده راجبش حرف میزنم)

وقتی on_heap صدا زده میشه؛ استک فقط و فقط شامل main هست و add_one حذف شده ازش (توی تصویر نمی‌شد این رو نشون داد) on_heap داخل خودش b رو داره (آپدیت کردن SP یادمون نرفته فقط دوباره توضحیش نمیدم) و b رو میخوایم روی heap بفرستیم پس به سیستم درخواست میدیم یک فضایی به اندازه i32 نوع داده integer 32bit برامون روی heap پیدا کنه و بهمون بده وقتی سیستم این رو پیدا کرد دیتای 42 رو اونجا مینوسه و آدرسش 0x5f21 رو بهمون بر میگردونه و بعد هم که return , ....

بعد از این مرحله تابع on_heap هم از روی stack حذف میشه و فقط main ‌می‌مونه روی main چون answer_universe هنوز به دیتای 42 روی heap نیاز داره پس اون دیتاهم روی heap وجود داره.

در نهایت وقتی این کارها تموم شد (اینجا print, ... نداریم) برنامه بطور کامل اجرا شده و main هم تموم می‌شه و تمام مموری پاک میشه.


پینوشت:
منبع نمونه کد بالا؛ این رو قبلا گذاشته بودم بنظرم خوبه دوباره زیر این پست هم باشه.