لحظه نوشتن متن بالا مثال خوبی برای static یادم نیومد.
اما گفتم یکی از استفاده‌هاش برای Singleton هست؛ برای مثال اینجا مطمئن میشم همه تست‌ها فقط یکبار اجازه صدا زدن کد رو دارند.

نمیدونم چرا این کتاب رو نخوندم و ندیده بودم (سرفصل‌هاش رو)

بسیار کتاب جذاب و خوبی هست؛ بله درسته با Rust 2018 هست ولی واقعا مهم نیست.
متوجه شدم یکی از دوستانی که توی گوگل دارم؛ تغییر Stack داده از C به Rust ایشون توی تیم کروم بودند.
کلی باهاش صحبت کردم؛ چون توی این مدت بسیار به نوشتن کرنل علاقمند شدم و خودم دارم روش کار می‌کنم (کند پیش میرم چون تسک‌های دیگه دارم ولی پیش میرم.)
ازش خواستم توی این موضوع بهم کمک کنه منابعی که خوندم رو بهش دادم؛ چندتا سوال ازم پرسید (مثل مصاحبه) و بعد این منبع رو بهم داد:
Programming Rust 2nd Edition

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

خیلی سال هست توی دنیای پایتون - هوش مصنوعی بودم؛ توی اون دنیا سرعت تغییراتی که باقی چیزها رو خراب کنه خیلی زیاده (بیش از حد) برای همین منبع ۳ سال قدیمی خیلی به کار نمیاد تازه منابع یادگیری هم خیلی زیاد و راحت در دسترس هست؛ اشتباه کردم با اون دید توی دنیای Rust دنبال منبع گشتم.

حالا اولویتم این کتاب هست؛ تا شنبه بنظرم بتونم ۱۲-۱۳ فصل اول رو بخونم و تمرین کنم.
یا اصطلاح دید یک سری منابع دیگه هم پیدا کردم که زیر این پست میذارم اگر دوست داشتید بررسی کنید.

۱- این از یک دوره اومده که certificate می‌داده برای Rust بنظرم برای مصاحبه خوبه چون تمرینات خوب و سوال جوابای خوبی داره (با اصطلاحات به خوبی آشنا می‌شید)
RustCamp
۲- موارد خیلی مهم مربوط به trait های standard library رو توی این مورد پیدا می‌کنید؛ کسایی که با Rust کمی جدی کد زده باشند می‌دونند که خیلی وقتا باید این موارد رو بشناسی تا برای struct, enum, ... خودت تعریفشون کنی و زندگی رو راحت کنی
Tour of std

۳- از همون نویسنده قیلی این پستش هم خیلی خوبه؛ اشتباهات رایج توی درک Lifetime رو اینجا گفته
Lifetime Misconceptions

۴- از سایت تمرینات راست هم این مورد خیلی خوبه (من تمرین کردن رو از خوندن بیشتر دوس دارم) :
100 Exercises to learn Rust

۵- در نهایت اینم چون از دنیای پایتون اومدم:
Rust-Python interoperability

شخصا به ترتیب با اولویت کتاب توی وقتهای خالی دارم این مورد رو پیش می‌برم.

#5min_Rust

تفاوت Stack, Heap, Static در Rust:

اولین نکته اینه که خیلی از دوستان به اشتباه فکر می‌کنند که این ۳ مورد حافظه‌های متفاوتی هست و این مشکل از اینجا میاد که راجب سرعت صحبت می‌شه.

توی تصویر مثال بالا اگر دقت کنید؛ هر ۳ مورد داخل RAM هستند فقط ویژگی‌های مختلفی دارند که بهشون می‌پردازیم:
وقتی شما کد رو اجرا می‌کنید اول یک سری فضا به برخی موارد اختصاص داده می‌شه؛ برای مثال خود دستورالعمل‌های کد شما که توی تصویر سمت چپ Stack هستند؛ این بخش شامل static, global variable و ... هم میشه.
از مثال زدن data type ها پرهیز می‌کنم چون هنوز باهاشون آشنا نشدیم.
بعد از اینکار برای Rust یک فضای 8MB پشت سرهم درخواست داده می‌شه که این فضا بعنوان Stack اصلی توسط برنامه استفاده خواهد شد.
دیفالت 8mb هست برای ترد اصلی و 2mb برای تردهای دیگه توجه کنید که لزوما همون لحظه کل 8mb رزرو نخواهد شد اما برنامه شما تا 8mb دسترسی به استک داره و اگر بیشتر بشه stack overflow رخ میده و برنامه kill میشه.

