🛠 ابزارها در حوزه Linters و تحلیل کد Go

1. Actionlint

* وظیفه: بررسی استاتیک فایل‌های workflow در GitHub Actions (.yml/.yaml در مسیر .github/workflows/)
* ویژگی‌ها:

* بررسی نحوی و semantic expressions (${{ }})
* اعتبارسنجی فراخوانی Actionها، ورودی/خروجی، نوع runners و امنیت اسکریپت‌ها
* استفاده از ShellCheck و Pyflakes برای lint کردن inline scripts
* CLI + کتابخانه Go برای استفاده در ابزارهای CI/CD ([megalinter.io][1])

---

2. Hadolint

* وظیفه: lint کردن Dockerfile
* ویژگی‌ها:

* نوشته شده با Haskell**؛ استفاده از AST برای تحلیل دستورات Docker
* ادغام با **ShellCheck برای بررسی اسکریپت‌های bash داخل RUN
* امکان ignore قوانین، سفارشی‌سازی severity، trusted registries و خروجی‌های متنوع (json, sarif, checkstyle)
* قابلیت اجرا به صورت binary، container تصویر Docker و ادغام در CI یا IDE ([megalinter.io][2])

---

3. deadcode

* وظیفه: شناسایی کدهای بلا‌استفاده (dead code) در برنامه‌های Go
* ویژگی‌ها:

* استفاده از تحلیل Rapid Type Analysis (RTA) برای ساخت call graph از تابع‌های reachable از main
* شناسایی توابع و متدهایی که در جریان اجرا هرگز فراخوانی نمی‌شوند، حتی در ورودی‌های تست
* گزینه‌های -test, -filter, -generated برای کنترل نوع تحلیل و محدودسازی نتایج
* نصب از طریق go install ...@latest ([Google Groups][3], [Go][4], [Go Packages][5])

---

4. fieldalignment

* وظیفه: آنالیز alignment فیلدهای struct
* ویژگی‌ها:

* بررسی شکل ساختار struct برای بهبود چینش فیلدها و کاهش حافظه مصرف‌شده
* موجود در پکیج go/analysis و قابل اجرا به‌صورت standalone یا در قالب Pass در تحلیل‌های سفارشی
* نصب با go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest

---

5. Protolint

* وظیفه: lint (و در برخی موارد fix) فایل‌های .proto مطابق با استاندارد Google Protobuf
* ویژگی‌ها:

* اجرا بدون نیاز به compiler اصلی (protoc) و سبک اجرا
* تولید گزارش برای قوانین style مانند نام‌گذاری، indentation، order imports، documentation، comment برای RPC و پیام‌ها
* توانایی غیرفعال‌سازی قوانین در سطح فایل، استفاده از پلاگین برای قوانین سفارشی، و خروجی‌های متنوع (json, junit, sarif)


✅ کدومش برای پروژه شما کاربردیه؟

* CI پروژه با workflows عالیه → Actionlint
* ساختن Docker image استاندارد/امن → Hadolint
* حذف کدهای غیرضروری پس refactor → deadcode
* بهینه‌سازی حافظه باینری در structها → fieldalignment
* بررسی فایل‌های protobuf و استانداردسازی API → Protolint

📊 مقایسه سریع با bytes.Buffer

🔐 مفهوم Mutex در Go

اsync.Mutex یک اصل اساسی برای کنترل دسترسی امن به منابع مشترک بین goroutineها است. این نوع قفل تضمین می‌کند که در هر لحظه تنها یک goroutine به بخش حیاتی از کد (critical section) دسترسی دارد

---

🧠 وضعیت‌های مختلف Mutex

می‌توان عملکرد آن را با وضعیت‌های زیر توضیح داد:
ا
ا* Unlocked (حالت اولیه): Mutex آزاد است و هر goroutine می‌تواند با فراخوانی Lock() آن را بگیرد.
ا* Locked: وقتی یک goroutine Lock() می‌زند، دیگران باید منتظر بمانند.
ا* Waiting: در صورت تلاش هم‌زمان چند goroutine برای گرفتن قفل، بقیه به صف انتظار اضافه می‌شوند.
ا* Starvation Mode: اگر یک goroutine بیش از \~۱ms نتواند قفل را بگیرد، سیستم وارد حالت گرسنگی (fair mode) شده و به ترتیب به goroutineهای قدیمی‌تر اجازه دسترسی می‌دهد ([CSDN Blog][3], [Zhihu Zhiwan][4]).

