این تصویر به‌خوبی ساختار سلسله‌مراتبی (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....

🔵 عنوان مقاله
How We Avoided Side-Channels in Our New Post-Quantum Go Cryptography Libraries

🟢 خلاصه مقاله:
ما دو کتابخانه امضای دیجیتال پساکوانتومی برای Go معرفی می‌کنیم: ml-dsa مطابق FIPS-204 و go-slh-dsa مطابق FIPS-205. تمرکز اصلی—فراتر از درستی و کارایی—کاهش خطر کانال‌های جانبی بوده است. برای این منظور، جریان کنترل و الگوهای دسترسی به حافظه را مستقل از راز نگه داشتیم، مسیر اجرای یکنواخت ایجاد کردیم و مقادیر میانی حساس را با دقت مدیریت و پاک‌سازی کردیم. در پیاده‌سازی‌ها از شاخه‌زنی و جداول وابسته به داده‌های محرمانه پرهیز شده، مقایسه‌ها و کاهش‌ها به‌صورت ثابت‌زمان انجام می‌شوند و رابط‌های برنامه‌نویسی طوری طراحی شده‌اند که استفاده امن به‌طور پیش‌فرض برقرار باشد. امضا به‌صورت مطابق استاندارد و تعیین‌گر پیاده‌سازی شده تا تکیه بر تصادفی‌سازی محیطی و تنوع زمانی کاهش یابد. آزمون‌های آماری و تفاضلی برای رفتار ثابت‌زمان، تست‌های property-based و فازینگ روی معماری‌های مختلف انجام شده و در بازبینی کد، هم درستی رمزنگاری و هم رفتار ریزمعماری بررسی شده است. حاصل، دو کتابخانه Go برای ML-DSA و SLH-DSA است که گزینه‌های عملی و مقاوم در برابر کانال جانبی برای امضای پساکوانتومی در اختیار توسعه‌دهندگان قرار می‌دهند.

#PostQuantum #Cryptography #GoLang #SideChannel #FIPS204 #FIPS205 #MLDSA #SLHDSA

🟣لینک مقاله:
https://golangweekly.com/link/177181/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
goquery v1.11: jQuery-Like HTML/DOM Manipulation Methods

🟢 خلاصه مقاله:
goquery v1.11 کتابخانه‌ای برای زبان Go است که شیوه‌ای آشنا و شبیه به jQuery برای کار با HTML و CSS در سمت سرور ارائه می‌دهد. با استفاده از انتخاب‌گرهای CSS، پیمایش DOM و زنجیره‌کردن متدها، می‌توانید به‌سادگی عناصر را انتخاب کنید، متن و ویژگی‌ها را بخوانید یا ویرایش کنید و بین والد، فرزند و همسایه‌ها حرکت کنید. این رویکرد برای وب‌اسکرپینگ، استخراج محتوا، بررسی خودکار کیفیت نشانه‌گذاری و تبدیل‌های سمت سرور بسیار کاربردی است. طراحی API تا حد ممکن با الگوی ذهنی jQuery هماهنگ است و یادگیری آن برای توسعه‌دهندگانی که تجربه front-end دارند سریع خواهد بود. فهرست کامل توابع پشتیبانی‌شده و مثال‌ها در مستندات رسمی ارائه شده است.

#goquery #Go #jQuery #HTML #CSS #WebScraping #DOM

🟣لینک مقاله:
https://golangweekly.com/link/177196/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Scriggo: Template Engine and Go Embeddable Interpreter

🟢 خلاصه مقاله:
Scriggo یک موتور قالب و مفسر قابل‌جاسازی برای Go است که تجربه‌ای مشابه ERB در Ruby/Rails را به اکوسیستم Go می‌آورد. با آن می‌توانید منطق و عبارت‌های Go را مستقیماً داخل قالب‌ها قرار دهید و محتوای پویا بسازید.

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

این ابزار به‌صورت کتابخانه در برنامه‌های Go ادغام می‌شود و برای ساخت خروجی‌های پویا مانند صفحات CMS، ایمیل‌ها یا تولید محتوای مبتنی بر قالب مناسب است؛ ترکیبی از امکانات Go با تفسیر زمان‌اجرا برای رسیدن سریع‌تر از ایده به خروجی.

#Go #Scriggo #TemplateEngine #Interpreter #ERB #RubyOnRails #Templating

🟣لینک مقاله:
https://golangweekly.com/link/177198/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

خبر داغ برنامه‌نویسا : گزارش Stack Overflow 2025 نشون می‌ده ۸۴% دولوپرها از AI مثل ChatGPT و GitHub Copilot استفاده می‌کنن، اما ۶۶% کلافه از کدهای 'تقریباً باگی' هستن! Cursor و Copilot دارن کدینگ رو متحول می‌کنن، ولی دیباگش وقت‌گیره.

https://survey.stackoverflow.co/2025/ai/

<Arash/>

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

کاهش هزینه سیستم‌های هوش مصنوعی با Semantic Caching

با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب می‌شه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث می‌شه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.

یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور می‌شه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.

در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت می‌کنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق می‌کنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.

اینجاست که Semantic Caching وارد می‌شه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه می‌کنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر می‌شه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.

روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل می‌شه. بعد با بردارهای موجود در کش با Semantic Search مقایسه می‌شه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده می‌شه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره می‌شه تا دفعه بعدی قابل استفاده باشه.

پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست می‌ده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.

معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون می‌ده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص می‌کنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.

یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.

<Reza Jafari/>

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

🔵 عنوان مقاله
Git 2.52 has been released

🟢 خلاصه مقاله:
نسخه Git 2.52 منتشر شد و با تمرکز بر بهبودهای کوچک اما کاربردی، تجربه روزمره کار با Git را روان‌تر می‌کند. مهم‌ترین تغییر، افزودن دستور جدید git last-modified است که برای هر فایل در یک پوشه مشخص می‌کند آخرین بار در کدام commit تغییر کرده است؛ قابلیتی مفید برای تعیین مالکیت کد، بازرسی تغییرات، رفع خطاها و اولویت‌بندی بازبینی‌ها. این دستور برای اسکریپت‌ها و CI نیز کاربردی است، چون می‌تواند به‌صورت خودکار آخرین commit مربوط به هر فایل را خروجی دهد و کارهای مانند بیلدهای افزایشی و خلاصه‌سازی تغییرات را ساده کند. فراتر از این، Git 2.52 شامل مجموعه‌ای از بهبودهای جزئی و پرداخت‌های کوچک است و به‌روزرسانی آن برای بیشتر کاربران بدون دردسر خواهد بود.

#Git #VersionControl #GitRelease #DevTools #SoftwareDevelopment #CLI #OpenSource

🟣لینک مقاله:
https://golangweekly.com/link/177210/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Context-Aware Dialer Methods Coming to Go 1.26

🟢 خلاصه مقاله:
** این تغییر که نخستین‌بار چهار سال پیش مطرح شد، قرار است در Go 1.26 و اوایل 2026 به net.Dialer اضافه شود و «متدهای شبکه‌محورِ مبتنی بر context» را به‌صورت رسمی در اختیار قرار دهد. با این کار، برقراری اتصال برای شبکه‌های خاص (مثل TCP/UDP) با رعایت لغو شدن‌ها و ضرب‌الاجل‌های context به‌صورت یکپارچه انجام می‌شود. تغییرات افزایشی است و سازگاری گذشته حفظ می‌شود؛ کدهای فعلی بدون تغییر کار می‌کنند و پروژه‌هایی که کنترل دقیق‌تری می‌خواهند می‌توانند از متدهای جدید استفاده کنند.

#golang #go126 #netDialer #context #networking #gostdlib #apiDesign

🟣لینک مقاله:
https://golangweekly.com/link/177180/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Building Dolt on Windows: The 'Pacman' Game

🟢 خلاصه مقاله:
این مجموعه به سه موضوع کلیدی برای توسعه‌دهندگان می‌پردازد: ساخت Dolt روی Windows با تمثیل بازی «Pacman» برای شکار وابستگی‌ها و رفع ناسازگاری‌های سیستم‌عاملی؛ بررسی عملی Crush، عامل کدنویسی مبتنی بر TUI از Charm توسط Elian Deogracia-Brito که تجربه‌ی کار یکپارچه در ترمینال را ارزیابی می‌کند؛ و راهنمای Graham Helton برای پروفایلینگ برنامه‌های Go با pprof و k6 روی نمونه‌ای به نام Pears. پیام اصلی: ایجاد ساخت‌های پایدار روی Windows نیازمند مهار تفاوت‌های پلتفرمی است، ابزارهای TUI مانند Crush می‌توانند تمرکز و سرعت جریان کاری ترمینال‌محور را بالا ببرند، و ترکیب pprof با k6 باید به عادت روزمره‌ی تیم برای اندازه‌گیری، تحلیل و بهینه‌سازی عملکرد تبدیل شود.

#Dolt #Windows #Pacman #Crush #Charm #TUI #Go #pprof #k6 #Profiling

🟣لینک مقاله:
https://golangweekly.com/link/177187/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy