🔵 عنوان مقاله
Kubernetes CPU Limits and Go

🟢 خلاصه مقاله:
به‌روزرسانی این مقاله توضیح می‌دهد که چرا runtime زبان Go به‌طور پیش‌فرض از محدودیت‌های CPU در Kubernetes خبر ندارد و چگونه همین موضوع می‌تواند به oversubscription و در نتیجه throttling و جهش‌های تاخیری منجر شود. راه‌حل عملی، هم‌راستاکردن GOMAXPROCS با سهم واقعی CPU کانتینر (براساس cgroups) است؛ یا با تنظیم متغیر محیطی GOMAXPROCS یا با استفاده از کتابخانه go.uber.org/automaxprocs تا runtime با ظرفیت واقعی زمان‌بندی کند. از نظر عملیاتی، برای سرویس‌های حساس به تاخیر بهتر است از limit سخت CPU پرهیز کرده و به request به‌همراه HPA اتکا کنید؛ در صورت اجبار به limit، سقف را طوری بگذارید که throttling حداقلی باشد و در صورت نیاز از CPU pinning و QoS مناسب بهره بگیرید. ارزیابی این تنظیمات با سنجه‌هایی مانند container_cpu_cfs_throttled_seconds_total و توزیع تاخیر و نیز متریک‌های runtime در Go، تصویر دقیقی از تاثیر بهینه‌سازی‌ها ارائه می‌کند.

#Kubernetes #Go #GOMAXPROCS #cgroups #CPUThrottling #ContainerPerformance #DevOps #SRE

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Making a Cross-Platform Game using Pion and WebRTC Datachannels

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

راه‌اندازی فعلی ساده و آزمایشی است و محدودیت‌هایی دارد: اتکای احتمالی به سیگنالینگ حداقلی، تکیه بر TURN در شرایط دشوار شبکه، نیاز به تنظیم دقیق قابلیت‌های Datachannel (سفارش‌دهی/قابلیت اطمینان)، دشواری اشکال‌زدایی، و نبود سرور اقتدارگرا یا rollback netcode که همگام‌سازی، ضدتقلب و پایداری را سخت‌تر می‌کند. با این حال پتانسیل توسعه بالاست: کانال‌های چندگانه برای ترافیک‌های مختلف، به‌کارگیری پیش‌بینی سمت مشتری و snapshot interpolation، افزودن امنیت و ضدتقلب، لابی و matchmaking، و پایش و سنجه‌ها. این مسیر برای نمونه‌سازی و آزمایش شبکه‌سازی بلادرنگ چندسکویی بسیار امیدوارکننده است. نویسنده: Srayan Jana.

#WebRTC #Pion #GameDev #Multiplayer #DataChannel #CrossPlatform #Networking

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Gojekyll: A Fast Go Implementation of Jekyll

🟢 خلاصه مقاله:
Gojekyll یک کلون سریع و «نسبتاً سازگار» از Jekyll است که به‌جای Ruby با Go پیاده‌سازی شده و با ارائه یک باینری تک‌فایلی، ساخت سایت‌های استاتیک را سریع‌تر و قابل‌حمل‌تر می‌کند. بسیاری از سایت‌های رایج Jekyll بدون تغییرات جدی اجرا می‌شوند، اما اگر به افزونه‌ها یا ویژگی‌های خاص متکی باشید، ممکن است نیاز به جایگزین یا اصلاح داشته باشید. برای تیم‌هایی که می‌خواهند Ruby را از استک خود حذف کرده و زمان ساخت و پیچیدگی CI/CD را کاهش دهند، Gojekyll گزینه‌ای قابل بررسی است.

#Jekyll #Gojekyll #Go #Ruby #StaticSiteGenerator #Performance #Portability #Jamstack

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Fibratus: Windows Kernel Exploration and Observability Tool

🟢 خلاصه مقاله:
فایبراتوس یک ابزار کاوش و Observability برای کرنل Windows است که اکنون بر «تشخیص، محافظت و شکار ترفندهای مهاجم» تمرکز دارد. این ابزار رویدادهای سیستمی مانند file I/O و درخواست‌های شبکه را جمع‌آوری می‌کند و با اسکن حافظه، تصویری دقیق از رفتار برنامه‌ها ارائه می‌دهد. چنین دیدی به تیم‌های امنیتی کمک می‌کند الگوهای مشکوک را شناسایی کنند، هشدارهای مهم را اولویت بدهند و در شکار تهدیدها و رسیدگی به رخدادها سریع‌تر عمل کنند. فایبراتوس همچنین برای توسعه‌دهندگان و تیم‌های IT که به درک عمیق‌تر از رفتار برنامه‌ها روی Windows نیاز دارند مفید است و از طریق مخزن GitHub در دسترس است.