---

⚙️ عملکرد درونی Mutex

* از عملیات غیرقابل قطع (CAS) برای کنترل فیلد state استفاده می‌شود.
* در شرایط کم‌رقابت ابتدا به‌صورت spinning تلاش می‌کند تا حد ممکن بدون خوابیدن lock را بگیرد.
* در سطوح بالای رقابت، goroutineها به صف انتظار اضافه می‌شوند و بیدار می‌شوند وقتی قفل آزاد شد.
* حالت starvation زمانی فعال می‌شود که یک goroutine مدت طولانی در انتظار است تا از حالت FIFO استفاده شود

---

✅ نکات کاربردی و بهترین شیوه‌ها

1. هیچ گاه Mutex را کپی نکنید؛ حتی تصادفاً**—مستقیماً باید از pointers استفاده شود
2. هیچ‌گاه موضعی در struct آن را جاسازی (embed) نکنید، چون باعث در دسترس‌پذیری ناخواسته متدهای Lock/Unlock می‌شود
3. از defer m.Unlock() برای اطمینان از آزادسازی قفل حتی در صورت panic یا return زودهنگام استفاده کنید
4. بخش قفل‌شده باید حداقل زمان ممکن طول بکشد؛ انجام عملیات بلندمدت در آن ممکن است باعث کاهش concurrency و تأخیر جدی شود.

---

⚠️ مشکلات رایج و اشتباهات متداول

* **کپی ناخواسته Mutex: حذف ایمنی synchronization و موجب رفتار نامشخص.
ا* embedding Mutex: باعث انتشار متدهای داخلی قفل به بیرون struct می‌شود — روش اشتباهی است
ا* Double Unlock یا Unlock بدون Lock قبلی → panic.
* عدم رعایت defer → ممکن است در صورت خطا یا exit، قفل آزاد نشود و deadlock رخ دهد.
ا* Deadlock ناشی از تداخل دو یا چند goroutine با mutexهای متفاوت و انتظار متقابل بر مبنای نظم اشتباهی بین Lock()ها.

مقاله‌ی «Top 6 Golang Logging Best Practices» در HackerNoon توسط Lane Wagner در سال ۲۰۲۲ منتشر شده و به بررسی نکاتی اساسی ولی کاربردی درباره‌ی لاگ‌نویسی در زبان Go پرداخته است. در ادامه، خلاصه‌ای مختصر

---

## نکات کلیدی مقاله

1. استفاده از `error` بجای رشته‌ها (strings)
از نوع استاندارد error برای نشان دادن خطاها استفاده کن تا از رفتارهای نادرست مانند نادیده‌گرفتن خطا یا پراکندگی سازوکار خطا جلوگیری شود.

2. Wrap کردن خطاها
بجای لاگ فقط پیام خطا، آن را wrap کن تا محل دقیق رخداد خطا (stack trace یا خط کد) حفظ شود و دیباگ آسان‌تر شود.

3. استفاده از `fmt.Errorf()` برای قالب‌بندی
fmt.Errorf() با قابلیت %w به تو اجازه می‌دهد خطاها را قالب‌بندی و wrap کنی:

   return fmt.Errorf("failed to open file: %w", err)
   

4. قالب‌دهی structها (Format Structs)
وقتی structها در لاگ‌ها استفاده می‌شن، آن‌ها را قالب‌مند کن تا خواناتر و مفیدتر باشند؛ مثلاً با فرمت:

   fmt.Printf("%+v", myStruct)
   

5. استفاده از نسخه variadic توابع مانند `fmt.Println()`
ورژن variadic بهت اجازه می‌دهد مولفه‌های مختلف را بدون تلاش برای concatenation دستی به هم بچسبونی. خوانا و منعطف‌تره.

6. استفاده از بسته‌ی استاندارد `log`
برای شروع خوبه، خصوصاً برای پروژه‌های ساده یا کوچک. log پایدار و سبک هست و کافی برای کاربردهای ابتدایی است.

---

جمع‌بندی سریع

اینها اصولی هستند که در بسیاری از آموزش‌ها و بحث‌های Go توصیه می‌شن: استفاده از سیستم خطای داخلی، پیروی از استانداردها در wrap خطا، قالب‌دهی مناسب، و استفاده از امکانات داخلی زبان قبل از رفتن به راه‌حل‌های پیچیده‌تر.

