‌آیا 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.

جامعه Geek Engineers یک فضای باز، پویا و دوستانه برای همه علاقه‌مندان به دنیای برنامه‌نویسی و مهندسی کامپیوتر است. ما باور داریم که یادگیری و پیشرفت، زمانی بهترین نتیجه را می‌دهد که افراد در کنار هم و با هم‌فکری، ایده‌ها و تجربیات خود را به اشتراک بگذارند.

هدف ما ایجاد محیطی است که در آن برنامه‌نویسان، از مبتدی تا حرفه‌ای، بتوانند با یکدیگر ارتباط برقرار کنند، پروژه‌های متن‌باز بسازند، مشکلات فنی را حل کنند و مهارت‌های خود را گسترش دهند. ما به ویژه به زبان‌های Rust، Go، OCaml و C علاقه‌مندیم و در پروژه‌ها و بحث‌های فنی از آن‌ها استفاده می‌کنیم. همچنین به الگوریتم‌ها و حل مسأله اهمیت می‌دهیم تا مهارت‌های تحلیلی و منطقی اعضای جامعه تقویت شود. در وب‌سایت ما می‌توانید کتاب‌ها و مقالات کاربردی مرتبط با برنامه‌نویسی و مهندسی نرم‌افزار را پیدا کنید تا یادگیری شما هدفمندتر و عمیق‌تر شود.

اگر شما هم به برنامه‌نویسی، یادگیری مستمر و کار تیمی علاقه‌مندید، جامعه ما جای مناسبی برای شروع و ادامه این مسیر است.

@geek_engineers

https://geekengineers.netlify.app

کتاب ها و مقاله های کوچک داخل کانال به مرور به وبسایت انتقال داده میشود و پروژه های اوپن سورس دیگری اضافه خواهد شد.

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

> به امید ساختن جامعه ای با سواد و مجرب🤌🏿

توی TempleOS کتابخانه داخلی‌ شبیه OpenGL و glm وجود داشت =) دارم وسوسه میشم امتحانش کنم روی VM.

https://youtu.be/d3eFHyryopQ?si=Ry5_LFrZh9Bowga8

سندرم ایمپاستر (Impostor Syndrome)

این یک اختلال رسمی روان‌شناسی مثل افسردگی یا اضطراب نیست، بلکه بیشتر یک الگوی فکری و احساسی است. کسی که این حالت را تجربه می‌کند، با وجود شواهد واقعی از موفقیت‌ها و توانایی‌هایش، خودش را یک «حقّه‌باز» یا «جعلی» می‌بیند.

ویژگی‌های اصلی‌اش:

- فرد موفقیت‌هایش را به شانس، روابط یا اتفاق نسبت می‌دهد، نه توانایی خودش.

- مدام می‌ترسد که دیگران بفهمند او به اندازه کافی باهوش، متخصص یا شایسته نیست.

- دستاوردها برایش واقعی یا ارزشمند به نظر نمی‌رسند.

- حتی وقتی موفقیتی کسب می‌کند، احساس رضایت موقتی دارد و سریعاً دوباره وارد همان چرخه شک و تردید می‌شود.


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

اینجا راجبش بحث شده :

https://www.reddit.com/r/webdev/s/Q4TPMWy0zH

منتها راه حل شفاف و واضحی ندارد.
فقط میتونم بگم آگاهی و شناخت کمک به کنترلش میکند.

Stack Frames (Trynna understand the concept by using a debugger)

https://www.youtube.com/watch?v=0t_QewtSbXo (The most nice one)

https://www.youtube.com/watch?v=7dMTCdFM2ss

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