🔵 عنوان مقاله
Trends in the Go Ecosystem in 2025

🟢 خلاصه مقاله:
گزارش تازه JetBrains از اکوسیستم Go در سال ۲۰۲۵ نشان می‌دهد جامعه Gophers همچنان به کتابخانه‌های ساده، پایدار و کم‌وابستگی تکیه دارد. در وب، گرایش به فریم‌ورک‌های سبک و سریع پررنگ است و Gin بیشترین توجه را جلب کرده؛ در کنار گزینه‌هایی مثل Echo، Fiber و Chi. برای دسترسی به داده نیز ابزارهایی مانند GORM و sqlx رایج‌اند و معیارهایی مثل کیفیت مستندات، ثبات و ردپای وابستگی کوچک نقش تعیین‌کننده دارند. در تست، رویکردهای idiomatic مثل go test و table-driven tests همراه با testify و ابزارهای mocking، به‌علاوه ادغام در CI و توجه به پوشش کد، جریان غالب‌اند؛ علاقه به fuzzing و property-based testing نیز رو به رشد است. دستیارهای هوشمند کدنویسی به ابزار روزمره تبدیل شده‌اند: GitHub Copilot و ChatGPT بیشترین اشاره را دارند، JetBrains AI Assistant در IDEها پذیرفته شده و گزینه‌هایی مثل Codeium و Tabnine هم برای ملاحظات حریم خصوصی و مجوزدهی مطرح‌اند. جمع‌بندی گزارش: انتخاب آگاهانه کتابخانه‌های مینیمال (با برتری Gin در سرویس‌های وب)، سرمایه‌گذاری در ارگونومی تست و CI، و تدوین سیاست روشن برای استفاده از AI جهت افزایش بهره‌وری بدون افت کیفیت کد.

#Go #Golang #JetBrains #Gin #Testing #AIAssistants #DeveloperSurvey #2025Trends

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Did You Know Postgres Tables are Limited to 1,600 Columns?

🟢 خلاصه مقاله:
اگر نمی‌دانستید، در Postgres هر جدول حداکثر ۱۶۰۰ ستون می‌تواند داشته باشد. این یک محدودیت سخت در هسته سیستم است و با NULL بودن فیلدها یا TOAST دور زده نمی‌شود. اگر شماره issue 226 در سال 2017 را خوانده باشید، احتمالاً این نکته را به خاطر دارید. این سقف به معنای آن است که طراحی‌هایی با جدول‌های بسیار عریض—مثل هر شاخص یک ستون یا طرح‌های EAV تثبیت‌شده—به‌سرعت به حد می‌خورند. راه‌حل‌های بهتر شامل نرمال‌سازی، تفکیک عمودی، تبدیل ستون‌ها به سطرها برای سنجه‌ها، یا استفاده از JSONB برای ویژگی‌های کم‌استفاده و پراکنده است. جدول‌های خیلی عریض علاوه بر ریسک رسیدن به سقف، هزینه I/O و نگهداری را بالا می‌برند. نتیجه عملی: با در نظر گرفتن حد ۱۶۰۰ ستون، از طرح‌های باریک‌تر و انعطاف‌پذیرتر استفاده کنید و قبل از اعمال مهاجرت‌ها، تعداد ستون‌ها را بررسی کنید.

#Postgres #PostgreSQL #SQL #DatabaseDesign #DataModeling #SchemaDesign #JSONB #SoftwareEngineering

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Go's Runtime May Someday Start Explicitly Freeing Some Internal Memory?

🟢 خلاصه مقاله:
** Chris Siebenmann به ایده‌ای اشاره می‌کند که هنوز توسعه نیافته است: احتمال اینکه Go Runtime در آینده بتواند بخشی از حافظه داخلی خودش را به‌صورت صریح به سیستم‌عامل برگرداند. هدف، کاهش RSS و رفتار بهتر زیر فشار حافظه—به‌ویژه در سرویس‌های طولانی‌مدت و محیط‌های کانتینری—است، اما با ریسک افت کارایی به‌خاطر افزایش syscall‌ها، page faultها و از دست رفتن cacheها. هنوز جزئیات و زمان‌بندی روشن نیست و اگر هم پیش برود، احتمالاً به‌صورت آزمایشی و opt-in ارائه می‌شود. در صورت پیاده‌سازی در نسخه‌های بعدی Go، این تغییر می‌تواند شیوه‌های مرسوم تنظیم حافظه در تولید را تحت تأثیر قرار دهد.

#Go #Golang #Runtime #MemoryManagement #GarbageCollection #Performance #Containers #Cloud

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Bleve: A Modern Indexing and Search Library

🟢 خلاصه مقاله:
** Bleve یک کتابخانه قدیمی و قابل اتکا برای ایندکس‌گذاری و جست‌وجو است که از تمرکز صرف بر جست‌وجوی متنی فراتر رفته و به یک راهکار مدرن و چندمنظوره تبدیل شده است. اکنون علاوه بر متن، از اعداد، داده‌های تاریخ و زمان، بردارها و جست‌وجوی مکانی نیز پشتیبانی می‌کند و امکان اجرای پرس‌وجوهای متنوعی مانند فیلترهای عددی و زمانی، جست‌وجوی شباهت برداری و پرس‌وجوهای مکانی (مثل محدوده، شعاع و چندضلعی) را فراهم می‌سازد. این قابلیت‌ها در قالب یک API یکپارچه ارائه می‌شوند تا توسعه‌دهندگان بدون چندپارچگی ابزارها، تجربه‌های جست‌وجوی غنی بسازند. یک مثال سریع هم نحوه ساخت ایندکس، افزودن اسناد و اجرای انواع پرس‌وجوها را به‌سادگی نشان می‌دهد.