---

توصیه‌های عملی

* لاگ‌نویسی رو با استفاده از خطاهای داخلی Go شروع کن.
* ورودی‌ها رو wrap کن؛ structها رو مرتب قالب بده.
* برای لاگ‌های پیشرفته‌تر، از structured logging استفاده کن (مثل Zap یا Zerolog).
* همیشه context مهم رو مثل request ID در لاگ‌ها نگه‌دار.
* حجم لاگ رو کنترل کن: نه خیلی زیاد باشه که کارایی رو پایین بیاره، نه خیلی کم که مفید نباشه.

📌 چرا به جای sync.Mutex از sync/atomic استفاده کنیم؟

سریع‌تره چون نیازی به قفل کردن نداره.

اما فقط برای عملیات ساده مثل افزایش/خواندن مقدار مناسبه.

برای عملیات پیچیده‌تر، هنوز باید از sync.Mutex یا sync.RWMutex استفاده کنی.

یکی از فوق العاده ترین ابزارهای مدیریت کلاستر kubernetes که هرروز باهاش کار میکنم و واقعا لذت میبرم k9s هست:
https://github.com/derailed/k9s

<Mohsen Khodabakhshi/>

اگه یه چیزی مثل curl برای gRPC میخواین میتونین از این استفاده کنین:
https://github.com/fullstorydev/grpcurl
<بلک استیت />

💐امکانات جدید در GoLand 2025.2

۱. تحلیل جریان داده برای جلوگیری از nil dereference

اGoLand اکنون از تحلیل بین‌تابعی (interprocedural) استفاده می‌کند تا جریان‌ داده‌های nil را در حلقه‌های فراخوانی تابع، فایل‌ها و بسته‌ها دنبال کند. در نتیجه، هشدارهایی برای استفاده‌های ناایمن از اشاره‌گرها (dereference) به شکل مستقیم در ادیتور نمایش داده می‌شود. علاوه بر این، تب جدیدی به نام Data Flow Analysis در پنجره Problems اضافه شده که مسیر دقیق جریان nil را نشان می‌دهد.


۲. صفحه خوش‌آمدگویی غیرمسدودکننده (Non‑blocking Welcome screen)

صفحه خوش‌آمدگویی (Welcome Screen) حالا به صورت تب (tab) در IDE باز می‌شود، بدون آنکه اجرای محیط توسعه را متوقف کند. این امکان را دارید که بدون باز کردن پروژه به ترمینال، ابزار HTTP، Docker، Kubernetes یا پایگاه‌داده دسترسی داشته باشید و حتی فایل‌های مستقل را ویرایش کنید.


۳. کشف هوشمندانه‌تر endpoint‌ها و تولید درخواست (Request) خودکار

ابزار Endpoints بهبود یافته تا الگوهای مدرن ServeMux را بهتر بشناسد؛ از جمله مسیرهای wildcard یا آن‌هایی که با HTTP method همراه هستند، مانند GET /task/{id}/.
علاوه بر این، متد HTTP در کنار هر endpoint نمایش داده شده، autocomplete برای ساخت آسان‌تر request فعال شده و پشتیبانی از فریم‌ورک‌هایی مانند Chi, Gin, Gorilla نیز بهبود یافته است.


۴. اJunie؛ عامل هوشمند داخل IDE

عامل هوشمند Junie حالا سریع‌تر شده (حدود ۳۰٪ افزایش سرعت)، از پروتکل MCP (Model Context Protocol) پشتیبانی می‌کند و امکان کار در محیط Remote Development را فراهم می‌آورد—همه این‌ها در دل IDE برای تسهیل کارهای حرفه‌ای‌تر.


۵. ارتقا در پشتیبانی از golangci-lint نسخه ۲

ادغام با golangci-lint بهبود یافته، به طوری که نسخه‌ی جدید آن (v2) در تحلیل بلادرنگ (real-time) بهتر و مطمئن‌تر عملکرد دارد.
---
خلاصه کاربردی

ویژگی جدید کاربرد

