🔗 لینک کانال‌هامون:
https://t.iss.one/addlist/AJ7rh2IzIh02NTI0

💰 لینک حمایت مالی:
https://www.coffeete.ir/mrbardia72

🚀لینک تلگرام بوست:
https://t.iss.one/boost/gopher_academy

توصیه غافلگیرکننده بنیان‌گذار آمازون به جوان‌ها: فعلا استارتاپ نزنید!
https://www.zoomit.ir/business/451731-jeff-bezos-guidance-gen-z-featured/

اگه دنبال یه آلترنیتیو برای Claude Code می گردید که اکثر Providerهارو ساپورت کنه بهتون Crush رو پیشنهاد می دم!

با go نوشته شده و من خیلی تجربه خوبی داشتم وقتی توی دو سه روز گذشته!

https://github.com/charmbracelet/crush

<Von Datawarehausen/>

اگه زبان گو کار می‌کنید و یا قصد یادگیریش رو دارید این ویدیو هارو ببینید از تیم Ardan Labs هستش یه مجموعه خیلی خوب برای یادگیری برنامه نویسی و دواپس

https://github.com/ardanlabs/gotraining

<MEHDI Homeily - مِهدی هُمِیلی/>

این تصویر به‌صورت دقیق نحوه‌ی ادغام خلاصه‌ها (summary merging) در مدیریت حافظه‌ی Go را نشان می‌دهد.
ایده‌ی اصلی:
در Go برای مدیریت صفحات آزاد از ساختاری به نام Summary استفاده می‌کند که سه مقدار دارد:

start → تعداد صفحات آزاد در ابتدای محدوده

end → تعداد صفحات آزاد در انتهای محدوده

max → بیشترین دنباله‌ی صفحات آزاد در هر نقطه از محدوده

هر Summary معمولاً ۵۱۲ صفحه را پوشش می‌دهد. وقتی دو محدوده‌ی متوالی (مثل S1 و S2) کنار هم قرار می‌گیرند، Go می‌تواند آنها را با هم ادغام کند تا یک summary بزرگ‌تر بسازد.
➖➖➖➖➖➖➖➖
👑 @gopher_academy

وقتی این دو کنار هم قرار می‌گیرند، Go مقدارهای جدید را به شکل زیر محاسبه می‌کند:

start = S1.start = 3
(از آنجایی که ناحیه پایین‌تر از S1 شروع می‌شود)

end = S2.end = 2
(زیرا انتهای کل محدوده با S2 تمام می‌شود)

max = max(S1.max, S2.max, S1.end + S2.start)
= max(10, 8, 7 + 5)
= max(10, 8, 12)

با ادغام S1 و S2، خلاصه‌ی جدید محدوده‌ی ۱۰۲۴ صفحه‌ای برابر است با:

start = 3, max = 12, end = 2

مزیت این روش:
Go با استفاده از این ساختار سلسله‌مراتبی از summaryها می‌تواند بدون نیاز به اسکن کامل بیت‌مپ‌ها، در چند سطح (arena → chunk → bitmap) سریعاً پیدا کند کجا فضای خالی کافی برای تخصیص span جدید وجود دارد — در نتیجه تخصیص حافظه بسیار سریع‌تر و مقیاس‌پذیرتر انجام می‌شود.
➖➖➖➖➖➖➖➖
👑 @gopher_academy

توضیحات👇👇👇👇
➖➖➖➖➖➖➖➖
👑 @gopher_academy

این تصویر به‌خوبی ساختار سلسله‌مراتبی (Hierarchical Summary Structure) در مدیریت حافظه‌ی Go را نشان می‌دهد — یکی از بخش‌های کلیدی طراحی allocator مدرن Go.

🧠 ایده‌ی اصلی:

برای اینکه Go بتواند خیلی سریع تشخیص دهد کجا فضای خالی کافی برای تخصیص وجود دارد**، از یک ساختار درختی چندسطحی استفاده می‌کند.
این ساختار درواقع یک **Radix Tree جهانی از *summaryها* است.


🏗 نحوه‌ی کار:

* Level 4 (پایین‌ترین سطح)
شامل بیت‌مپ‌های واقعی از صفحات (هر بیت = یک صفحه 8KB).
در تصویر با رنگ سبز نشان داده شده و مقدار 1011...0010 وضعیت صفحات را مشخص می‌کند (۰ = آزاد، ۱ = اشغال).

* Level 3 و بالاتر:
هر سطح بالاتر از ترکیب دو یا چند خلاصه‌ی سطح پایین‌تر تشکیل می‌شود.
هر جعبه‌ی آبی، یک Summary است که نشان می‌دهد در زیرمجموعه‌ی خود چند صفحه آزاد به‌صورت پیوسته وجود دارد.
برای هر سطح، سه مقدار (start, max, end) بر اساس ادغام سطوح پایین‌تر محاسبه می‌شوند (مثل مثال S1 و S2 که قبلاً دیدی).