#Bleve #Search #Indexing #FullTextSearch #VectorSearch #Geospatial #InformationRetrieval

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Google's Agent Development Kit (ADK) for Go

🟢 خلاصه مقاله:
** گوگل نسخه Go از Agent Development Kit (ADK) را عرضه کرده است؛ کیتی که پیش‌تر برای Python و Java در دسترس بود و برای ساخت و استقرار عامل‌های هوش مصنوعی به‌کار می‌رود. ADK با حذف بخش بزرگی از کدنویسی تکراری در ارکستراسیون و ترکیب گردش‌کار عامل‌ها، توسعه را ساده می‌کند. این چارچوب هم از نظر مدل (model-agnostic) و هم از نظر استقرار (deployment-agnostic) مستقل است، بنابراین می‌توان آن را با LLMهای مختلف و در محیط‌های ابری، داخلی یا لبه اجرا کرد. همچنین با فریم‌ورک‌های دیگر سازگار است و امکان پذیرش تدریجی در کنار پشته‌های موجود را می‌دهد. برای تیم‌های Go، این پشتیبانی یک مسیر سازگار و منعطف برای ساخت عامل‌ها فراهم می‌کند، بدون قفل‌شدن به مدل یا زیرساخت خاص.

#Google #ADK #Go #AI #Agents #Python #Java #DeveloperTools

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Red, Green, Refactor: Writing Perfect Go, with TDD

🟢 خلاصه مقاله:
** این مطلب سه دیدگاه مکمل برای بهبود کدنویسی در Go ارائه می‌کند: به‌کارگیری چرخه Red–Green–Refactor در TDD برای ساخت پکیج‌های کوچک و APIهای شفاف و ریفکتور امن با تکیه بر تست‌های سریع؛ مرور کاربردی John Arundel از sync.Pool برای کاهش فشار تخصیص در مسیرهای داغ، با تأکید بر اینکه این سازوکار «کش» نیست و اقلام آن ممکن است هر لحظه حذف شوند، و استفاده از آن فقط با اندازه‌گیری و پروفایل توجیه‌پذیر است؛ و توضیح Jesús Espino در Devtrovert درباره Scanner در کامپایلر Go و نحوه تبدیل کد منبع به توکن‌ها، که منشأ برخی خطاها و رفتار ابزارها را روشن می‌کند. جمع‌بندی: با TDD کیفیت و قابلیت نگه‌داری را بالا ببرید، sync.Pool را صرفاً وقتی به کار بگیرید که داده‌ها گلوگاه تخصیص را نشان می‌دهند، و با شناخت روند اسکن، ابزار بهتر و کد خواناتر بسازید.

#Go #Golang #TDD #syncPool #Refactoring #GoCompiler #Performance #Profiling

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Understanding the Go Compiler: The Scanner

🟢 خلاصه مقاله:
این مقاله، با معرفی نقش Scanner در Go Compiler، توضیح می‌دهد که چگونه متن خام به توکن‌های دقیق و موقعیت‌دار تبدیل می‌شود تا مراحل بعدی مانند parser و type checker بتوانند روی آن کار کنند. تمرکز مقاله بر سادگی قواعد واژگانی Go، نبود preprocessor و سازوکار semicolon insertion است که باعث می‌شود کد خواناتر و ابزارها قابل‌اعتمادتر باشند.

نویسنده انواع توکن‌ها را مرور می‌کند: شناسه‌ها با پشتیبانی Unicode، اعداد صحیح و اعشاری و imaginary با امکان استفاده از underscore، رشته‌های interpreted و raw، و rune literals. همچنین به نحوه‌ی تشخیص و نادیده‌گیری یا نگه‌داری کامنت‌ها بر حسب نیاز ابزار اشاره می‌کند. بخشی هم به گزارش خطا و ادامه‌ی اسکن در مواجهه با ورودی‌های نامعتبر می‌پردازد و اهمیت go/token برای نگه‌داری دقیق موقعیت‌ها را توضیح می‌دهد.

در پایان، با معرفی بسته‌های go/scanner و go/token، مسیر ساخت ابزارهایی مثل linter و formatter نشان داده می‌شود و تفاوت آن‌ها با پیاده‌سازی داخلی کامپایلر بیان می‌گردد. نتیجه اینکه طراحی خطی و ساده‌ی Scanner، سرعت ابزار Go و کیفیت پیام‌های خطا و تحلیل‌های ایستا را ممکن کرده است.

#Go #Golang #GoCompiler #Scanner #Lexer #Parsing #StaticAnalysis #ProgrammingLanguages

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

یه ابزار مشابه شبیه به Make منتهی جدیدتر و با فرمت Yaml که با زبان Go ساخته شده.

#Makefile #Task #Taskfile #Tools #GNU #GoLang #Go #Build #Workflow #Yaml

https://taskfile.dev

🔗 لینک کانال‌هامون:
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