نکته‌ای که تجربه‌اش رو توی سیستم‌های high-scale دیدم، اینه که بسیاری از این تصمیمات فقط یکبار نیستن — بلکه evolutionary هستن.
مثلاً شروع با monolith منطقی‌ترین انتخاب برای یک سیستم جدید با domain uncertainty بالا هست، اما همون معماری با رشد traffic و team size ممکنه به bottleneck تبدیل بشه. در اون مرحله migration به microservices دیگه یک انتخاب نیست، بلکه یک forced trade-off بین developer productivity، operational complexity و scalability هست.
یا مثلاً انتخاب database: با 10K QPS شاید PostgreSQL با read replica کافی باشه، ولی با 100K+ QPS باید راجع به sharding، caching layer و eventual consistency فکر کنی. همین decision دوباره وابسته میشه به اینکه consistency requirements چقدر سخت‌گیرانه‌ان.
به نظرم شاید یه اصل مهم دیگه هم مثل "it depends" اینه که بدونیم چه موقع باید یک تصمیم رو revisit کنیم. این یعنی داشتن observability و metrics که نشون بدن کِی architectural constraints ما به actual bottleneck تبدیل شدن.


در تایید این پست خوب دوست عزیزم محمد نصر
https://www.linkedin.com/posts/mohammadne_%D8%AF%D8%B1-%D8%B3%D8%A7%D9%84%D9%87%D8%A7%DB%8C%DB%8C-%DA%A9%D9%87-%D8%B1%D9%88%DB%8C-software-architecture-activity-7396796883618217985-GquG?utm_source=share&utm_medium=member_desktop&rcm=ACoAABKaeq4BumiQ-WRCbtW6ppzE1JdD1EBnCUQ


پی نوشت: عذرخواهی میکنم واقعا سخته فارسی کنی کلمات رو و همون معنی رو بده. من خودم انگلیسی م چندان تعریفی نداره و خدای نکرده برداشت بدی نشه. ولی واقعا سخته بعضی جاها. نگم سخته بهتره بگم سریعتره که اینطوری نوشته بشه 🙂. بازم معذرت


@gocasts

وقتی یک خط کد، نیمی از اینترنت را از کار انداخت

گزارش مفصل فنی GoCasts رو از مشکلی که برای cloudflare پیش اومد بخونید
سعی شده علاوه بر شرح جزییات نکات فنی و مهندسی‌ای ذکر بشه که میتونیم رعایت کنیم که از مشکلات مشابه برای خودمون و در سطح خودمون جلوگیری کنیم.
https://gocasts.ir/cloudflare-outage-analysis/

امیدورام خوشتون بیاد 🌺

@gocasts

این claude فلان فلان شده زد همه فایل های روی سرور سایتمو حذف کرد
خیلی رو دادم بهش..
بهش گفتم دیپلوی کن اول پاک کرد بعد دیپلوی کرد
در کل هیچ عیب و ایرادی سمت claude نیست مقصر منم که توجیه ش نکردم 🙂
اینو شوخی نکردم. جدی میگم. رابطه ت با agentها مثل نیروهای کاری باید باشه که soft-skillی ضعیفه و باید کم کم کمکش کنی


@gocasts

در مورد مهندس بهراد قبلا گفتنی هارو گفتم، اینجا میتونید بخونید
https://news.1rj.ru/str/gocasts/675

بهراد جان دوره های طراحی سیستم و هنر کدنویسی رو مجدد داره برگزار میکنه، به مناسبت بلک فرایدی هم تخفیف ویژه گذاشته که میتونید تا امشب استفاده کنید، حتما این فرصت خوب برای تقویت مهارت هاتونو جدی بگیرید

لینک توضیحات
https://www.linkedin.com/posts/behradz_%D8%A8%D8%AE%D8%A7%D8%B7%D8%B1-%D9%87%D9%85%D8%B2%D9%85%D8%A7%D9%86-%D8%B4%D8%AF%D9%86-%D8%B4%D8%B1%D9%88%D8%B9-%D8%AF%D9%88%D8%B1%D9%87-%D9%BE%D8%A7%DB%8C%DB%8C%D8%B2-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D8%AF%DB%8C%D8%B2%D8%A7%DB%8C%D9%86-activity-7399034712289325056-oAVa?utm_source=share&utm_medium=member_ios&rcm=ACoAAAbohWoBPeqOSQmQHfzveYWZgwWhxKAzGi4

@gocasts

زبان Zig: زبانی که آروم داره جای خودش رو پیدا می‌کنه

این روزها هرجا نگاه می‌کنم، یه پروژه performance-critical جدید می‌بینم که با Zig نوشته شده. Bun - همون JavaScript runtimeی که هفته پیش Anthropic خریدش با Zig نوشته شده. Lightpanda - یه headless browser که ادعا می‌کنه ۱۰ برابر Chrome سریع‌تره با Zig نوشته شده. TigerBeetle - یه دیتابیس مالی که قراره جایگزین سیستم‌های بانکی بشه - با Zig نوشته شده.

مقاله Lightpanda یه تیتر خیلی صادقانه‌ داره: «چون به اندازه کافی باهوش نیستیم که با C++ یا Rust بنویسیم.»

زبان Zig رو Andrew Kelley از سال ۲۰۱۵ شروع کرد چون داشت روی یه پروژه real-time audio کار می‌کرد و از C کلافه شده بود. فلسفه طراحی‌ش ساده‌ست: هیچ چیز مخفی نباشه. هیچ hidden allocation نداری، هیچ operator overloadingی نداری، هیچ exceptionی نداری. وقتی کد رو می‌خونی، دقیقاً می‌فهمی چی اجرا میشه. یه فیچر خیلی قوی داره به اسم comptime که باهاش می‌تونی موقع کامپایل کد اجرا کنی - مثل macroهای C ولی با همون سینتکس Zig. همچنین می‌تونی مستقیم headerهای C رو import کنی و با کدبیس‌های قدیمی کار کنی.

حالا سوال اصلی: چرا Zig و نه Rust؟ جواب کوتاه: Zig ساده‌تره ولی unsafe تره. Rust با borrow checker تضمین می‌کنه memory safe هستی، ولی learning curve سنگینی داره. Zig این تضمین رو نمیده - بجاش یه سری runtime check داره که توی debug mode کمکت می‌کنه. Jarred Sumner (سازنده Bun) گفته اول می‌خواست با Rust بنویسه ولی نتونست productive باشه. تیم TigerBeetle هم گفته برنامه‌نویس‌های خوب از هر زبانی می‌تونن Zig رو توی یه آخر هفته یاد بگیرن.

زبان Zig هنوز به نسخه ۱.۰ نرسیده و اکوسیستم بالغی نداره. برای پروداکشن معمولی توصیه نمیشه. ولی برای systems programming - جایی که می‌خوای به سخت‌افزار نزدیک باشی، performance حیاتیه، و با زبان C باید interpolation داشته باشی - داره به یه گزینه جدی تبدیل میشه. وقتی Anthropic میاد Bun رو می‌خره و میگه می‌خوایم زیرساخت Claude Code رو باهاش بسازیم، یعنی این زبان دیگه فقط یه اسباب‌بازی نیست.

Why We Built Lightpanda in Zig
Because We're Not Smart Enough for C++ or Rust
https://lightpanda.io/blog/posts/why-we-built-lightpanda-in-zig

Anthropic acquires Bun as Claude Code reaches $1B milestone
https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone


@gocasts

«مادر»

حرف زیاده، ولی سکوت شایسته‌تره..

بهینه سازی گولنگ برای سیستم های پردازشی با حجم بالای داده

این مقاله نکات جالبی نوشته برای وقتی که یه سرویس گولنگی داری که باید real-time از دیتابیس Postgres بخونه و به Elasticsearch بنویسه. البته نکاتی که گفته کاربردشون محدود به این ابزارها نمیشه و در سناریوهای مشابه هم میشه استفاده شون کرد.

طبق تجربه در این مسیر احتمالا سه تا چالش اصلی داری: دیسک دیتابیس که پر میشه اگه کند بخونی، حافظه که منفجر میشه اگه زیاد buffer کنی، و GC که CPU رو می‌بلعه اگه زیاد allocate کنی.

یکی از اولین جاهایی که باید بهینه کنی، JSON serialization هست. کتابخانه استاندارد encoding/json امن و راحته، ولی برای حجم بالا کند میشه. جایگزین‌هایی مثل jsoniter با کاهش reflection overhead می‌تونن توان عملیاتی رو به شکل محسوسی بالا ببرن. البته جایگزین کردنش چالش هایی هم داره و باید edge case ها رو تست کنی.