تحلیل ‌Nil با DFA جلوگیری از خطاهای اشاره‌گری قبل از runtime
صفحه خوش‌آمدگویی غیرمسدودکننده دسترسی سریع‌تر به ابزارها بدون باز کردن پروژه
کشف و Request خودکار endpoint‌ها تسهیل تعامل با HTTP در توسعه وب
اJunie با MCP و پشتیبانی Remote افزایش سرعت و قابلیت هوشمند برای توسعه حرفه‌ای
ارتقاء golangci‑lint integration تحلیل کد دقیق‌تر و قابل‌اعتمادتر در زمان توسعه

---

در مجموع، نسخه 2025.2 تمرکزش را روی بهبود تجربه توسعه‌دهنده معطوف کرده—از تشخیص هوشمند خطا تا دسترسی سریع به ابزارها و هوشمندسازی کمک‌ها در IDE.

«به جای اینکه توی benchmark از for i := 0; i < b.N; i++ { ... } استفاده کنی، می‌تونی از متد جدیدتر b.Loop() استفاده کنی.»

توضیح

در تست‌های بنچمارک گولنگ (یعنی تابع‌هایی که با func BenchmarkXxx(b *testing.B) نوشته می‌شن)، معمولاً برای اجرای کد به تعداد کافی و گرفتن میانگین زمان اجرا، از این الگو استفاده میشه:

for i := 0; i < b.N; i++ {
    // کدی که باید بنچمارک بشه
}