با ویژگی‌های اصلی استک شروع کنیم و بعد به سراغ مثال بریم:
۱- سرعت؛ توی تصویر دقت کنید؛ یک بخشی بین stack, heap نوشتم Stack Pointer؛ یکی از رجیسترهای CPU وظیفه نگهداری آدرس شروع Stack رو به عهده می‌گیره و هموراه به آدرس انتهایی آخرین دیتای موجود در استک اشاره می‌کنه.

۲- هر نوع داده‌ای که می‌خواد داخل استک قرار بگیره باید سایز مشخصی داشته باشه. در زمان کامپایل باید مشخص بشه چقدر جا می‌خواد.

ترکیب دو مورد بالا باعث میشه که بتونیم خیلی سریع به دیتاهای روی Stack دسترسی بگیریم اما یک محدودیت هم هست؛ Stack مثل بشقاب چینی می‌مونه وقتی روی هم میچینی نمی‌‌تونی از آخر ی دونه رو بکشی بیرون؛ باید به ترتیب از بالاترین بشقاب برداری تا به پایینی (آخری برسی).

مورد بعدی Heap اما داستان متفاوتی داره؛ برخلاف Stack که خودش بصورت خودکار حافظه اختصاص میده و میگیره heap اینطوری نیست و هروقت به این حافظه نیاز داشته باشه باید به سیستم عامل بگه که یک همچین حافظه‌ای لازمه تا سیستم عامل اون میزان رو پیدا کنه و بهش بگه از اینجا به بعد رو می‌تونی استفاده کنی.

توی عکس بالا توی بخش heap خونه‌های قرمز بخش‌های از حافظه‌ هست که برای کارهای دیگه اختصاص داده شده و ما نمی‌تونیم دسترسی بگیریم؛ همین بررسی اینکه کجا رو به ما اختصاص بده باعث میشه سرعت این حافظه کندتر باشه.
پاک کردن داده از Heap هم توسط ownership, borrowing توی Rust مدیریت میشه که بعدا راجبش صحبت می‌کنیم.

توی پست بعدی راجب نمونه کد و جزئیاتش توی تصویر بالا صحبت خواهیم کرد.

پینوشت:
من سعی کردم خیلی ساده توضیح بدم تا کلیات و تفاوت‌های اصلی رو همه متوجه بشوند و از بحث راجب نحوه دقیق عملکرد در اینجا خودداری کردم (باشه برای آینده)

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


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

#5min_Rust

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

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

Rust 1.85.0:

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

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

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

این موضوع خیلی کار رو نسبت به async block ها راحت‌تر می‌کنه دیگه درگیری ownership و ... رو نداره.

Rust edition 2024
هم همزمان منتشر شده؛ که یک سری رزرو جدید و ... داشته

Rust Blog

نظرشخصی:
بنظرم هرچی بیشتر جلو میریم کد زدن توی Rust راحت‌تر و تمیزتر خواهد شد.

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

داشتم راجب linux io_uring میخوندم؛ که برام سوال شد آیا Rust هم ازش استفاده می‌کنه ؟
دیدم توکیو همه‌کاره اینکار رو هم می‌کنه؛ اما نه کاملا بهینه ولی bytedance شرکت مادر Tiktok یک پروژه داره به اسم monoio که کاملا هم فعال و آپدیت بگیر هست و بدون سربار داره از io_uring استفاده می‌کنه.

من روی تمرین Socket توی Rust به این موضوع رسیدم و دارم بیشتر باهاش آشنا میشم اما خوشحال میشم اگر کسی تجربه کار با این ابزار یا آشنایی دقیقی با io_uring داره یک پست؛ ویدئو یا ... مارو مهمون کنه توی کامنت‌ها.

ماکروسافت دیروز اعلام کرد که کامپایلر Typenoscript رو منتقل کرده روی Go (قبلا روی خود TypeScript بود)

یک دلیلی که من مخالف ترجمه فارسی خیلی از مباحث هستم همین موضوع هست؛ ماکروسافت نگفته کامپایلر رو بازنویسی می‌کنه بلکه دقیقا تاکید روی Port کردن داشته.
یعنی همون کدهای قبل رو کپی پیست می‌کنند توی یک فایل جدید و مطمئن میشن سینتکس و ... به Go تبدیل بشه. (واقعا فارسی توضیح دادن تفاوت rewrite, port کردن خیلی سخته)

