یه چیت شیت ۱۰ صفحه ای برای اسمبلی x64

https://cs.brown.edu/courses/cs033/docs/guides/x64_cheatsheet.pdf

اینم یک زبان برنامه نویسی اسوتریک دیگه که من ساختم :)

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

https://github.com/tahadostifam/Babaism

شما هم به ببئیسم بپیوندید
با ساختن ایشیو در همین ریپازیتوری و با روانه کردن بعععع بععععع میتونین بدون اخذ هیچ هزینه ای در ببئیسم عضو بشید.

زیگ برای async و event loop یه rewrite داشتن چون سازنده ش Andrew Kelley فکر میکرد که به اون خوبی ای نشده که فکرشو میکرد و اومدن آپگرید ش کردن :)

میتونم بگم فوق العاده ست پیاده سازیش. ولی خدایی "async"@ قطعا چیزی نیستش که بهش بتونی بگی سیمپل :) زیگ از simplicity فاصله گرفته.

https://www.youtube.com/watch?v=hEIBsqP63Pg

مثال هایی از error polymorphism در زبان های مختلف Java, C#, Rust, Zig, Koka

https://www.youtube.com/watch?v=OcyijYJq18s

‌آیا async/await همیشه مفیده؟ نه دقیقاً!
توی یکی از پروژه‌های ما با ترافیک بالا، همه‌ی endpointها به‌صورت async نوشته شده بودن.
ولی با وجود کد تمیز و async بودن کامل، سیستم دچار ThreadPool starvation شده بود و latency به‌شدت بالا رفته بود.
بررسی کردیم و دیدیم:‌ async به‌صورت blanket روی همه مسیرها اجرا شده، حتی روی عملیات‌های CPU-bound یا توی حلقه‌های ریز و پرتکرار.
حالا async ابزار خیلی خوبیه، ولی:
- روی CPU-bound = بدتر شدن عملکرد
- توی حلقه‌های tight = هزینه context switching اضافی

توصیه:
فقط عملیات‌های I/O واقعی (مثل DB, HTTP, File IO) ارزش async دارن
چی‌کار کردیم؟
؛ endpointهایی که واقعاً I/O-bound بودن، async موندن

بقیه‌ی مسیرها برگشتن به sync
و با این تغییر ساده، latency تقریباً نصف شد (بر اساس لاگ‌های واقعی)
ابزار:
من برای این تحلیل از ابزارهایی مثل MiniProfiler و لاگ‌های دقیق Serilog کمک گرفتم.
جمع‌بندی:
تجربه نشون می‌ده async فقط یه keyword نیست.
یه تصمیم مهندسیه، که اگه بی‌دلیل و همه‌جا استفاده بشه، می‌تونه قاتل performance باشه.

@DevTwitter | <Bahare Zarei/>

عجب کتابخونه ایه. از دستش ندین

https://magicui.design

خب Carbon تا یه حدی نسخه experimental ش تکمیل شده و آماده تست و مشارکت هستش، اگر ++C دوس دارین یه نگاهی بهش بندازین؛ گرچه قبلا هم معرفی ش کرده بودم :)

https://docs.carbon-lang.dev

عجب چیزی ساخته طرف

https://www.youtube.com/watch?v=8-B6ryuBkCM

Programming Abstractions in C++

اون کتاب قبلیه زیادی مقدماتی بود. این یکی یکم بهتره =)
فصل ۶ و ۷ و ۸ راجب انتزاعات در الگوریتم ها هستش و خوندنش رو پیشنهاد میکنم.

مزایا و معایب ساخت انتزاع

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

1. ساده‌سازی منطق و کاهش پیچیدگی ذهنی
2. قابلیت استفاده مجدد (Reusability)
3. افزایش قابلیت نگهداری (Maintainability) (همچنین اشاره میشود به اصل Separation of Concerns)
4. تمرکز بر روی مسئله اصلی