قدم بعدی sync.Pool هست. هر event که از replication slot میاد، struct میسازی، buffer برای JSON میگیری، slice و map میسازی. زیر لود بالا، این آبشار allocationها GC رو دیوونه میکنه. با pool کردن bufferها و structهای پرتکرار، تعداد allocationها رو به شدت کم میکنی و GC pause time میاد پایین.

همچنین GC tuning باید آخرین کار باشه، نه اولین. اول allocationها رو کم کن، بعد serialization رو بهینه کن، بعد اگه هنوز spike داشتی برو سراغ تنظیمات GC. از Go 1.25 هم یه GC آزمایشی جدید اومده که برای سرویس‌های throughput-heavy مناسبه.

https://open.substack.com/pub/packagemain/p/golang-optimizations-for-highvolume


@gocasts

بعد از تقریبا پنج سال زمان جدایی از اسنپ فرا رسید...

همیشه میخواستم با حس و حال خوب از اسنپ جدا بشم و الحمدلله فکر میکنم این اتفاق رخ داده.

آدمای زیادی هستن که باید ازشون تشکر کنم، هر کسی یه روزی در اسنپ بوده بدونه من وامدارشم و مدیونشم، چون مستقیم یا غیرمستقیم احتمالا یه چیزی ازش یاد گرفتم، از نبوغ ش، از نوآوری و خلاقیت ش و حتی از اشتباهات ش، چون خود من سر تا پا اشتباهم...

به ویژه از همکاران عزیزم در تیم های NBO و Pricing و Dispatching تشکر می‌کنم. اگه امکانش بود دوست داشتم تک تک بچه هارو منشن کنم اما خب خیلی کار سختیه این همه همکار گرامی رو بخوام منشن کنم. فقط بدونن که ارادتمند تک تک شون هستم ❤️.

قطعا اسنپ با اختلاف بهترین تجربه کاری من در دهه گذشته بوده و از یک سری ابعاد٬ چالش و تجربیات‌ش قابل مقایسه با جاهای دیگه نیست. و قطعا بیش از آنکه من چیزی ارائه کرده باشم برای اسنپ٬ اسنپ برای من کلی آورده فنی و غیرفنی داشته.

انسان یک بار بیشتر فرصت زندگی کردن نداره و مسیرهایی که دوست داره طی کنه خیلی زیادن. پس به ناچار در دوراهی های زیادی قرار میگیری و از بین اونا فقط یکی رو میتونی انتخاب کنی. ان شاءالله که خیره...

Snapp!
بازم از همه تشکر می‌کنم. دم همه تون گرم، مثل همیشه خوش بدرخشید 💚💚


@gocasts

واقعاً لذت بردم از نحوه نوشتن این مقاله. نویسنده یه موضوع نسبتاً پیچیده رو با انیمیشن و visualization های تعاملی طوری توضیح داده که قدم به قدم باهاش جلو میری. از اون مقاله‌هاییه که آدم دلش میخواد کاش همه مطالب فنی اینجوری نوشته میشدن.

موضوعش prompt caching توی LLM هاست. اگه با API های Claude یا OpenAI کار کرده باشید، دیدید که cached tokens حدود ۱۰ برابر ارزون‌ترن. ولی سوال اینه: دقیقاً چی داره cache میشه؟ جواب این سوال کمک میکنه بهتر بفهمیم LLM ها از درون چطور کار میکنن.

خلاصه‌اش اینه که توی مکانیزم Attention، هر token باید با همه tokenهای قبلی مقایسه بشه تا مدل بفهمه به کدوم‌ها توجه کنه. این مقایسه با ماتریس‌های Q و K انجام میشه و نتیجه نهایی با V ترکیب میشه. نکته کلیدی اینه که K و V مربوط به tokenهای قبلی هیچوقت عوض نمیشن.

پروایدرها (مثل OpenAI و Anthropic) این K و V رو برای ۵ تا ۱۰ دقیقه نگه میدارن. اگه request بعدی با همون prefix شروع بشه، دیگه لازم نیست از اول محاسبه بشه.

نتیجه‌ش هم میشه تا ۱۰ برابر کاهش هزینه و تا ۸۵ درصد کاهش latency.