#Fibratus #Windows #Kernel #Observability #ThreatHunting #Security #MemoryScanning

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

کلاد سونت ۴.۵ اومد با عنوان بهترین مدل کدنویسی در جهان.
رکوردهاش هم توی بنچمارک‌ها جالبه، بیشتر جاها عملکرد بالاتر از Opus 4.1.
اکستنشن Claude for Chrome هم برای کسایی که توی لیست انتظار بودن در دسترس قرار گرفت.
یه ویژگی ساخت فایل هم به چت‌بات اضافه شده و میتونه براتون اسلاید و داک بسازه.
واکنش‌ها خوب بوده و میگن بیشترین جهش عملکرد رو از زمان معرفی Sonnet 3.6 داشته.

این مدل میتونه بیشتر از ۳۰ ساعت به صورت خودکار روی پروژه‌های چند مرحله‌ای کار کنه. برای Opus 4 عددش ۷ ساعت هست، این نیاز نظارت رو کم میکنه و رسما بیش از ۱ روز میتونه خودکار فعالیت خودش‌رو ادامه بده.

<Soroush Ahmadi/>

چرا از جاوا و پایتون برای نرم افزارهای سیستم های هوافضا نمیشه استفاده کرد؟
1-قطعیت (Determinism):
در زبان هایی مثل جاوا و پایتون به خاطر وجود garbage collection و مبتنی بر JVM بودن اجرای برنامه دقیقا قابل پیش بینی نیست. ممکنه برنامه یه لحظه به خاطر garbage collector متوقف بشه یا pause کنه. تو نرم افزارهای real time همچین چیزی قابل قبول نیست.
به عبارت دیگه یه حلقه توی جاوا یه بار ممکنه یک میلی ثانیه طول بکشه اما دفعه بعد 5 میلی ثانیه طول بکشه دلیل این امر اینه که JIT و gc معلوم نیست کی عمل می کنن و حافظه رو پس می گیرن. پایتون هم به همین دلیل که gc داره عملکردش این شکلیه.
2-زمانبندی سخت گیرانه(Hard real-time constraints): نرم افزارهای هوافضا باید مشخص، کوتاه و قطعی واکنش نشان دهند اما جاوا و پایتون همچین تضمینی نمی دهند.
3-ایمنی و استانداردها :
صنعت هوافضا از استانداردهایی مثل DO-178C پیروی می‌کند. Ada و C ابزارها و کتابخانه‌های تأییدشده‌ای برای این استاندارد دارند اما برای جاوا و پایتون چنین پشتیبانی و تأیید رسمی بسیار محدود یا تقریباً وجود ندارد.
4-کارایی (Performance & Footprint):
پایتون کنده چون مفسریه جاوا هم به خاطر JVM و مدیریت حافظه سربار زیادی داره که خب توی سیستم های هوافضا که سرعت مهمه و منابع سخت افزاری محدودی داریم نمیشه یه برنامه کند و برنامه ای که کلی منابع میخواد رو اجرا کنیم.
در نهایت باید بگم که زبان هایی که باهاشون نرم افزارهای سیستم های هوافضا، نظامی و حساس رو میسازن Ada-Spark ada - C  و جدیدا Rust هستند.

<Mohsen Shojaei Yeganeh/>

👇👇👇👇👇👇👇
@software_Labdon

🔵 عنوان مقاله
Go Allocations Explorer Extension for VSCode

🟢 خلاصه مقاله:
این افزونه با نام Go Allocations Explorer Extension برای VS Code به برنامه‌نویسان Go کمک می‌کند تا محل و میزان تخصیص حافظه را بر پایه بنچمارک‌های موجودشان مستقیماً داخل ویرایشگر ببینند. با اجرای go test -bench و استفاده از -benchmem، نتایج تخصیص‌ها جمع‌آوری و به فهرستی قابل پیمایش تبدیل می‌شود تا بتوانید به‌سرعت هات‌اسپات‌ها را یافته و از همان ورودی‌ها به کد مربوطه بپرید. امکان اجرا و تکرار بنچمارک‌ها، مشاهده و مقایسه سریع نتایج، و مرتب‌سازی/فیلتر کردن بر اساس پکیج، تست یا تابع فراهم است. راه‌اندازی ساده است، فقط نیاز به ابزار Go دارد و روی macOS، Linux و Windows کار می‌کند. خروجی‌ها در خود VS Code به شکل قابل فهم ارائه می‌شوند تا کاهش تخصیص‌ها، کم شدن فشار GC و بهبود تأخیر به‌صورت مستمر و در جریان کدنویسی انجام شود.