معایب و هزینه‌های انتزاع

1. خطر طراحی نادرست
انتزاعی که با نیازهای دامنه منطبق نباشد، به جای ساده‌سازی، باعث پیچیدگی و سختی در استفاده می‌شود. این پدیده معمولاً با Leaky Abstraction شناخته می‌شود، جایی که جزئیات سطح پایین ناخواسته به لایه بالاتر نشت می‌کنند.

2. پنهان کردن بیش‌ازحد جزئیات حیاتی
برخی سیستم‌ها (مانند سیستم‌های Real-Time یا Embedded) نیازمند کنترل دقیق بر منابع و رفتار هستند. انتزاع بیش‌ازحد می‌تواند این دید و کنترل را محدود کند و اشکال‌زدایی را دشوار نماید.

3. هزینه عملکرد (Performance Overhead)
هر لایه‌ی انتزاع می‌تواند منجر به سربار زمانی و حافظه‌ای شود. مثلاً استفاده از یک ORM ممکن است در مقایسه با اجرای مستقیم SQL، چندین برابر کندتر باشد. در سیستم‌های High-Performance، این موضوع باید به‌دقت سنجیده شود.

4. افزایش وابستگی
انتزاعی که به کتابخانه‌ها یا فریم‌ورک‌های خاص متکی باشد، می‌تواند باعث قفل‌شدگی تکنولوژیک (Vendor Lock-In) شود. در این حالت، تغییر زیرساخت یا ابزار، نیازمند بازنویسی گسترده خواهد بود.

توصیه‌های طراحی انتزاع

1. اصل KISS (Keep It Simple, Stupid): لایه‌ها را تا حد ممکن ساده طراحی کنید.
2. اصل YAGNI (You Aren’t Gonna Need It): انتزاعی نسازید که فعلاً نیاز ندارید.
3. مستندسازی: هرچه جزئیات پنهان می‌کنید، باید به‌خوبی داکیومنت شود.
4. قابل تست بودن: انتزاع باید به شکلی باشد که بتوان آن را به‌صورت مستقل تست کرد.

انتزاع یک ابزار قدرتمند برای مدیریت پیچیدگی در نرم‌افزار است، اما استفاده بی‌رویه یا طراحی ضعیف آن می‌تواند به ضد خود تبدیل شود. در عمل، بهترین انتزاع آن است که به‌اندازه نیاز واقعی ساخته شود، قابل فهم باشد، و در عین حال مانع دیدن جزئیات ضروری نشود.

Common Rust Lifetime Misconceptions

https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md#2-if-t-static-then-t-must-be-valid-for-the-entire-program

پ.ن: اینو بخونید تا دیگه borrow checker راست کفری تون نکنه =)

صحبت های سازندگان زبان Odin یعنی Ginger Bill و سازنده زبان Elixir (که اصلا نمیشناسمش) رو داریم می‌بینیم و باید بگم عجب جنجالی راه افتاده حقیقتا =) تقریبا ازشون خبر های داغ راجب زبان های برنامه‌نویسی رو پرسیدن.

مثلا اینکه چرا Python کارا میرن سمت Go.
یا چرا Ruby کار ها میرن سمت Rust.
و سرگذشت Erlang و Elixir و Ruby.
و حتی سازنده الکسیر راجب open بودن کامیونیتی روبی توضیح میده.
و صحبت کلی دعوای بین پارادایم های زبان های برنامه نویسی ست (OOP vs Functional).

و ازشون opinion شون رو راجب Rust هم پرسیدن که...😂 خودتون بشنوید بهتره.

درکل به هیچ عنوان این ویدیو رو از دست ندید. زیاد جالب است :)

https://youtu.be/tXJfS6jI9Z0?si=UAvBmX5Tmj_S7s44

این گنج را دریابید و متحول شوید.
کتابی برای درک برنامه نویسی Data Oriented در مقابل Object Oriented.