یه نکته جالب هم داره: OpenAI اتوماتیک cache میکنه با حدود ۵۰ درصد hit rate، ولی Anthropic کنترل رو دست شما میده و ۱۰۰ درصد hit میخوره. برای سیستم‌هایی که latency قابل پیش‌بینی میخوان، این تفاوت مهمه.

اینم لینک مقاله
https://ngrok.com/blog/prompt-caching


@gocasts

استفاده از Rust در کرنل لینوکس: یه انقلاب بعد از ۳۰ سال!

یکی از پادکست‌های جذابی که اخیرا منتشر شده، مصاحبه با Danilo Krummrich بود، maintainer کرنل لینوکس و عضو تیم اصلی Rust for Linux.

این یه تغییر تاریخیه چون برای اولین بار بعد از بیش از ۳۰ سال یه زبان جدید رسماً وارد توسعه کرنل میشه!

دنیلو توسعه‌دهنده اصلی و maintainer درایور Nova هست، یه درایور GPU کاملا مبتنی بر Rust برای کارت‌های گرافیک انویدیا. این درایور برای GPU های GSP-firmware-based (از RTX 2000 / Turing به بعد) طراحی شده و قراره برای این نسل‌ها جایگزین Nouveau بشه.

شاید از دلایل اصلی حضور Rust در کرنل لینوکس Memory Safety و Concurrency Safety باشه.

طبق گزارش مایکروسافت، حدود ۷۰٪ از CVE های Windows مربوط به memory safety هست. گوگل هم آمار مشابهی برای Android گزارش کرده.

توی کرنل که یه خطای کوچیک می‌تونه کل سیستم رو از کار بندازه، جلوگیری از data race و undefined behavior در compile-time خیلی ارزشمنده.

یه چالش فرهنگی این وسط وجود داره اونم اینه که کرنل لینوکس بیش از ۳۰ ساله با C نوشته شده. maintainerهای قدیمی که سال‌ها با C کار کردن، باید قانع بشن که Rust ارزشش رو داره. این یه تغییر فرهنگی بزرگه که زمان می‌بره.

این پروژه از نظر من خیلی جذابه چون نشون میده Rust دیگه فقط یه زبان Hype شده نیست. وقتی کرنل لینوکس - که قلب تپنده میلیاردها دستگاه از سرورها تا گوشی‌های اندرویدیه - داره Rust رو می‌پذیره، یعنی این زبان واقعاً به بلوغ رسیده. البته Rust ثابت شده بود، ثابت شده تر شد..

البته هنوز سال‌ها طول می‌کشه تا بخش قابل توجهی از کرنل با Rust نوشته بشه. ولی شروع شده و این خودش خبر بزرگیه.

اگه برنامه نویسی سیستمی و low-level کار می‌کنید، یادگیری Rust دیگه انتخابی نیست، احتمالا یه ضرورته!

اینم لینک پادکست
https://corrode.dev/podcast/s05e06-rust4linux/

@gocasts

🍉 شب یلدا، بلندترین شب سال

یه فرصت خوب برای شروع یه مسیر بلند!

دوره + تیمسازی بکند و گولنگ Go Casts
۱۲ میلیون ← ۴.۴۹ میلیون

کد تخفیف: YALDA

لینک خرید
🔗 https://shop.gocasts.ir/product/go

توضیحات تکمیلی سایت
https://gocasts.ir

همه چیز در مورد دوره و تیمسازی در این پست توضیح داده شده
https://news.1rj.ru/str/gocasts/434

تو این پست هم میتونید فیدبک های دوره و تیمسازی و استخدام بچه هارو بخونید
https://news.1rj.ru/str/gocasts/441

دوستانی که در خرید دوره تردید دارند میتونن برای مشاوره کوتاه تلفنی، فرم زیر رو پر کنند که باهاشون تماس بگیرم
https://survey.porsline.ir/s/ATeQL4b4


@gocasts

ارائه Critical Path Analysis: تکنیکی از پروژه منهتن برای دیباگ Latency در Go!

یکی از ارائه های جذاب GopherCon 2025 ارائه Felix Geisendörfer از Datadog بود درباره پروفایلینگ request latency با استفاده از Critical Path Analysis.

