سلامتی زندونیای بیملاقاتی...
عجب داستانی داره این پسره. این آقا یه مهندس ارشد توی یه شرکت دیتابیس به اسم 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
عجب داستانی داره این پسره. این آقا یه مهندس ارشد توی یه شرکت دیتابیس به اسم 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
YouTube
Rewriting SQLite from prison with Preston Thorpe
In this episode of Database School, Aaron talks with Preston Thorpe, a senior engineer at Turso who is currently incarcerated, about his incredible journey from prison to rewriting SQLite in Rust. They dive deep into concurrent writes, MVCC, and the challenges…
❤82👏26👍7🔥6
Forwarded from Ai Casts | Ai for Software
وقتی نیاز شخصیات میشه محصول ۵۰۰ میلیون دلاری
سپتامبر ۲۰۲۴، یه برنامهنویس به اسم Boris Cherny تازه به Anthropic جوین شده بود. داشت با مدل Claude ور میرفت که خودش رو با APIهاشون بیشتر آشنا کنه. اولین ابزارش یه چیز خیلی ساده بود: یه برنامه ترمینال که بهش میگفتی الان چه آهنگی داری گوش میدی! خیلی basic، خیلی شخصی، ولی جالب بود. بعد یه روز یهو به ذهن Boris خطور کرد که چرا فقط AppleScript؟ چرا نذاریم فایلسیستم رو ببینه؟ چرا نذاریم bash commands بزنه؟
همین که این قابلیتها رو اضافه کرد، دنیاش عوض شد. Claude شروع کرد به explore کردن کد، خوندن فایلها، دنبال کردن importها، و پیدا کردن جوابها. Boris خودش میگه: "این همون لحظهای بود که فهمیدم یه چیز بزرگ داره میشه." ابزاری که برای خودش ساخته بود، یهو تبدیل شد به چیزی که همکاراش هم میخواستن ازش استفاده کنن. تا روز پنجم، ۵۰٪ تیم مهندسی Anthropic داشتن باهاش کار میکردن!
حالا Claude Code یه ماشین درآمدزایی ۵۰۰ میلیون دلاری شده. یه تیم کامل داره، features جدید هر روز اضافه میشه، و داستانش شبیه همون چیزیه که Ken Thompson درباره Unix گفته بود:
"Unix was built for me. I didn't build it as an operating system for other people, I built it to do games, and to do my stuff."
یعنی Unix هم اول یه ابزار شخصی بود، بعد شد اساس سیستمعاملهای امروزی.
نکته داستان چیه؟ وقتی چیزی میسازی که واقعاً نیاز خودت رو رفع کنه، احتمالش خیلی زیاده که برای دیگرانی که نیاز مشابه دارن هم مفید باشه. Boris داشت یه مشکل شخصی حل میکرد، نه یه محصول تعریفشده. تیم Claude Code الانم با همین فلسفه کار میکنه: کمترین کد ممکن، سادهترین معماری، و اجازه بده مدل کارشو بکنه. حتی ۹۰٪ کد Claude Code با خود Claude Code نوشته شده! پس دفعه بعد که احساس میکنی یه ابزاری لازمه، نشین منتظر شرکتها یا استارتاپها. خودت بساز. شاید امروز فقط برای خودته، ولی فردا میشه یکی از بهترین ابزارهای دنیا.
https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built
📱 @gocasts
Ai for Software
📱 @aicasts_ir
سپتامبر ۲۰۲۴، یه برنامهنویس به اسم Boris Cherny تازه به Anthropic جوین شده بود. داشت با مدل Claude ور میرفت که خودش رو با APIهاشون بیشتر آشنا کنه. اولین ابزارش یه چیز خیلی ساده بود: یه برنامه ترمینال که بهش میگفتی الان چه آهنگی داری گوش میدی! خیلی basic، خیلی شخصی، ولی جالب بود. بعد یه روز یهو به ذهن Boris خطور کرد که چرا فقط AppleScript؟ چرا نذاریم فایلسیستم رو ببینه؟ چرا نذاریم bash commands بزنه؟
همین که این قابلیتها رو اضافه کرد، دنیاش عوض شد. Claude شروع کرد به explore کردن کد، خوندن فایلها، دنبال کردن importها، و پیدا کردن جوابها. Boris خودش میگه: "این همون لحظهای بود که فهمیدم یه چیز بزرگ داره میشه." ابزاری که برای خودش ساخته بود، یهو تبدیل شد به چیزی که همکاراش هم میخواستن ازش استفاده کنن. تا روز پنجم، ۵۰٪ تیم مهندسی Anthropic داشتن باهاش کار میکردن!
حالا Claude Code یه ماشین درآمدزایی ۵۰۰ میلیون دلاری شده. یه تیم کامل داره، features جدید هر روز اضافه میشه، و داستانش شبیه همون چیزیه که Ken Thompson درباره Unix گفته بود:
"Unix was built for me. I didn't build it as an operating system for other people, I built it to do games, and to do my stuff."
یعنی Unix هم اول یه ابزار شخصی بود، بعد شد اساس سیستمعاملهای امروزی.
نکته داستان چیه؟ وقتی چیزی میسازی که واقعاً نیاز خودت رو رفع کنه، احتمالش خیلی زیاده که برای دیگرانی که نیاز مشابه دارن هم مفید باشه. Boris داشت یه مشکل شخصی حل میکرد، نه یه محصول تعریفشده. تیم Claude Code الانم با همین فلسفه کار میکنه: کمترین کد ممکن، سادهترین معماری، و اجازه بده مدل کارشو بکنه. حتی ۹۰٪ کد Claude Code با خود Claude Code نوشته شده! پس دفعه بعد که احساس میکنی یه ابزاری لازمه، نشین منتظر شرکتها یا استارتاپها. خودت بساز. شاید امروز فقط برای خودته، ولی فردا میشه یکی از بهترین ابزارهای دنیا.
https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built
Ai for Software
Please open Telegram to view this post
VIEW IN TELEGRAM
Pragmaticengineer
How Claude Code is built
A rare look into how the new, popular dev tool is built, and what it might mean for the future of software building with AI. Exclusive.
👍55❤5🔥2
بروس وین یه آدم شکستخوردهست، ولی بتمن یه سیستمه! ما باید یاد بگیریم که ایدهها رو از آدمها جدا کنیم. وقتی یه استارتاپ کل صداقتش وابسته به شخصیت فاندرش باشه، یه 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
نکته کلیدی اینه که سیستم رو طوری طراحی کنیم که تقلب رو گرون کنه، نه اینکه به وعدهها اعتماد کنیم. یه سیستم خوب نیاز به incentive های درست داره، نه enforce کردن اخلاق. باید سیستمهایی بسازیم که صداقت رو مکانیکی تضمین میکنن، نه اخلاقی. Public Choice Theory میگه "برای فرشتهها طراحی نکن" - درسته! سیستمهای قهرمانمحور با قهرمانشون میمیرن، ولی سیستمهای یادگیرنده باقی میمونن.
سیستمهایی که نیاز به قهرمان ندارن
https://vaibhawvipul.github.io/2025/11/10/Build-systems-that-don-t-need-saints.html
@gocasts
Vipul Vaibhaw
Build systems that don’t need saints
Bruce Wayne is a mess. Batman is a system.
❤35👍17👏3
اسیر شدیم. صبح به صبح میرم شرکت سماور رو روشن میکنم چای دم میکنم خسته خسته میاد سر کار صبحونه شو میخوره کاراشو انجام میده. بعدشم یه چندتا کوچیک و بزرگ بارمون میکنه که تو نمیفهمی و این چه وضعشه و اینا. عصرم کاراشو تحویل میده و میره خونه. این چه وضعشه آقای claude 🥲
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝28
Go Casts 🚀
اسیر شدیم. صبح به صبح میرم شرکت سماور رو روشن میکنم چای دم میکنم خسته خسته میاد سر کار صبحونه شو میخوره کاراشو انجام میده. بعدشم یه چندتا کوچیک و بزرگ بارمون میکنه که تو نمیفهمی و این چه وضعشه و اینا. عصرم کاراشو تحویل میده و میره خونه. این چه وضعشه آقای claude…
لازمه که این نکته رو عرض کنم خدمت تون: نگران هیچی نباشید دوستان با قدرت ادامه بدید
مهم این نیست که چی میشه مهم اینه که در لحظه هر چی در توان داریم بذاریم. اینکه آینده چطور پیش میره برای همه نامعلومه. در لحظه وظیفه ماست که قدم هایی که برای ما معلوم و روشنه برداریم
یکی از واضح ترین قدم ها هم در آغوش گرفتن تمام و کمال ai برای بهبود بهره وری کارمون هست
اینطوری هم نیست که یک شبه همه چیز بهم بریزه. هوش مصنوعی بیشتر از اینکه فرصت از بین ببره فرصت ایجاد میکنه. توکل به خدا محکم بریم جلو ان شاءالله خوب پیش میره برامون
مهم این نیست که چی میشه مهم اینه که در لحظه هر چی در توان داریم بذاریم. اینکه آینده چطور پیش میره برای همه نامعلومه. در لحظه وظیفه ماست که قدم هایی که برای ما معلوم و روشنه برداریم
یکی از واضح ترین قدم ها هم در آغوش گرفتن تمام و کمال ai برای بهبود بهره وری کارمون هست
اینطوری هم نیست که یک شبه همه چیز بهم بریزه. هوش مصنوعی بیشتر از اینکه فرصت از بین ببره فرصت ایجاد میکنه. توکل به خدا محکم بریم جلو ان شاءالله خوب پیش میره برامون
❤70👍7
کتاب 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
نکاتی که هر 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
❤54👍3🔥1
Go Casts 🚀
کتاب Understanding Distributed Systems نکاتی که هر developerی در مورد distributed applicationها باید بدونه چرا همه درباره Distributed Systems حرف میزنن؟ 🤔 وقتی اولین بار با سیستمهای توزیعشده آشنا شدم، فکر میکردم فقط برای شرکتهای بزرگ مثل Google و Amazon…
یکی از زیباترین جنبه های سیستم های توزیع شده 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
پارت دوم: 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
❤27👍2
This media is not supported in your browser
VIEW IN TELEGRAM
این 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.
البته از external-agentها مثل claude-code هم پشتیبانی نمیکنه و فعلا در برنامه شون نیست
https://github.com/charmbracelet/crush/issues/457
@gocasts
یه 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
❤19
گولنگ ۱۶ ساله شد!
مقاله جدید GoCasts با عنوان «Go: زبانی که زیرساخت ابر را بازنویسی کرد - شانزده سال تکامل» منتشر شد
https://gocasts.ir/go-16th-anniversary
در این مقاله تلاش شده علاوه بر مرور ۱۶ سال تکامل زبان Go به بررسی تاثیر این زبان بر اکوسیستم IT بپردازیم و برخی از مهمترین موفقیتهای این زبان را ذکر کنیم.
مقاله سایت رسمی گولنگ رو هم از طریق لینک زیر میتونید مطالعه کنید.
https://go.dev/blog/16years
@gocasts
مقاله جدید GoCasts با عنوان «Go: زبانی که زیرساخت ابر را بازنویسی کرد - شانزده سال تکامل» منتشر شد
https://gocasts.ir/go-16th-anniversary
در این مقاله تلاش شده علاوه بر مرور ۱۶ سال تکامل زبان Go به بررسی تاثیر این زبان بر اکوسیستم IT بپردازیم و برخی از مهمترین موفقیتهای این زبان را ذکر کنیم.
مقاله سایت رسمی گولنگ رو هم از طریق لینک زیر میتونید مطالعه کنید.
https://go.dev/blog/16years
@gocasts
❤46👍2🎉2
تو این ویدیو توضیح داده میشه که postgres و mysql چطوری durability رو تضمین میکنن
https://youtu.be/bFGNZqsKV-E?si=5WvGSwUhqt_PXiIH
@gocasts
https://youtu.be/bFGNZqsKV-E?si=5WvGSwUhqt_PXiIH
@gocasts
YouTube
SREcon25 Europe/Middle East/Africa - The Computer Wants to Lose Your Data
The Computer Wants to Lose Your Data
Chris Sinjakli, PlanetScale
Storing data is something we expect computers to just do. When your application writes data to a database, you trust it to give you that data back later, but what does it take to make that…
Chris Sinjakli, PlanetScale
Storing data is something we expect computers to just do. When your application writes data to a database, you trust it to give you that data back later, but what does it take to make that…
👍13
نکتهای که تجربهاش رو توی سیستمهای 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
مثلاً شروع با 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
Linkedin
در سالهایی که روی Software Architecture و Distributed System Design کار کردهام، بیشترین سوءتفاهمی که دیدهام این است که تصور…
در سالهایی که روی Software Architecture و Distributed System Design کار کردهام، بیشترین سوءتفاهمی که دیدهام این است که تصور میشود برای هر پروژه یک «نسخهی واحد» وجود دارد؛ از انتخاب معماری گرفته تا انتخاب زیرساخت.
اما واقعیت این است که در مهندسی نرمافزار،…
اما واقعیت این است که در مهندسی نرمافزار،…
👍27❤11🔥6👏4
Forwarded from Ai Casts | Ai for Software
این چند ماه که از claude زیاد استفاده کردم کاملا به یه سطحی رسیده بود که دیگه از vibe coding فراتر رفته بود و خودم اسمش رو گذاشته بودم agent-first development.
معتقدم بزودی باید تلاش کنیم یه بازبینی اساسی در روند توسعه هامون داشته باشیم چون سطح کارآمدی توسعه agent-first کاملا متفاوته با agent-assisted.
برای agent-first شدن در سطح سازمان و شرکت هایی که سرویس و codebaseهای بزرگ دارن باید از همین امروز کار شروع بشه که انتظار داشت چند سال دیگه بهینگی مد نظر بدست بیاد. ولی برای سرویس های کوچیک و استارتآپ ها میشه انتظار داشت که در بازه کوتاه مدت این کارآمدی زودتر خودش رو نشون بده.
امروز که گوگل همراه با معرفی Gemini 3 Pro از یه IDE جایگزین cursor رونمایی کرده که اسمش رو گذاشته Antigravity
نکته جالبش اینه که همون اول که میخوای نصبش کنی ازت میپرسه که میخوای agent-driven توسعه بدی یا agent-assisted.
درسته که recommendationش فعلا روی agent-assisted هست ولی احتمالا بزودی این اولویتبندی هم تغییر میکنه..
https://antigravity.google
📱 @gocasts
Ai for Software
📱 @aicasts_ir
معتقدم بزودی باید تلاش کنیم یه بازبینی اساسی در روند توسعه هامون داشته باشیم چون سطح کارآمدی توسعه agent-first کاملا متفاوته با agent-assisted.
برای agent-first شدن در سطح سازمان و شرکت هایی که سرویس و codebaseهای بزرگ دارن باید از همین امروز کار شروع بشه که انتظار داشت چند سال دیگه بهینگی مد نظر بدست بیاد. ولی برای سرویس های کوچیک و استارتآپ ها میشه انتظار داشت که در بازه کوتاه مدت این کارآمدی زودتر خودش رو نشون بده.
امروز که گوگل همراه با معرفی Gemini 3 Pro از یه IDE جایگزین cursor رونمایی کرده که اسمش رو گذاشته Antigravity
نکته جالبش اینه که همون اول که میخوای نصبش کنی ازت میپرسه که میخوای agent-driven توسعه بدی یا agent-assisted.
درسته که recommendationش فعلا روی agent-assisted هست ولی احتمالا بزودی این اولویتبندی هم تغییر میکنه..
https://antigravity.google
Ai for Software
Please open Telegram to view this post
VIEW IN TELEGRAM
👍41❤11
وقتی یک خط کد، نیمی از اینترنت را از کار انداخت
گزارش مفصل فنی GoCasts رو از مشکلی که برای cloudflare پیش اومد بخونید
سعی شده علاوه بر شرح جزییات نکات فنی و مهندسیای ذکر بشه که میتونیم رعایت کنیم که از مشکلات مشابه برای خودمون و در سطح خودمون جلوگیری کنیم.
https://gocasts.ir/cloudflare-outage-analysis/
امیدورام خوشتون بیاد 🌺
@gocasts
گزارش مفصل فنی GoCasts رو از مشکلی که برای cloudflare پیش اومد بخونید
سعی شده علاوه بر شرح جزییات نکات فنی و مهندسیای ذکر بشه که میتونیم رعایت کنیم که از مشکلات مشابه برای خودمون و در سطح خودمون جلوگیری کنیم.
https://gocasts.ir/cloudflare-outage-analysis/
امیدورام خوشتون بیاد 🌺
@gocasts
❤43👍23
این claude فلان فلان شده زد همه فایل های روی سرور سایتمو حذف کرد
خیلی رو دادم بهش..
بهش گفتم دیپلوی کن اول پاک کرد بعد دیپلوی کرد
در کل هیچ عیب و ایرادی سمت claude نیست مقصر منم که توجیه ش نکردم 🙂
اینو شوخی نکردم. جدی میگم. رابطه ت با agentها مثل نیروهای کاری باید باشه که soft-skillی ضعیفه و باید کم کم کمکش کنی
@gocasts
خیلی رو دادم بهش..
بهش گفتم دیپلوی کن اول پاک کرد بعد دیپلوی کرد
در کل هیچ عیب و ایرادی سمت claude نیست مقصر منم که توجیه ش نکردم 🙂
اینو شوخی نکردم. جدی میگم. رابطه ت با agentها مثل نیروهای کاری باید باشه که soft-skillی ضعیفه و باید کم کم کمکش کنی
@gocasts
🤣66👍15❤3
Go Casts 🚀
یه سری از مهندس ها هستن که از همون لحظه اول که باهاشون هم کلام میشی متوجه میشی که با کوله باری از تجربه و دانش مواجهی و اگه فرصت طلب باشی تا بتونی سعی میکنی از دریای دانش شون ذره ای بهره مند بشی. بهراد جان از نظر من قطعا جز همین دسته از مهندسین هست، که نه…
در مورد مهندس بهراد قبلا گفتنی هارو گفتم، اینجا میتونید بخونید
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
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
Telegram
Go Casts 🚀
یه سری از مهندس ها هستن که از همون لحظه اول که باهاشون هم کلام میشی متوجه میشی که با کوله باری از تجربه و دانش مواجهی و اگه فرصت طلب باشی تا بتونی سعی میکنی از دریای دانش شون ذره ای بهره مند بشی.
بهراد جان از نظر من قطعا جز همین دسته از مهندسین هست، که نه…
بهراد جان از نظر من قطعا جز همین دسته از مهندسین هست، که نه…
❤12
زبان 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
این روزها هرجا نگاه میکنم، یه پروژه 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
👍46❤16
بهینه سازی گولنگ برای سیستم های پردازشی با حجم بالای داده
این مقاله نکات جالبی نوشته برای وقتی که یه سرویس گولنگی داری که باید 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
این مقاله نکات جالبی نوشته برای وقتی که یه سرویس گولنگی داری که باید 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
packagemain.tech
Golang optimizations for high‑volume services
Lessons from a Postgres → Elasticsearch pipeline
❤26👍2
بعد از تقریبا پنج سال زمان جدایی از اسنپ فرا رسید...
همیشه میخواستم با حس و حال خوب از اسنپ جدا بشم و الحمدلله فکر میکنم این اتفاق رخ داده.
آدمای زیادی هستن که باید ازشون تشکر کنم، هر کسی یه روزی در اسنپ بوده بدونه من وامدارشم و مدیونشم، چون مستقیم یا غیرمستقیم احتمالا یه چیزی ازش یاد گرفتم، از نبوغ ش، از نوآوری و خلاقیت ش و حتی از اشتباهات ش، چون خود من سر تا پا اشتباهم...
به ویژه از همکاران عزیزم در تیم های NBO و Pricing و Dispatching تشکر میکنم. اگه امکانش بود دوست داشتم تک تک بچه هارو منشن کنم اما خب خیلی کار سختیه این همه همکار گرامی رو بخوام منشن کنم. فقط بدونن که ارادتمند تک تک شون هستم ❤️.
قطعا اسنپ با اختلاف بهترین تجربه کاری من در دهه گذشته بوده و از یک سری ابعاد٬ چالش و تجربیاتش قابل مقایسه با جاهای دیگه نیست. و قطعا بیش از آنکه من چیزی ارائه کرده باشم برای اسنپ٬ اسنپ برای من کلی آورده فنی و غیرفنی داشته.
انسان یک بار بیشتر فرصت زندگی کردن نداره و مسیرهایی که دوست داره طی کنه خیلی زیادن. پس به ناچار در دوراهی های زیادی قرار میگیری و از بین اونا فقط یکی رو میتونی انتخاب کنی. ان شاءالله که خیره...
Snapp!
بازم از همه تشکر میکنم. دم همه تون گرم، مثل همیشه خوش بدرخشید 💚💚
@gocasts
همیشه میخواستم با حس و حال خوب از اسنپ جدا بشم و الحمدلله فکر میکنم این اتفاق رخ داده.
آدمای زیادی هستن که باید ازشون تشکر کنم، هر کسی یه روزی در اسنپ بوده بدونه من وامدارشم و مدیونشم، چون مستقیم یا غیرمستقیم احتمالا یه چیزی ازش یاد گرفتم، از نبوغ ش، از نوآوری و خلاقیت ش و حتی از اشتباهات ش، چون خود من سر تا پا اشتباهم...
به ویژه از همکاران عزیزم در تیم های NBO و Pricing و Dispatching تشکر میکنم. اگه امکانش بود دوست داشتم تک تک بچه هارو منشن کنم اما خب خیلی کار سختیه این همه همکار گرامی رو بخوام منشن کنم. فقط بدونن که ارادتمند تک تک شون هستم ❤️.
قطعا اسنپ با اختلاف بهترین تجربه کاری من در دهه گذشته بوده و از یک سری ابعاد٬ چالش و تجربیاتش قابل مقایسه با جاهای دیگه نیست. و قطعا بیش از آنکه من چیزی ارائه کرده باشم برای اسنپ٬ اسنپ برای من کلی آورده فنی و غیرفنی داشته.
انسان یک بار بیشتر فرصت زندگی کردن نداره و مسیرهایی که دوست داره طی کنه خیلی زیادن. پس به ناچار در دوراهی های زیادی قرار میگیری و از بین اونا فقط یکی رو میتونی انتخاب کنی. ان شاءالله که خیره...
Snapp!
بازم از همه تشکر میکنم. دم همه تون گرم، مثل همیشه خوش بدرخشید 💚💚
@gocasts
Linkedin
Snapp! | LinkedIn
Snapp! | 94,307 followers on LinkedIn. Your all-in-one solution for transportation, delivery services and more in Iran; Snapp super app is more than just a number of services; it's a commitment to transforming the way you travel, explore, and connect. At…
❤145👍21🔥4🤝1
واقعاً لذت بردم از نحوه نوشتن این مقاله. نویسنده یه موضوع نسبتاً پیچیده رو با انیمیشن و 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
موضوعش 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
🔥17❤14👍8
استفاده از 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
یکی از پادکستهای جذابی که اخیرا منتشر شده، مصاحبه با 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
Corrode Rust Consulting
Rust for Linux with Danilo Krummrich - Rust in Production Podcast | corrode Rust Consulting
Bringing Rust into the Linux kernel is one of the most ambitious m…
🔥31❤12👍8