* Level 0 (بالای درخت):
این سطح تنها یک نود دارد که کل فضای مجازی تخصیص‌پذیر Go را پوشش می‌دهد.
این نود به allocator اجازه می‌دهد خیلی سریع بفهمد آیا در کل heap جایی وجود دارد که مثلاً 100 صفحه‌ی خالی پشت‌سرهم داشته باشد یا نه.

⚙️ مزایا:

1. 🔍 جستجوی سریع:
ا Allocator دیگر لازم نیست کل heap را اسکن کند — فقط در درخت پایین می‌رود تا بخش‌های مناسب را بیابد.

2. 🔄 به‌روزرسانی بلادرنگ:
وقتی صفحه‌ای تخصیص یا آزاد می‌شود، فقط summary همان بخش و مسیرش تا بالا به‌روزرسانی می‌شود (O(log n) پیچیدگی).

3. 🧩 مقیاس‌پذیری بالا:
چون هر سطح می‌تواند به‌صورت محلی به‌روزرسانی شود، چندین goroutine می‌توانند به‌صورت هم‌زمان در بخش‌های مختلف heap کار کنند بدون قفل‌گذاری سراسری.
➖➖➖➖➖➖➖➖
👑 @gopher_academy

به اون کاری که امروز کردی نگو "ریفکتور" (Refactor). اگه تست نداره، اون فقط یه "گندکاریِ تمیزه".
این فقط یه جمله‌ی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ‍️ تو یه پروژه‌ی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکه‌تیکه‌اش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفه‌ای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد.  کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطق‌های تجاری پنهان و وابستگی‌های زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کم‌بهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تله‌ی کد تمیز"ئه. مهم‌ترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تست‌های مشخصه‌یابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همه‌ی باگ‌هاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.

<Hossein Moradi/>

سرویسی که گفت: “من دیگه نمی‌کشم…” و ما رفتیم سراغ Go!
چند ماه پیش متوجه شدم که بار روی یکی از سرویس‌هامون که مسئولیت محاسبه قیمت، تخفیف و موجودی کالا را برعهده داشت، عجیب بالا رفته.
هی باید بهش ریسورس اضافه می‌کردیم و هی فاکتور پشت‌فاکتور… هی سعی می کردیم کد های سمت node js رو باز نویسی کنیم اما باز مشکل وجود داشت

اما یک جایی ایستادم و به مانیتور زل زدم:
«واقعاً تا کی Scale out ؟ تا کی پول بریزیم برای پادهای بیشتر؟»

با بررسی لاگ های کمی که تو سیستم داشتیم و کمی تعمل بیشتر دیدم مشکل ما فقط زبان نیست بلکه دید طراحی ما برای همچین فشاری آماده نشده بود.
و دیدم که مشکل فقط «بار زیاد» نیست؛ مشکل این بود که مدلِ اجرا (single-threaded event loop + heavy allocations) با الگوی کاری سرویس (محاسبهٔ همزمان قیمت/تخفیف/موجودی) همخوانی نداشت.
هرچقدر پاد اضافه می‌کردیم، هزینه افزایش می‌یافت اما مشکل اصلی — CPU-bound hot path و فشار GC — همچنان پابرجا بود.

وقتی این‌طوری باشه، مهاجرت به runtimeی که برای concurrency و low-overhead execution طراحی شده (مثل Go) یک انتخاب فنی معقول و قابل دفاعه.

پس تصمیم گرفتم همه‌چیز را با Go دوباره بسازم؛
اما نه صرفاً rewrite — بلکه یک refactor درست در مون

اول از همه، متریک‌ها را جمع کردم.(این کار برای شروع کار حیاتیه)
p95، مصرف CPU، ترافیک همزمان، صف درخواست‌ها…
می‌خواستم دقیقاً بفهمم کجا درد می‌کنیم.

بعد شروع کردم به بازطراحی معماری:
سرویس باید کاملاً Stateless می‌شد
هر درخواست باید موازی و بدون dependency محلی قابل پاسخ باشد
عملیات سنگین محاسبات تخفیف باید Pipeline بشود

با کمک goroutineها و channelها در خواست ها را موازی و سبک تقسیم کردم و شد یک پازل برای گرفتن جواب نهایی
درخواست‌ها را تقسیم کردم، هرکدام موازی، هرکدام سبک، و در نهایت مثل قطعات پازل کنار هم جواب نهایی را ساختیم.

می خواستم برم سمت gRPC  که محدودیت زمان اجازه نداد پس رفتم سمت DB   و ایندکس گزاری های بهنر و جدا کردن read , write  از هم
کش کویری هم اورد وسط و بعد هم از ردیس واسه کش کمک گرفتم