ولی از نسخه‌های جدیدتر Go، متد [`b.Loop()`](https://pkg.go.dev/testing#B.Loop) اضافه شده که همین کار رو به شکل مدرن و کمی بهینه‌تر انجام میده و خوانایی رو هم بهتر می‌کنه:

b.Loop(func() {
    // کدی که باید بنچمارک بشه
})

فرق اصلی

* کد کوتاه‌تر و خواناتر
* جلوگیری از اشتباهات احتمالی در حلقه شمارشی
* خود Go در آینده ممکنه بهینه‌سازی‌های بیشتری روی b.Loop انجام بده

مثال تبدیل

قدیم:

func BenchmarkSomething(b *testing.B) {
    for i := 0; i < b.N; i++ {
        doWork()
    }
}

جدید:

func BenchmarkSomething(b *testing.B) {
    b.Loop(func() {
        doWork()
    })
}

پس پیغام `b.N can be modernized using b.Loop()` یعنی «لطفاً حلقه for رو به b.Loop تغییر بده».

دیدگاه جامعه درباره استفاده از Enum در Go

اهمیت خاص گذاشتن روی مقدار Invalid در صفر:

“New go devs from Java tend to forget that the enum doesn’t default to null… defining 0 as unknown saves a lot of confusing bugs!”

هشدار نسبت به وابستگی زیاد به iota وقتی این مقادیر در دیتابیس ذخیره می‌شن:

“Reordering/removing cases also doesn't cause any big problem… unless you are using the number representation of enums in the database.”

برخی هم در بحث‌های Reddit اشاره کرده‌اند که enumهای واقعی مثل Rust’s sum types در Go وجود ندارند و هرچقدر هم شبیه‌سازی شوند، محدودیت‌هایی دارند.

تاج‌گذاری OpenAi در میدان شطرنج هوش مصنوعی ؛ ChatGPT گراک رو به زمین زد!

▪️در اولین دوره مسابقات شطرنج هوش‌ مصنوعی در Kaggle Game Arena، مدل o3 از OpenAI با یک نمای قاطع 4 بر 0 مقابل Grok 4 (xAI) پیروز شد.

▪️مدل o3 با دقت 90.8% و بازی‌های حساب‌شده، حریف رو به اشتباهات سخت کشوند؛ در حالی که Grok 4 با دقت 80.2% نتونست جلوی سقوط مهره‌ها رو بگیره.

▪️رده‌بندی نهایی :

🥇 OpenAI - o3 (قهرمان)
🥈 xAI - Grok 4 (نایب‌قهرمان)
🥉 Gemini 2.5 Pro (مقام سوم)

🆗 چیستی SBOM و اهمیتش؟

ا* SBOM یا Software Bill of Materials، لیستی ساختاریافته از تمام اجزای تشکیل‌دهنده نرم‌افزار مثل پکیج‌ها، ماژول‌ها و کتابخانه‌هاست. این لیست کمک می‌کنه تیم‌ها بر زنجیره تأمین نرم‌افزاری، وابستگی‌ها و ریسک‌های امنیتی تسلط بهتری داشته باشن
* در پروژه‌های Go، فایل go.mod فقط وابستگی‌های مستقیم رو فهرست می‌کنه، اما SBOM برای پوشش‌دهی وابستگی‌های غیرمستقیم (transitive) و تولید خروجی در قالب‌های استاندارد بسیار کاربردی‌تره

---

مزایای SBOM

| مزیت | توضیح |
| --------------- | ------------------------------------------------------ |
| امنیت | شناسایی سریع آسیب‌پذیری‌های وابستگی‌ها |
| تطابق با مجوزها | بررسی مجوزهای وابستگی‌ها قبل از انتشار |
| استانداردسازی | استفاده از فرمت‌های مشترک و قابل تحلیل |
| الزامات قانونی | کاربرد در پروژه‌هایی با نیازهای compliance مثل FedRAMP |


---

نحوه‌ی تولید SBOM در پروژه‌های Go

1. نصب ابزار CycloneDX برای Go:

   go install github.com/CycloneDX/cyclonedx-go@latest
   

2. تولید SBOM با فرمت JSON:

   cyclonedx-go mod -json -output sbom.json
   

3. تحلیل SBOM با ابزارهایی مثل Grype:

   grype sbom.json
   

4. بررسی تطابق مجوزها:

   cyclonedx-go mod -licenses -json -output licenses.json
   

* برای پروژه‌هایی که از Go Workspace استفاده می‌کنن، باید به‌طور موقت آن را غیرفعال کرد (مثلاً با GO111MODULE=off) تا ابزار بتواند SBOM را به درستی تولید کند

---

جمع‌بندی کوتاه

*ا SBOM یک نقشهٔ دقیق از تمام اجزای نرم‌افزار شماست—وقت نگرانی دربارهٔ نسخه‌ها، آسیب‌پذیری‌ها یا مجوزهای حقوقی شون داشته باشی.
* ابزار CycloneDX for Go ساده‌ترین راه برای تولید SBOM در پروژه‌های Go است.
* پس از تولید، ابزارهایی مثل Grype و CycloneDX خود ابزار خوبی برای تحلیل و بررسی و آسیب‌پذیری یا مجوزها فراهم می‌کنن.

یه محیط خفن گرافیکی جذاب برای یادگیری الگوهای Concurrency

Go Concurrency Explorer

https://www.concurrency.rocks

لینوس توروالدز: کد مهندس گوگل «آشغال محض» بود!

▪️همه فکر می‌کنن مهندسای گوگل در قله کیفیت هستن، اما خالق لینوکس یه شوک اساسی داد! لینوس توروالدز بدون هیچ تعارف، کد یکی از برنامه‌نویسای گوگل رو «به درد نخور» خطاب کرد و اون رو با خاک یکسان کرد.

▪️ماجرا از یه Pull Request مربوط به پشتیبانی RISC-V در لینوکس 6.17 شروع شد. پالمر دابلت از تیم اندروید، تغییرات رو فرستاد، ولی:

1. کیفیت کدنویسی افتضاح!

2. ارسال دیرهنگام در «پنجره ادغام»!

🎯 آمادگی کامل IELTS با تدریس خصوصی و آنلاین

👑به دنبال نمره بالا در آیلتس هستی؟

🟢با استاد Mansourian، مدرس با تجربه مهارت‌های
🩵Speaking
🩵Writing
🩵Reading
🩵Listening

رو به بهترین شکل تقویت کن.

📌 کلاس‌ها به صورت آنلاین، خصوصی و روزانه برگزار میشه.

📈 پیشرفت سریع + برنامه‌ریزی دقیق برای رسیدن به هدفت.

💬 همین الان فالو کن و مسیر موفقیتت رو شروع کن!

👇پیج استاد توی انستاگرام 👇

https://www.instagram.com/english_razi_ielts

در ادامه، یک خلاصه کاربردی و به‌روز از مقاله Matthias Endler با عنوان «How To Review Code» (منتشرشده در ۶ آگوست ۲۰۲۵) آورده شده است

نکات کلیدی برای بررسی کد با رویکرد حرفه‌ای

۱. به چشم‌انداز کلی فکر کن
بررسی کد نباید فقط به خط‌های تغییر یافته محدود شود. بهتر است به این سوال‌ها پاسخ بدهیم:
کد جدید چگونه با سیستم فعلی تعامل دارد؟
تست‌ها، مستندات و دیتا تایپ‌ها به‌روز شده‌اند؟
آیا معماری کلی را تضعیف نمی‌کند؟

۲. نام‌گذاری اهمیت زیادی دارد
نام‌گذاری بد نه‌تنها کد را سخت‌فهم می‌کند، بلکه می‌تواند نشانه‌ای از مشکلات ساختاری بزرگ باشد. انتخاب نام‌هایی واضح، با مفهوم و هماهنگ با دامنه کاربرد حیاتی است.
مثال ارائه‌شده روی یک نسخه نامناسب از تابع update_player_stats تأکید دارد.

۳. اگر ممکن است، کد را اجرا کن
داشتن نسخه محلی برای اجرای کد، تست‌ها و linters خیلی کمک می‌کند. جابه‌جایی و آزمودن کد به فهم بهتر منطق کمک می‌کند (مخصوصاً برای تغییرات UI یا پیام‌های خطا).

۴. درباره دسترس‌پذیری خود صادق باش
بررسی کد ممکن است زمان‌بر باشد. اگر فرصت انجامش را نداری، صادق باش و به نویسنده اطلاع بده — تا فرایند توسعه متوقف نشود.

۵. هیچ‌وقت دست از یادگیری بر ندار
هر بررسی کد فرصتی برای یادگیری الگوها، کتابخانه‌ها یا رویکردهایی است که شاید نمی‌دانستی. هدف فقط اصلاح نیست، رشد تیمی نیز هست.

۶. حسّی رفتار نکن — فقط نقدهای اصل‌محور
اformat و whitespace را به ابزارهای قالب‌زن (formatter) بسپار. انرژی خود را برای بررسی منطق، طراحی و نگهداری‌پذیری صرف کن. اگر تغییری کاربردی ندارد یا باعث سردرگمی نخواهد شد، نادیده‌اش بگیر.

۷. روی چرا تمرکز کن، نه چگونه
بهتر است سؤال‌های راه‌گشا درباره دلیل انتخاب یک راه حل مطرح شود، تا صرفاً گفتن "اشتباه است". این رویکرد ماندگارتر و آموزنده‌تر است.

۸. پرسیدن سؤال‌های ساده هیچ اشکالی ندارد
اگر چیزی را نمی‌فهمی، حتماً سؤال بپرس. ممکن است شخص دیگری هم همان‌طور فکر کند. این کمک می‌کند نویسنده ببینند بخش‌هایی از کد بی‌دلیل گیج‌کننده‌اند.

۹. به بررسی سبک خودت هم گوش بده
بپرس: "آیا نقدم خیلی سختگیرانه بود؟ مفید بود؟ باعث پیشرفت شد؟"

احتمالاً خودت هم در حال یادگیری هستی و تکامل در روند بررسی خیلی ارزشمند است.

جمع‌بندی: بررسی کد حرفه‌ای یعنی چه؟

علاوه بر خط‌های تغییر، به تأثیر تغییر در کل سیستم توجه کن.

نام‌گذاری صحیح، درک جریان و معماری را ساده‌تر می‌کند.

وقتی می‌شود کد را اجرا کرد، حتماً امتحانش کن.

اگر وقت نداری یا چیزی را نفهمیدی، صادق باش و سؤال بپرس.

مهم‌تر از اصلاح، کمک به رشد است.

پایان استقلال گیت‌هاب؛ مایکروسافت همه‌چیز را می‌بلعد!

▪️گیت‌هاب، بزرگ‌ترین مخزن کد جهان و خانه میلیون‌ها توسعه‌دهنده، بعد از استعفای مدیرعاملش دیگه مستقل نیست! مایکروسافت رسماً این پلتفرم محبوب رو قورت داد و انداختش وسط تیم Core AI خودش.

▪️«توماس دومکه» مدیرعامل گیت‌هاب گفت تا آخر امسال میره دنبال استارتاپ جدیدش، اما درست بعد از اعلام رفتنش، خبر اومد که گیت‌هاب از این به بعد بخشی از پروژه‌های AI مایکروسافته؛ یعنی همه راه‌ها مستقیم میره سمت GitHub Copilot...

+ اما برنامه‌نویس ها نگرانن همون بلایی که سر اسکایپ اومد سر گیت‌هاب هم بیاد!