این تکنیک جالبه چون اصلاً برای نرم‌افزار طراحی نشده بود. از پروژه منهتن میاد! همون پروژه‌ای که بمب اتمی ساخت. ایده‌ش ساده‌ست: وقتی یه پروژه بزرگ داری با زیرپروژه‌های موازی، کدوم مسیر واقعاً تعیین‌کننده زمان کله؟

حالا Felix این رو آورده روی Go و goroutine ها.

مشکلی که حل می‌کنه اینه که پروفایلینگ سنتی بهت میگه mutex contention داری، ولی نمیگه این چقدر روی latency کاربر تأثیر گذاشته. مثلاً یه پروفایل نشون میده ۴۳۹ ثانیه contention تو ۶۰ ثانیه داشتی. خب این خیلی بده، ولی سوال اصلی اینه: کدوم بخشش واقعاً روی request های کاربر تأثیر گذاشته؟

اینجاست که execution tracer میاد وسط. برخلاف CPU profiling که فقط on-CPU رو نشون میده، execution tracer همه state transition ها رو ثبت می‌کنه: کی goroutine داشت run می‌شد، کی منتظر mutex بود، کی منتظر channel بود، کی scheduling latency داشت. یه تصویر کامل از زندگی goroutine هات.

راه‌حل اینه که از آخر request بری عقب و ببینی کدوم goroutine ها واقعاً سر راه بودن. اگه G1 منتظر G2 و G3 باشه و G3 دیرتر تموم بشه، سریع‌تر کردن G2 هیچ فایده‌ای نداره. این همون critical path هست.

یه کار خفن دیگه که تیم Datadog کرده اینه که overhead اجرای execution tracer رو از ۱۰-۲۰ درصد به ۱-۲ درصد رسوندن. یعنی الان میشه تو production ازش استفاده کرد.

این ارائه خیلی ارزشمنده چون نشون میده پروفایلینگ می‌تونه خیلی دقیق‌تر از چیزی باشه که عادت کردیم. به جای اینکه بگیم mutex contention داریم، بیاید همه جا رو optimize کنیم، می‌تونیم دقیقاً بفهمیم کجا واقعاً مهمه.

آقای Felix امیدواره این کار رو open source کنه.

اگه با Go کار می‌کنید و tail latency براتون مهمه، پیشنهاد می‌کنم این ارائه رو ببینید.

https://www.youtube.com/watch?v=BayZ3k-QkFw

@gocasts

قابلیت Git Worktree: سلاح مخفی کار با Code Agentها

یه مشکل کلاسیک هست که وسط یه فیچری، باید یه branch دیگه رو چک کنی. و روند git stashو switch و کارتو بکن و برگرد و unstash... خسته‌کننده‌ست.

ولی وقتی داری با agentها کار می‌کنی (Cursor، Claude Code و ...)، این مشکل ۱۰ برابر میشه. Agent می‌خواد فایل‌ها رو عوض کنه، build بزنه، شاید خراب‌کاری کنه. نمی‌خوای working directory اصلیت رو بهم بریزه.

راه‌حلش میشه git worktree

مفهومش ساده‌ست. پروژه‌ات دو بخش داره: پوشه .git که دیتابیسته (کامیت‌ها، برنچ‌ها، تاریخچه) و working directory که فایل‌های واقعی هستن. مشکل اینه که فقط یه working directory داری، پس فقط یه branch می‌تونی checkout داشته باشی.

درواقع worktree یه working directory دوم می‌سازه که به همون .git وصله. پوشه جدا، branch جدا، ولی همون history.

فقط ۳ تا دستور لازمه:

git worktree add ../project-agent feature-branch
git worktree list
git worktree remove ../project-agent

چرا برای Agent ها عالیه؟ وقتی ClaudeCode یا ابزارهای مشابه یه agent رو توی worktree mode اجرا می‌کنن، یه worktree جدید می‌سازن، فایل‌هاتو کپی می‌کنن اونجا، agent توی isolation کامل کارشو می‌کنه، و آخر یه دکمه Apply میدن که merge کنی. Agent می‌تونه هر کاری بکنه، working directory اصلیت دست‌نخورده می‌مونه.

یه نکته مهم هم اینه که node_modules و فایل‌های .env منتقل نمیشن چون توی gitignore هستن. هرچی agent ها قوی‌تر میشن، این pattern ضروری‌تر میشه.

این مقاله رو هم میتونید بخونید
https://www.marcohaber.dev/blog/git-worktrees


@gocasts