#Go #VSCode #Golang #Performance #Benchmarking #MemoryAllocations #Profiling #DeveloperTools

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

می‌خوام یک وب سایت خیلی خوب برای گولنگ بهتون معرفی کنم، https://awesome-go.com/
این وب سایت فوق العادس برای دیدن کد تو هر موضوعی که فکرشو کنید در کانکارنسی، CLI، وب و هرچیز دیگه ای.
کافیه برین داخلش عنوان ابزار، کتابخونه یا حتی نمونه کد مورد نظر خودتون رو پیدا کنید و ریپازیتوری اوپن سورس مرتبطش رو باز کنید و داکیومنشن یا کدش رو بخونید.
واقعا جذابه پیشنهاد میکنم حتما ببینید

<Abolfazl Alizadeh/>

🔵 عنوان مقاله
Building Conway’s Game of Life with raylib-go

🟢 خلاصه مقاله:
یک پروژه تفننی و آموزشی است: پیاده‌سازی Conway’s Game of Life با استفاده از raylib-go در Go. برنامه یک پنجره باز می‌کند، شبکه‌ای دوبعدی از سلول‌ها می‌سازد و هر فریم سلول‌های زنده و مرده را به‌صورت مستطیل‌های رنگی رسم می‌کند. قوانین استاندارد (شمارش ۸ همسایه و اعمال قوانین کم‌جمعیتی، بقا، تراکم و تولیدمثل) با double-buffering اجرا می‌شوند تا محاسبات نسل بعدی تمیز و قابل اتکا باشد و در صورت نیاز امکان دورپیچی مرزها هم در نظر گرفته شده است. تعامل‌ها شامل توقف/ادامه، گام‌به‌گام، تنظیم سرعت، پاک‌سازی یا تصادفی‌سازی صفحه و تغییر وضعیت سلول‌ها با کلیک ماوس است؛ ذخیره/بارگذاری الگوهای ساده هم قابل افزودن است. حلقه به‌روزرسانی مستقل از نرخ رندر زمان‌بندی می‌شود تا اجرای روان و کارآمد حفظ شود و روی Windows، macOS و Linux به‌خوبی اجرا می‌شود. کد نهایی ارائه شده و برای توسعه ایده‌هایی مانند کتابخانه الگوها، کنترل‌های بهتر زوم/پن، گرادیان‌رنگ بر اساس سن سلول و ارزیابی عملکرد قابل گسترش است.

#ConwaysGameOfLife #raylib #raylibgo #Go #GameDev #CellularAutomata #GraphicsProgramming

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

مشکل "mutex copying" در Go یعنی کپی کردن یک mutex به جای استفاده از pointer به آن. این کار باعث می‌شه که mutex اصلی و کپی شده دو شیء جداگانه بشن و قفل‌گذاری درست کار نکنه.

چرا مشکل ساز است؟

وقتی یک mutex رو کپی می‌کنی، حالت داخلی اش (locked/unlocked) کپی نمی‌شه به درستی و هر کدوم مستقل عمل می‌کنن. این یعنی race condition و عدم هماهنگی بین goroutine ها.


1. همیشه از pointer receiver استفاده کن وقتی mutex داری:
func (c *Counter) method()


2. هرگز mutex رو به صورت value پاس نده:
func badFunc(mu sync.Mutex)


3. ا Go vet ابزار خوبیه که این مشکل رو پیدا می‌کنه:
  

   go vet ./...
   

4. اگه struct رو embed می‌کنی**، حواست باشه که اون رو کپی نکنی

5. **انواع Mutex ها همه این مشکل رو دارن:
sync.Mutex,
sync.RWMutex,
sync.WaitGroup,
sync.Cond


این یکی از رایج‌ترین اشتباهات تو Go هست، خصوصا برای کسایی که تازه شروع کردن!

💙نمونه استفاده درست👇
‍

package main

import (
    "fmt"
    "sync"
    "time"
)

type Counter struct {
    mu    sync.Mutex
    value int
}

