لازمه که این نکته رو عرض کنم خدمت تون: نگران هیچی نباشید دوستان با قدرت ادامه بدید
مهم این نیست که چی میشه مهم اینه که در لحظه هر چی در توان داریم بذاریم. اینکه آینده چطور پیش میره برای همه نامعلومه. در لحظه وظیفه ماست که قدم هایی که برای ما معلوم و روشنه برداریم
یکی از واضح ترین قدم ها هم در آغوش گرفتن تمام و کمال ai برای بهبود بهره وری کارمون هست

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

کتاب Understanding Distributed Systems
نکاتی که هر developerی در مورد distributed applicationها باید بدونه


چرا همه درباره Distributed Systems حرف می‌زنن؟ 🤔

وقتی اولین بار با سیستم‌های توزیع‌شده آشنا شدم، فکر می‌کردم فقط برای شرکت‌های بزرگ مثل Google و Amazon کاربرد داره. اما حقیقت اینه که امروز تقریباً هر اپلیکیشنی که ازش استفاده می‌کنیم، یه سیستم توزیع‌شده‌س - از Instagram گرفته تا دیجی‌کالا.

سیستم‌های توزیع‌شده چهار مشکل اساسی رو حل می‌کنن:
1️⃣ وقتی ترافیک بیشتر از ظرفیت یه سرور میشه (Scalability)
2️⃣ وقتی نمی‌خوایم با down شدن یه سرور، کل سیستم از کار بیفته (Resiliency)
3️⃣ وقتی کاربرا از سراسر دنیا دارن به سیستم request می‌زنن (Performance)
4️⃣ وقتی می‌خوایم سیستم رو راحت maintain و توسعه بدیم (Maintainability)

اما این قدرت با چالش‌هایی همراهه: نودها باید با هم communicate کنن، باید coordinate بشن، و باید در برابر failure مقاوم باشن. Leslie Lamport یه جمله معروف داره که می‌گه: "سیستم توزیع‌شده جاییه که failure یه کامپیوتری که حتی نمی‌دونستی وجود داره، می‌تونه سیستم تو رو خراب کنه."
اگه دارید روی backend کار می‌کنید یا قراره شروع کنید، درک این مفاهیم دیگه optional نیست - الزامیه. چون دیگه داریم همه چیز رو distributed می‌سازیم.


نکاتی از فصل اول کتاب Understanding Distributed Systems

با تشکر از جناب Roberto Vitillo برای این کتاب درجه یک!


#understanding_distributed_systems
#roberto_vitillo

@gocasts

یکی از زیباترین جنبه های سیستم های توزیع شده fault tolerant شدنشونه از نظر بنده


پارت دوم: Distributed Systems دیگه چه غولی داره؟

در بخش قبل گفتم که چرا Distributed Systems اینقدر مهم شدن. اما یه سوال دیگه هم پیش میاد: پس چه فرقی با سیستم‌های عادی دارن؟
تصور کنید و یک رستوران رو در نظر بگیرید:
- رستوران معمولی (غیرتوزیع‌شده): یک آشپز، یک پیشخدمت، یک صندوقدار. اگه آشپز مریض بشه، کل رستوران تعطیل میشه!
- رستوران توزیع‌شده: چندین آشپز، چندین پیشخدمت، چندین صندوق. اگر یک آشپز زمین بخوره، بقیه کار رو ادامه میدن.

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


سه تا مفهوم کلیدی که باید از همین اول بدونید:

🔄 Communication:
نودها (همون کامپیوترها یا سرویس‌ها) چطور با هم حرف می‌زنن؟ مثل آدم‌ها که تلفن، ایمیل یا حضوری حرف می‌زنن، نودها هم پروتکل‌های مختلفی دارن - از HTTP/REST گرفته تا gRPC و Message Queue ها.

🤝 Coordination:
چطور بین خودشون هماهنگ می‌شن؟ مثلاً چه کسی تصمیم می‌گیره که یک داده رو کدوم نود ذخیره کنه؟ یا چطور مطمئن می‌شن که دو تا کار  با هم انجام ندن که منجر به conflict بشه؟ اینجا هست که چیزایی مثل Consensus Algorithms (مثلاً Raft) به کمکمون می‌آن.

🛡️ Fault Tolerance:
وقتی یک نود می‌میره، سیستم چطور زنده می‌مونه؟ اینجاست که می‌فهمیم چرا Design for Failure اینقدر مهمه. باید طوری طراحی کنیم که شکست یه جز، به معنای شکست کل سیستم نباشه.


نکته طلایی: ساختن سیستم توزیع‌شده مثل این می‌مونه که یک تیم بسازید - مهم نیست که تک‌تک اعضا چقدر قوی هستند، مهم اینه که چطور با هم همکاری می‌کنن.

نکاتی از فصل اول کتاب Understanding Distributed Systems

با تشکر از جناب Roberto Vitillo برای این کتاب درجه یک!

#understanding_distributed_systems
#roberto_vitillo

کانال تلگرام
@gocasts

این crush عجب چیز خفنیه
یه coding agent ترمینالی با گولنگ

https://github.com/charmbracelet/crush

Your new coding bestie, now available in your favourite terminal.
Your tools, your code, and your workflows, wired into your LLM of choice.

brew install charmbracelet/tap/crush

البته از external-agentها مثل claude-code هم پشتیبانی نمیکنه و فعلا در برنامه شون نیست
https://github.com/charmbracelet/crush/issues/457

@gocasts

گولنگ ۱۶ ساله شد!

مقاله جدید GoCasts با عنوان «Go: زبانی که زیرساخت ابر را بازنویسی کرد - شانزده سال تکامل» منتشر شد
https://gocasts.ir/go-16th-anniversary

در این مقاله تلاش شده علاوه بر مرور ۱۶ سال تکامل زبان Go به بررسی تاثیر این زبان بر اکوسیستم IT بپردازیم و برخی از مهم‌ترین موفقیت‌های این زبان را ذکر کنیم.

مقاله سایت رسمی گولنگ رو هم از طریق لینک زیر میتونید مطالعه کنید.
https://go.dev/blog/16years


@gocasts

تو این ویدیو توضیح داده میشه که postgres و mysql چطوری durability رو تضمین میکنن

https://youtu.be/bFGNZqsKV-E?si=5WvGSwUhqt_PXiIH


@gocasts

نکته‌ای که تجربه‌اش رو توی سیستم‌های 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