بگذریم؛ توی این بحث طرفدارای Go و البته اونایی که درک درستی از موضوع نداشتند خواستند از آب گل‌الود ماهی بگیرند که دوره‌های Go خودشون رو بفروشند یا اینکه نفرت پراکنی کنند راجب Rust ؛ اول اینکه اگر بیشتر رصد کنید خیلی‌ها کمی ناامید شدند که چرا Rust انتخاب نشد.

مثلا نویسنده Vue که توی توییت‌های مختلف توضیح داده که Go برای بعضی کاربردها مثل web assembly مناسب نیست و ...

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

اما تیم TypeScript نمی‌خواد مجدد همه چیز رو از بیخ بازنویسی کنه و فقط داره Port می‌کنه تا زمان کامپایل رو کاهش بده؛ برای همین نیازی به سختی‌های Rust, C نداره و البته همین Port کردن کم هزینه هم حداقل بهش 10x سرعت داده.

دلیل انتخاب Golang بجای Rust, C فقط این موضوع بوده؛ خواستم شفاف بشیم روش.

#5min_Rust

قبل از اینکه دوپایی بپریم توی معرفی انواع Data type توی Rust یک تفاوت رو بین Rust, Python ببینیم.
توی rust بر خلاف python برنامه‌نویس نمی‌تونه هر زمانی که دلش خواست توی متغییر مقداری با دیتا تابپ متفاوت بریزه؛ کد زیر توی پایتون درست هست:

my_var  = 5
print(f"The content is {my_var} of type {type(my_var).__name__}")
my_var = "@pyrust" 
print(f"The content is {my_var} of type {type(my_var).__name__}")

اما توی rust شما اجازه اینکار رو ندارید

fn main() {
    let my_var: i32 = 5;
    println!("The content is {my_var} of type {}", std::any::type_name::<i32>());

    my_var = "Hello"; // ٍError: expected `i32`, found `&str`
}

پس توی rust خیلی مهم هست که مشخص کنید متغیر شما از چه نوعی باید باشه؛‌ البته توی خیلی موارد نیازی به نوشتن نداره و خود کامپایلر می‌تونه بر اساس استفاده‌ای که از متغییر می‌کنید (اولین نوع داده‌ای‌ که داخلش می‌ریزید) تصمیم بگیره.

پس با این حساب یادگیری Data Type مهم میشه و اولین نوع داده‌ای که بررسی می‌کنیم Integer خواهد بود.
بازم بر خلاف پایتون نوع int توی rust خودش چندین مدل داره؛ بصورت پیش‌فرض اگر هیچ موردی رو انتخاب نکنید کامپایلر برای شما i32 رو درنظر می‌گیره ولی این یعنی چی ؟

i32 : i = Signed, 32 = 32-bit value

اگر نوع int شما با i شروع شده بود یعنی Signed هست و این به این معنی هست که این نوع داده شامل اعداد صحیح مثبت و منفی می‌شه.
عدد 32 نشان دهنده تعداد بیت حافظه هست و محدوده اعدادی که این مقدار می‌تونه نگهداره رو شامل میشه.

برای راحتی من با i8, u8 مثال میزم:
اینجا u به معنی unsigned هست و یعنی این نوع داده اعداد منفی قبول نمی‌کنه؛ برای اینکه بفهمیم یک نوع داده چه رنج اعدادی رو داخل خودش نگهداری می‌کنه می‌تونیم از فرمول زیر استفاده کنیم:

i8 : Signed, 8bit
برای بدست آوردن رنج signed کافیه تعداد bit رو داخل این فرمول بذارید :

[-2^(n-1), (2^(n-1))-1] ==> [-2^7, (2^7)-1) ==> [-128, 127]

u8
برای بدست آوردن رنج unsigned ها کافیه تعداد bit رو داخل این فرمول بذارید:

(2^n)-1 ==> (2^8)-1 ==> 255

علامت ^ نماد توان هست.