func (c *Counter) Increment() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value++
    fmt.Printf("Value: %d\n", c.value)
}

func goodFunction(c *Counter) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value = 100
}

func main() {
    counter := &Counter{}
    
    var wg sync.WaitGroup
    
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter.Increment() 
        }()
    }
    
    wg.Add(1)
    go func() {
        defer wg.Done()
        goodFunction(counter)
    }()
    
    wg.Wait()
    fmt.Printf("Final value: %d\n", counter.value)
}

type SafeMap struct {
    mu sync.RWMutex
    data map[string]int
}

func NewSafeMap() *SafeMap {
    return &SafeMap{
        data: make(map[string]int),
    }
}

func (sm *SafeMap) Set(key string, value int) {
    sm.mu.Lock()
    defer sm.mu.Unlock()
    sm.data[key] = value
}

func (sm *SafeMap) Get(key string) (int, bool) {
    sm.mu.RLock()
    defer sm.mu.RUnlock()
    val, ok := sm.data[key]
    return val, ok
}

❤️نمونه اشتباه

package main

import (
    "fmt"
    "sync"
    "time"
)

type Counter struct {
    mu    sync.Mutex
    value int
}

func (c Counter) Increment() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value++
    fmt.Printf("Value: %d\n", c.value)
}
func badFunction(c Counter) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value = 100
}

func main() {
    counter := Counter{}
    
    for i := 0; i < 5; i++ {
        go counter.Increment() 
    }
    
    go badFunction(counter) 
    
    time.Sleep(time.Second)
    fmt.Printf("Final value: %d\n", counter.value)
}

🚀 به دنیای توسعه و تکنولوژی خوش اومدی!

اگر به موضوعات زیر علاقه‌مندی:

🔹 Golang
🔹 Linux & DevOps
🔹 Software Engineering
🔹 AI & Machine Learning
🔹 فرصت‌های شغلی ریموت (خارجی و داخلی)

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

📌 از این لینک همه چنل‌هامونو یه‌جا ببین و جوین شو:

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

📢 اگر تلگرام پرمیوم دارید، کانال ما رو Boost کنید ! 🚀

با Boost کردن کانال، به رشد و دیده شدن ما بیشتر کمک کنید💙

https://t.iss.one/boost/gopher_academy

این کتاب خیلی ساده و روان توضیح میده چرا Rust اینقدر سر و صدا کرده و چرا خیلی‌ها دارن سمتش میرن:

نشون میده چطوری با سیستم ownership و borrowing میشه حافظه رو بدون دردسر مدیریت کرد

توضیح میده چرا توی Rust باگ‌هایی مثل null pointer یا data race کلاً از همون اول جلوی راهت سبز نمی‌شن

یاد میده چطوری میشه به راحتی برنامه‌های چندنخی و امن نوشت، بدون استرس خطاهای عجیب غریب

تأکید می‌کنه که همه‌ی این امکانات رو می‌گیری، ولی سرعتش در حد C/C++ باقی می‌مونه

📌 Span and Size Class in Go

🔹 یکی از مفاهیم کلیدی در مدیریت حافظه گو Span است.

🧩 Span

* یک Span شامل یک یا چند Page متوالی است.
* هر Span به چند شیء هم‌سایز تقسیم می‌شود.
* این کار باعث می‌شود Go از استراتژی segregated fit allocation استفاده کند:

* تخصیص بهینه برای اندازه‌های مختلف
* کاهش fragmentation (تکه‌تکه شدن حافظه)

🔸 اطلاعات هر Span در یک ساختار به نام mspan ذخیره می‌شود:

* آدرس شروع اولین Page
* تعداد Pageها
* تعداد اشیاء تخصیص‌یافته
* و سایر متادیتا

📦 Size Class

ا * Go سایز اشیاء را در گروه‌هایی به نام Size Class تقسیم‌بندی می‌کند.
* هر Span دقیقاً به یک Size Class تعلق دارد.
ا * Go در مجموع ۶۸ Size Class تعریف کرده است:

ا * Class 0 → برای اشیاء بزرگ‌تر از 32KB
ا * Class 1 تا 67 → برای اشیاء کوچک و خیلی کوچک

به زبان ساده:
ا Go با تقسیم حافظه به Span و گروه‌بندی آن‌ها در Size Class**، تخصیص حافظه را سریع و بهینه نگه می‌دارد.

➖➖➖➖➖➖➖➖
👑 @gopher_academy

📌 Two spans with different size classes

