🎙 «آغاز ثبت‌نام رویداد Emeet دانشگاه شریف»

سلام دوستان، تمایل داشتید این رویداد رو شرکت کنید با کد تخفیف اختصاصی
gocasts

🔔 رسانا، انجمن علمی دانشکدهٔ مهندسی برق دانشگاه شریف برگزار می‌کند:

⏪اِمیت؛ جایی که صنعت، آکادمی و نوآوری به هم می‌پیوندند.

با حضور مدیران استارتاپ‌های بزرگ داخل و خارج از کشور، اساتید دانشگاه‌های برجستۀ دنیا، کارآفرینان موفق و رهبران صنعتی

📅 تاریخ برگزاری: ۳۰ مهرماه (مجازی) ➕ ۱ و ۲ آبان‌ماه (مجازی و حضوری در دانشگاه صنعتی شریف)
✅ ثبت‌نام برای عموم آزاد است.
📄 همراه با ارائۀ گواهی حضور

✍️ برای ثبت‌نام و کسب اطلاعات بیشتر، به وبسایت رویداد مراجعه فرمایید:
🔗 Emeet.eeresana.com

↙️ پرسش‌های خود پیرامون ثبت‌نام را می‌توانید با پشتیبانی امیت، مطرح کنید.

🌍 Website 💠💼 LinkedIn
🚀 @EmeetSUT 💠🚀 @EEResana



@gocasts

سلامتی زندونیای بی‌ملاقاتی...

عجب داستانی داره این پسره. این آقا یه مهندس ارشد توی یه شرکت دیتابیس به اسم Turso هست که داره SQLite رو از صفر با Rust بازنویسی می‌کنه - و در عین حال الان توی زندان Maine هست! این پسره از سال 2017 توی زندانه، یعنی 8 سال و نیم. اون موقع که 20 سالش بود اومد زندان و عملاً بزرگ شد تو زندان. داستانش از سال 2022 شروع میشه که دانشگاه ثبت‌نام کرد و اتفاقاً همون اولین ترمی بود که توی زندان بهشون لپتاپ دادن و یه نوع دسترسی محدود به اینترنت. یه روز بیدار شد و با خودش گفت "من چرا این زندگی رو قبول کردم؟" - اون لحظه یه تحول ذهنی براش اتفاق افتاد. فکر کرد چه کسی 16 ساعت در روز برای سالها فرصت داره چیز جدید یاد بگیره؟

از اون روز به بعد، روزی 16 ساعت شروع کرد برنامه‌نویسی یاد گرفتن. بعد از فقط 8 ماه، اولین شغلش رو گرفت توی یه شرکتی به اسم Unlock Labs که خودشون هم توسط افراد سابقاً زندانی تاسیس شده بود. اونجا به سرعت پیشرفت کرد، مدیر یه تیم 7 نفره شد، و بالاخره مهندس ارشد شد. بعد شروع کرد توی پروژه‌های اوپن‌سورس مشارکت کنه، تا اینکه Glauber که CEO شرکت Turso هست بهش پیشنهاد داد همون روز شروع کنه کار کردن! الان داره فول‌تایم از زندان روی دیتابیس کار می‌کنه و می‌گه پدر و مادرش بعد از سالها بالاخره بهش افتخار می‌کنن. قراره ماه می‌ِی امسال آزاد بشه و یه خونه هم خریده دقیقاً روبروی خونه پدر و مادرش توی میشیگان. یه داستان واقعی از تحول کامل زندگی، همه‌اش از درون زندان.


خیلی جالبه که سابقه دارای زندان حمایتش کردن برای گرفتن اولین موقعیت شغلی ش
https://youtu.be/AEPf9zUI_fQ?si=pLCxuAwzv7rwIAyc


@gocasts

بروس وین یه آدم شکست‌خورده‌ست، ولی بتمن یه سیستمه! ما باید یاد بگیریم که ایده‌ها رو از آدم‌ها جدا کنیم. وقتی یه استارتاپ کل صداقتش وابسته به شخصیت فاندرش باشه، یه red flag بزرگه. فاندر باید یه node باشه، نه یه قهرمان مطلق. بهترین شرکت‌ها با آدم‌های قابل تعویض اداره می‌شن - و این دقیقاً قدرتشونه. چون سیستم‌ها scale می‌کنن، نه قهرمان‌ها.
نکته کلیدی اینه که سیستم رو طوری طراحی کنیم که تقلب رو گرون کنه، نه اینکه به وعده‌ها اعتماد کنیم. یه سیستم خوب نیاز به incentive های درست داره، نه enforce کردن اخلاق. باید سیستم‌هایی بسازیم که صداقت رو مکانیکی تضمین می‌کنن، نه اخلاقی. Public Choice Theory می‌گه "برای فرشته‌ها طراحی نکن" - درسته! سیستم‌های قهرمان‌محور با قهرمانشون می‌میرن، ولی سیستم‌های یادگیرنده باقی می‌مونن.


سیستم‌هایی که نیاز به قهرمان ندارن
https://vaibhawvipul.github.io/2025/11/10/Build-systems-that-don-t-need-saints.html

@gocasts

لازمه که این نکته رو عرض کنم خدمت تون: نگران هیچی نباشید دوستان با قدرت ادامه بدید
مهم این نیست که چی میشه مهم اینه که در لحظه هر چی در توان داریم بذاریم. اینکه آینده چطور پیش میره برای همه نامعلومه. در لحظه وظیفه ماست که قدم هایی که برای ما معلوم و روشنه برداریم
یکی از واضح ترین قدم ها هم در آغوش گرفتن تمام و کمال 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