اگر با اعداد باینری کمی آشنایی داشته باشید نیازی به حفظ کردن فرمول‌ها نیست؛ توی نوع unsigned ازونجایی که عدد مثبت و منفی رو قبول می‌کنه پس ۱ بیت رو از دست میده برای اینکه مشخص کنه عدد منفی هست یا مثبت پس این یعنی بخش توان فرمول -1 رو خواهد داشت فقط برای unsigned ها
اما توی هر دوحالت حاصل محسابات و به توان رسوندن همیشه -1 رو توی بخش مثبت هم داره؛ خیلی ساده دلیلش اینه که بزرگترین عدد مثبتی رو وقتی می‌تونید بسازید که همه‌ی بیت‌های باینری 1 باشند و هروقت بیت اول (از راست) مقدار 1 بگیره حاصل حتما عددی فرد خواهد بود.

بر همین اساس شما همه‌ی آنچه برای درک جدول تصویر پیوست لازمه رو می‌دونید؛ فقط یک مورد می‌مونه :

arch | isize | usize

که یعنی این نوع به معماری سیستم بستگی داره (معماری سیستم روی index گذاری برای دسترسی به خانه‌های RAM مهم هست) برای همین هرجا صحبت از دسترسی به حافظه یا index , ... باشه این نوع داده رو خواهید دید. اگر سیستم ۳۲ بیتی باشه مقدار isize = i32, usize = u32 خواهند بود و برای سیستم‌های ۶۴ بیتی مقادیر isize=i64, usize=u64 رو خواهیم داشت.

بعد از اون نوع داده float رو داریم؛ شامل f32, f64 تفاوتشون توی precision هست (تعداد اعدادی که بعد از اعشار میاد)

f32 precision: 6-9 digits
f64 precision: 15-17 digits

یعنی برای نوع داده f32 بعد از ۶-۹ رقم اعشار دقت رو از دست می‌دیم و حاصل محاسبات بعد از ۶-۹ رقم اعشار رند شده خواهد بود؛ برای f64 این مقدار به ۱۵-۱۷ میرسه؛ بصورت دیفالت کامپایلر متغیرها رو f64 درنظر میگیره مگر اینکه شما مشخص کنید نوع داده چیز دیگری باشه.

اگر رند کردن براتون قابل قبول نیست Decimal رو باید در نظر بگیرید که خب توی این مرحله راجبش صحبت نمی‌کنیم.

برای تعیین نوع داده هم بعد از ساخت متغییر و قبل از مقدار دهی می‌تونید نوع داده رو مشخص کنید:

let red_pixel: u8 = 25;
let my_negative_number: i32 = -5654891;
let pi: f64 = 3.14

بیشترین سوالی که پرسیده میشه؛ آیا باید همیشه برای پرفورمنس بیشتر کوچکترین نوع داده رو انتخاب کنیم ؟
خیر.
اولین و مهمترین موضوع؛ اجرا شدن درست برنامه هست؛ اما بعضی وقتا کاملا میشه مطمئن بود نوع داده‌ای باید چه مقداری باشه.
مثلا فرض کنید ما دارید یک برنامه برای پردازش تصاویر jpg می‌نویسید؛ توی این تصاویر همیشه مقدار هر پیکسل بین 0-255 خواهد بود و این یعنی شما برای متغییرهای کار با پیکسل می‌تونید با خیالت راحت نوع داده رو روی u8 تعریف کنید.
اما برای مواردی که مطمئن نیستید i32 شروع خوبی هست که پیش‌فرض کامپایلر هم همین مقدار هست.

#5min_Rust

از حالت‌های دیگه‌ای که می‌تونید نوع داده رو مشخص کنید استفاده از _ و البته as که ممکن توی کدهای دیگران ببیند.
در نهایت

std::<TYPE>::MIN
std::<TYPE>::MAX

رو هم برای دیدن کوچکترین و بزرگترین مقدار اون نوع داده می‌تونید print کنید.

توی گروه codecraft همینجوری که دارم تسک‌ها رو تمرین می‌کنم کدها رو با rust می‌نویسم و به اشتراک میذارم.

خیلی از مواردی که توی پست‌های ۵ دقیقه یادم میره مثال بزنم یا مثال به ذهنم نمیاد توی کدهای اونجا هست (الته کدها بصورت تصویر هست) تا حتی اگر کسی خواست از روی کدها هم تسک‌ها رو انجام بده حداقل مجبور بشه یکبار کد رو بخونه (موقع تایپ)