برای invalidate   کردن قیمت و موجودی هم   معماری event driven   کمک گرفتم (حالا هی بگید چرا مهمه بدونیمش)

خوب گفتیم قبل از این که سرور بیاد پایین بفهیم چه خبره تو سیستم… پس  یک logging   , metrics   هم توی سیستم گذاشتم حتی گوروتین ها رو همو پروفایل کردم که oberservity  رو افزایش بدم
خلاصه بعد از این کارها .  latency تا ۶۰ درصد در پیک ها پایین امد…مصرف cpu  قابل حدس شد و هزینه ها  به شدت کم شد و بچه های محصول خوشحال (البته بعدش یک عالمه فیچر امد سمتمون)

در کل باید به  " performance  از همان ابتدای طراحی معماری فکر کرد"

| <Hessam Zaheri/>

این CPU-bound hot path یعنی چی؟

بذار خیلی ساده و دقیق براتون بگم:

🔥 CPU-bound

یعنی بخش یا کاری از برنامه که کاملاً به قدرت CPU وابسته است.
یعنی گلوگاهِ سرعت CPU است، نه I/O، نه شبکه، نه دیسک.

📚کارهای CPU-bound معمولاً شامل:

محاسبات سنگین (hashing، encryption)

پردازش داده زیاد

الگوریتم‌های تکراری و سنگین

encode/decode

پردازش تصویر/ویدئو
و… هستند.

⚡ Hot path

یعنی مسیر بسیار پرتکرار اجرای برنامه.
یعنی جایی که بیشترین زمان CPU صرف می‌شود.

📚مثلاً:

فانکشنی که هزاران بار در ثانیه صدا زده می‌شود

حلقه‌ی اصلی برنامه

ا inner loop الگوریتم


اHot path معمولاً جایی است که بهینه‌سازی واقعاً مهم است.


🔥⚡ وقتی می‌گوییم CPU-bound hot path

یعنی:

> بخش بسیار پرتکراری از برنامه که به شدت CPU را درگیر می‌کند و سرعت کل سیستم را تعیین می‌کند.


📚این مسیر معمولاً باید:

با دقت زیاد written بشه

اmemory allocations کم بشه

اbranchهای غیر ضروری حذف بشه

ا data structures درست انتخاب بشه

حتی گاهی inline یا SIMD بشه

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

🧩 مثال خیلی ساده (Go)

// Hot path: این فانکشن داخل یک حلقه میلیاردی صدا زده می‌شود.

// CPU-bound: محاسبه سنگین دارد.

func sumArray(arr []int) int {
total := 0
for _, v := range arr { // hot path loop
total += v * 2 // pure CPU work
}
return total
}

اینجا:
این حلقه میلیارد بار تکرار می‌شود → hot path
فقط محاسبه است → CPU-bound
پس CPU-bound hot path است.

👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0

مدیرعامل Hugging Face: حباب مدل‌های زبانی هوش مصنوعی شاید سال آینده بترکد
https://digiato.com/artificial-intelligence/hugging-face-ceo-says-were-in-an-llm-bubble

🎙️ عنوان پادکست:
Live from San Francisco, it's Cup o' Go! 1.26 release notes, speaker dinner, and more
خلاصه پادکست:
** این اپیزود Cup o' Go! به‌صورت زنده در San Francisco و در جمع GoSF ضبط شده و با حمایت Forge ارائه می‌شود. بخش اصلی برنامه مرور DRAFT RELEASE NOTES — Go 1.26 است؛ با تأکید بر بهبودهای احتمالی عملکرد، تغییرات کتابخانه استاندارد و ابزارها، و توصیه به آزمودن نسخه‌های پیش‌انتشار. در ادامه، به مناسبت Coding Challenge #100، ساخت یک BitTorrent Client در Go مطرح می‌شود؛ از پارس کردن فایل‌های .torrent و magnet تا تعامل با tracker و peers، انتخاب قطعه‌ها، کنترل نرخ و همزمانی ایمن....

🎙️ عنوان پادکست:
🎉 Surprise! 😯 A new security release is coming!
خلاصه پادکست:
**یک انتشار امنیتی غافلگیرکننده برای Go اعلام شده است: نسخه‌های Go 1.24.3 و Go 1.23.9 برای سه‌شنبه ۶ مه زمان‌بندی شده‌اند و توصیه می‌شود تیم‌ها برنامه‌ریزی ارتقا را انجام دهند و با انتشار یادداشت‌ها سریعاً به‌روزرسانی کنند. در بخش رویدادهای حضوری، کنفرانس GoWest در ۲۴ اکتبر در Lehi, Utah برگزار می‌شود و CFP تا ۳ ژوئن باز است؛ همچنین میت‌آپ‌های Go در Atlanta (۷ مه) و SF (۲۷ مه) برگزار می‌شوند. در به‌روزرسانی‌های فنی، پیش‌نویس یادداشت‌های انتشار Go 1....