🔹 هر Span در Go به یک Size Class خاص تعلق دارد. این Size Class مشخص می‌کند که:

* چند Page در Span قرار بگیرد
* هر Page چند Object را در خود جای دهد

📦 مثال‌ها (تصویر بالا):

ا 1. Size Class 38

* اندازه هر شیء: 2048B
* یک Page (۸KB) دقیقاً ۴ تا شیء 2048B را جا می‌دهد.
* پس کل Span = ۱ Page + ۸ Object

ا 2. Size Class 55

* اندازه هر شیء: 10880B
* هر شیء بزرگ‌تر از یک Page است.
* Span در اینجا روی ۴ Page گسترده می‌شود و ۳ Object را نگه می‌دارد.

🧩 Tail Waste (هدررفت انتهایی)

* دلیل اینکه برای Size Class 55 از ۴ Page استفاده می‌شود و نه ۲ Page، کاهش هدررفت حافظه است.
* اگر ۲ Page می‌گرفت → هدررفت = 5504B
* اگر ۴ Page بگیرد → هدررفت = 128B
* ✅ پس با استفاده از صفحات بیشتر، fragmentation به حداقل می‌رسد.


به زبان ساده:
ا Go با استفاده از Span Class و محاسبه‌ی دقیق Tail Waste**، حافظه را به شکل بهینه تخصیص می‌دهد و از هدررفت جلوگیری می‌کند.

➖➖➖➖➖➖➖➖
👑 @gopher_academy

📌 Tail waste in span


🔹 هر Span ممکنه مقداری فضای استفاده‌نشده در انتهای خودش داشته باشه، به این فضا می‌گن Tail Waste.

* مثال (تصویر بالا):

* اگر Span با ۲ Page ساخته بشه → Tail Waste = 5504B
* اگر Span با ۴ Page ساخته بشه → Tail Waste = 128B
✅ پس Go برای کاهش هدررفت، از ۴ Page استفاده می‌کنه.

🧩 چرا فقط 67 Size Class داریم؟

برنامه‌ی Go می‌تونه آبجکت‌هایی با سایزهای مختلف بخواد، اما Go فقط 67 Size Class برای آبجکت‌های کوچک تعریف کرده.

📍 سوال: اگه ما آبجکت 300B بخوایم که دقیقاً تو جدول Size Classes نیست، چی می‌شه؟

* Go سایز رو Round Up می‌کنه به نزدیک‌ترین Size Class بزرگ‌تر.
* اینجا 300B → می‌شه 320B

🔑 نکته مهم:
اون چیزی که ما در تصویر به‌عنوان "Object" می‌بینیم، دقیقاً آبجکت برنامه نیست، بلکه یک Size Class Object هست که توسط Runtime مدیریت می‌شه.

به زبان ساده:

*ا Go با Tail Waste Optimization جلوی هدررفت زیاد رو می‌گیره.
* با Size Class Rounding هم حافظه رو سریع‌تر و ساده‌تر مدیریت می‌کنه.
➖➖➖➖➖➖➖➖
👑 @gopher_academy

📌User objects and size class objects


🔹 در Go، آبجکت‌های واقعی برنامه (User Objects) داخل آبجکت‌های مربوط به Size Class قرار می‌گیرن.

* سایز User Object معمولاً از Size Class Object کوچیک‌تره → همین اختلاف باعث Waste می‌شه.
* علاوه بر اون، در انتهای Span هم یه بخشی از حافظه استفاده‌نشده باقی می‌مونه (Tail Waste).
* مجموع این دو نوع هدررفت = Total Waste.

🧩 مثال (Size Class 55):

* هر Size Class Object = 10880B
* 3 تا User Object (هرکدوم 10241B) توی Span جا می‌گیرن.
* Waste ناشی از اختلاف سایز: 1917B
* Tail Waste: 128B
* Total Waste = 1917 + 128 = 2045B ≈ 6.24% کل Span

🔑 نتیجه:
حتی با وجود Segregated Fit Strategy که هدفش کاهش Fragmentation هست، باز هم کمی هدررفت اجتناب‌ناپذیر وجود داره.
➖➖➖➖➖➖➖➖
👑 @gopher_academy

☝️👆👆👆
دوستان عزیز، این پستی که ریپلای کردم به‌روزرسانی میشه ✨
می‌تونید ادامه‌ی مقالات این بخش رو همیشه از همینجا دنبال کنید و بخونید 📚

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

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

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