https://news.1rj.ru/str/codecrafter_fa/472

توزیع ubuntu اعلام کرده میره سراغ پروژه uutils؛ این پروژه یکی از بزرگترین بازنویسی‌ها توی Rust هست که تمام ابزارهای مهم پروژه GNU Linux رو با Rust بازنویسی می‌کنه.
ls, cd, cp, mv, mkfifo, ....

مشکل اصلی هم بخاطر، باگ‌های گزارش شده سر Memory Safety هست؛ اوبنتو هم این مورد و پرفورمنس رو دلیل این حرکت دونسته.

پرفورمنس از کجا میاد؛ قطعا Rust به خودی خود از C سریعتر نیست ولی سختی مالتی‌ترد و مالتی پراسس روی C باعث شده بسیاری از توسعه دهنده‌های core utils سراغ اینکار نروند و خب بارها صحبت این موضوع شده بود که این یک bottleneck برای خیلی از ابزارهای دیگه که بر اساس core utils توسعه داده می‌شوند هست، مشکلی که توی Rust وجود نداره و با یک جستجو حتی نتایج بنچمارک‌ها روی ابزارهایی که امکان Multi thread / Multi Process شدن براشون بوده رو می‌بینید که توی بعضی موارد حتی تا 10x سریعتر هستند.

توسط پروژه oxidizer می‌تونید همین الان اینکار رو بکنید و تست بگیرید ubuntu با نسخه rust ابزارها چیکار خواهد کرد.



اطلاع بیشتر :
Link


پ.ن : راستی اگر اینطوری بشه یعنی GNU از Ubuntu و بعد از Linux حذف بشه؛ دیگه اینایی که تازه مدرک کار با ترمینال لینوکس گرفتن
زخممون نمی‌کنند که Linux نگو، باید بگی Gnu Linux
اگر این مشکل رو حل می‌کنه من ۱۰۰٪ پایه‌ام 😂

زردی من از تو / سرخی تو از من

#ai_generated

نوروز مبارک 🌹🎊🎉🎉🎊🎉🌹

امیدوارم سال جدید از سالی که لحظات آخرش هست، بهتر باشه.
پر از خبرای شادی بخش برای ایران و ایرانیان.

سایه آخوند از وطن دور

فیلم امشب و فردا رو پیدا کردم؛ تخمه یادم نره

Build a Music platform with Rust (Axum)

فرصت کردم، این کتاب رو شروع کنم و توی همین فصل‌های اول واقعاً لذت بردم.

بسیار روان نوشته شده؛ هرچند ترجیح میدادم مثال‌های بیشتری داشته باشه ولی خب به لطف LLM ها دیگه خیلی نیاز نیست همین‌ که خوب توضیح میده مفاهیم رو واقعاً فوق‌العاده هست.

امیدوارم تا آخرش همینطور باشه

Rust Atomics and Locks

که می‌گفتن Rust در واقعیت به خوبی C, C++ نیست ؟

Microsoft is Getting Rusty

شاید شما هم تعجب کردید؛ شایدم نه که موزیلا مدتی قبل یک سری اخراج توی تیم‌هاش انجام داد (که کم هم نبود) ولی اپلیکیشن‌هاش توی ios, android, desktop توی آپدیت‌های بعدی به مراتب بهتر و بهتر شد.

