توی ۷-۸ روز اخیر پروژه لینوکس کرنل یک مینتینرهایی رو داشت از دست میداد که نباید (لاشخورها هم نشسته بودن رو هوا بزنند‌ها؛ ویندوز و مک) بگذریم. کار به جایی رسید که اومدن برای این موضوع قانون گذاری کردند.
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 مخالف از این بخش (کل نه‌ها فقط همین بخش) حذف شد؛ دلیلشم این بود که مخالفتش غیر منطقی بوده (خود لینوس تروالدز این کدپ رو تایید کرده)

#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 هم تموم می‌شه و تمام مموری پاک میشه.

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

Fish shell

رو با بازنویسی کامل روی Rust برای نسخه 4 خواهیم داشت.

ازون گیت‌هابای پر از درس هست که خیلی خوب میشه سورس کدش رو خوند.
پروژه Limbo رو که یادتون هست ؟

https://t.me/pyrust/110

fs::read_to_string

باگ خفته، یک سرویس کوچیک داریم که دائم down می‌شه چک می‌کنیم می‌بینیم دقیقا قبلش دیوایس (Edge Device) اونم داره ریستارت میشه.
پس نیرو میره سراغ مشکلات دیوایس؛ این وسط منم رفتم سورس کد بخونم.

اطلاعاتی هم از پروژه و مشکل داشتم و خب چندتا از بچه‌ها گفتن مشکل از دیوایس هست.

توی سورس کد دیدم طرف اینطوری داره فایل رو می‌خونه؛ یک نمونه فایل رو گرفتم (بعد از کرش کردن دستگاه)

دیدم بله، حجم فایل بیشتر از رم دستگاه شده؛ مشکل همین بود.

برای همین توی اکثر آموزش‌های حرفه‌ای از این مورد استفاده نمی‌شه و راه سخت‌تره read, buffer, ... پیش گرفته می‌شه

موضوع فقط بهینه بودن نیست؛ موضوع جلوگیری از کرش کردن هست.

گفتم اینجا هم بگم، شاید یک نفر دیگه رو هم از چندساعت دیباگ نجات داد.

یک چندتا ادیت روی این مورد بدم؛ همونطور که گفتم من تازه داشتم اینجا داکرفایل رو برای پروژه‌ام می‌نوشتم که توی گروه یکی از دوستان سوال پرسید و ترجیح دادم روی نمونه جواب بدم.
اینکه این dockerfile درست هست خوبه یا نه هدف نبود و هدف درک multi\-stage بود.

اما چندتا نکته (بر خلاف دنیای پایتون) :

۱- استفاده از اسم src قطعا اینجا مناسب نیست؛ من حواسم نبود ولی cargo, rustc رو این اسم حساب می‌کنند پس app رو جایگزین کردم

۲- از cargo\-chef استفاده کردم به ۲ دلیل :
۲-۱: توی کد بالا من compile انجام نمیدادم و فقط پکیج‌هارو دانلود میکردم؛ قصدم این بود توی استپ بعدی سراغش برم ولی خب توی بعضی شرایط خاص دردسرش زیاد میشه که الان فرصتش رو نداشتم.
۲-۲: توی همون شرایط و crate های خاص (که اتفاقا یکی از دوستان توی پروژه‌اش بهم نشون داد) باعث میشه قابلیت cache رو از دست بدید؛ دلیل اصلیش رو نمی‌دونم.

۳- بجای استفاده از اداکر ایمیج‌های معرفی شده توسط پروژه cargo\-chef از همون rust:1.82.0 استفاده کردم و فقط یک استیج بیشتر ساختم که دستورات زیر رو داشته باشه :

RUN apt update && apt install lld clang \-y && cargo install cargo\-chef

۴- وقتی sqlx رو توی پروژه دارم؛ توی استیج runtime حتما باید sqlx migrate runtime رو اجرا کنم. (برایحجم کمتر این مورد رو با migrate macro اجرا کردم.

۵- خیلی بهتره موقع استفاده از cargo build —release توی استیج builder باید از فلگ:
—bin
استفاده کنم

نهایتا شد این :

```
FROM rust:1.82.0 AS chef
WORKDIR /app
RUN apt update && apt install lld clang -y && cargo install cargo-chef

FROM chef as planner
COPY . .
RUN cargo chef prepare --recipe-path recipe.json

FROM chef AS builder
COPY --from=planner /app/recipe.json recipe.json
RUN cargo chef cook --release --recipe-path recipe.json
COPY . .
ENV SQLX_OFFLINE true
RUN cargo build --release --bin XYZ

FROM debian:bookworm-slim AS runtime
WORKDIR /app
RUN apt update -y \
&& apt install -y --no-install-recommends openssl ca-certificates \
&& apt autoremove -y \
&& apt clean -y \
&& rm -rf /var/lib/apt/lists/*
COPY --from=builder /app/target/release/XYZ XYZ
COPY .env .env
ENTRYPOINT [ "./XYZ" ]
```

بگذارید هرکس به آیین خودش باشد.
زنان را گرامی بدارید.
فرودستان را دریابید.
اجازه دهید هرکسی به تکلم قبیله‌ی خویش سخن بگوید.

آدمی تنها در مقام خویش به منزلت خواهد رسید.

۷ آبان روز بزرگداشت کوروش کبیر، همایون باد.

اگر خواستید یکی رو آزار بدید
بهش بگید

Red\-Black Tree

رو توی Rust پیاده سازی کنه

فکر کنم این عذاب برنامه‌نویس‌های جهنمی باشه ??