دلیلش خیلی تو مخ من بود (فکر میکردم از ابزاری مثل Dioxus استفاده می‌کنند؛ که درست در نمیومد چون هنوز تیم‌های native خودشون رو داشتند.

این قضیه تو مخی من بود تا اینکه متوجه توسعه UniFFI شدم؛ بر اساس خود داکیومنت :

UniFFI is currently used extensively by Mozilla in Firefox mobile and desktop browsers; written once in Rust, auto-generated bindings allow that functionality to be called from both Kotlin (for Android apps) and Swift (for iOS apps). It also has a growing community of users shipping various cool things to many users.

ابنطوری منطق رو ۱ بار می‌نویسه و بعد توی کدهای مختلف android, ios, desktop اون رو استفاده می‌کنند. دیگه مشکلی هم برای استفاده از جدیدترین فیچرهای هر پلتفرم نداره (وقتی ایده خوب و پیاده‌سازی خوب کنار هم میاد).


مثال جایی که کاربرد زیادی داره:
یک پروژه‌ای چندین سال قبل داشتم که شامل بیش از ۵۰ تا فرمول ریاضی و بیش از ۲۰ مورد الگوریتم بود تا خروجی درست رو تحویل بده؛ حتما پیش خودتون می‌گید ببرش ۱ بار روی سرور پیاده‌سازی کن یک endpoint بده به فرانت تموم بشه بره.
گزینه خوبی هست ولی نه وقتی مزیت رقابتی کار شما نسبت به باقی privacy دیتای کاربر هست و این محاسبات بطور کامل باید روی دستگاه کاربر باشه؛ غیر از اون حجم دیتاها توی بعضی شرایط بسیار بالا بود که خیلی عاقلانه نبود برای اون دیتاها هم از کاربر بخوایم آپلود انجام بده.

پس مجبور بودیم؛ ۴ بار پیاده‌سازی کنیم:
۱- تیم تحقیقاتی که دائمی روی پایتون کار می‌کرد.
۲- تیم C# که برای ویندوز نرم‌افزار رو تولید می‌کرد (دسترسی بالاتر)؛ کاربر ios, android می‌تونستند دیتاهاشون رو باهاش به اشتراک بذارند برای همین نیاز بود قابلیت پردازش قویتر هم داشته باشه اگر خواست گزارش جزئی تری بدست بیاره و ....
۳- تیم Swift که روی نسخه iOS, iPadOS کار می‌کرد.
۴- تیم Kotlin که روی نسخه Android کار می‌کرد.

خیلی وقتا پیش میومد یک اشتباه توی منطق کار با آرایه‌های چند بعدی (برای optimization باید اینطوری پیاده‌سازی می‌شد که بشه از GPU, CPU همزمان استفاده کرد) باعث می‌شد یا نتایج نهایی اشتباه بشه یا محاسبات خیلی کند بشه و البته گوشی بیش از حد داغ کنه.

هیچ وقت یادم نمیره اون روزا مجبور بودم کار با آرایه رو روی C#, Js, Kotlin, Swift یاد بگریم تا ایرادات بچه‌ها رو پیدا کنم؛ کاری که اگر به عقب برگردم حتما یکبارم که شده با این پکیج تستش می‌کنم.

اون زمان اینطوری بودیم که تا مجبور نشدیم؛ الگوریتم جدید رو برای پیاده‌سازی نفرستیم وقتی رقیبا الگوریتم‌هاشون به خوبی کار ما می‌شد اونوقت نسخه جدید میدادیم. اینطوری بود که تیم تحقیق v70 الگوریتم روی میداد برای پیاده‌سازی ولی روی اپلیکیشن می‌شد v5 الگوریتم. خیلی میفهمم چرا یک تیم باید از چنین ابزاری استفاده کنه.

کاش یک سالی هم بیاد که توش اصلاً لازم نشه بهم #تسلیت بگیم.

اصلاً یادمون بره ی روزی توی این مملکت، آخوندایی که جز خوندن :
احکام ریدن و جهتش و ...
شعور و فهم چیز دیگه‌ای نداشتند، مسئولیت داشتند.

یعنی میشه؟ تا ما زنده‌ایم !
یک سال وقتی تموم میشه، بیام اینجا بزنم:

بچه‌ها دقت کردید، امسال لازم نشد بهم دیگه تسلیت بگیم !!

من واسه اون روز می‌جنگم.

#بندرعباس

کتاب async rust منتشر شده.
اومدم بخونم که توش پیشنهاد داده بود قبلش
Rust web programming
رو بخونم که توسط همین نویسنده منتشر شده (توی لیست کتاب‌هایی که اکر وقت کنم می‌خونم، نگهش داشته بودم)

تا اینکه شروع کردم توی اوقات کانفیگ سرور و ... خوندن؛ خوشحالم که این کتاب رو قبل از Async Rust دارم می‌خونم.

واقعاً جذاب هست؛ هر دو کتاب این نویسنده رو پیشنهاد می‌کنم حتماً بخونید.

پ.ن:
برای آموزش‌های ۵ دقیقه‌ای، فراموش نکردم فقط این روزها بسیار بسیار زمانبندی فشرده‌ای دارم. سرور و داوپس و شبکه و برنامه‌نویسی و هوش مصنوعی و ... همرو دارم انجام میدم 🤦

قطعاً کمی شرایط بهتر بشه، ادامه خواهم داد.