یکی دو سال پیش مرورگر Arc رو نصب کردم ولی بعد از مدتی بدون استفاده خاصی حذفش کردم.

چند هفته ای میشه که مجدد نصب ش کردم و با اختلاف بهترین تجربه کاربری ای که یه مرورگر میتونه داشته باشه رو ازش گرفتم.
شاید مهمترین ویژگی ش از نظر من داشتن tab launcher و workspace هست که تجربه کاربری خیلی خوبی ایجاد میکنه.

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

اینجا لینک دانلودش هست میتونید نصب کنید.
https://arc.net/gift/4b5d3e50


@gocasts

به شیوه Joe Armstrong بزرگ کد بنویسید.
برگرفته از کتاب Programming Erlang, Second Edition

برداشت اول: ترجیح میدم برنامه هارو کم کم بزرگشون کنم جای اینکه از اول به نوشتن یه برنامه خیلی بزرگ و جامع فکر کنم.
برداشت دوم: مزیت این روش اینه که immediate feedback میگرم از کدی که نوشتم و از اشتباهات بزرگی که بخواد حجم زیادی از کد رو تحت تاثیر قرار بده جلوگیری میشه.
برداشت سوم: سعی نمیکنم از قبل به ساختار برنامه و data structureهای مورد نیاز فکر کنم. حین برنامه کم کم میفهم م چی لازمه.
برداشت چهارم: یه ذره کد مینویسم٬ یه ذره تست ش میکنم. مجدد همین کارو تا جایی که لازمه ادامه میدم.

How I Write Programs
When I’m writing a program, my approach is to “write a bit” and then “test a bit.” I start with a small module with a few functions, and then I compile it and test it with a few commands in the shell. Once I’m happy with it, I write a few more functions, compile them, test them, and so on. Often I haven’t really decided what sort of data structures I’ll need in my program, and as I run small examples, I can see whether the data structures I have chosen are appropriate.
I tend to “grow” programs rather than think them out completely before writing them. This way I don’t tend to make large mistakes before I discover that things have gone wrong. Above all, it’s fun, I get immediate feedback, and I see whether my ideas work as soon as I have typed in the program.
Once I’ve figured out how to do something in the shell, I usually then go and write a makefile and some code that reproduces what I’ve learned in the shell.

@gocasts

ابزار VictoriaMetrics یه ابزار سریع و مقیاس پذیر برای مانیتورینگ و مدیریت time-series data هست که در توسعه ش خیلی به مساله performance و reliability اهمیت دادن.

حالا یکی از توسعه دهندگانش توصیه کرده که اگه میخواید بدونید سیستم های high performance چطوری با گولنگ توسعه داده میشن کد پروژه VictoriaLogs رو بخونید.

If you want to know how high performance systems written in Go were built, read VictoriaLogs.
1. Custom bloom filters to reduce disk I/O and CPU cycles for redundant logs.

2. Column-oriented block storage for better compression ratio and cache locality.

3. Memory-mapped files with automatic pread fallback for zero-copy reads.

4. Lock-free object pools and arena allocators to reduce heap allocations.

5. Reflection-free JSON parsers for streaming at hundreds of MB/s per core.

6. Compile-time templates replace text/html parsing with near-printf speed.

7. Dictionary-aware Zstd compression balancing CPU cost against bandwidth savings.

8. Multi-core parallelism everywhere with adaptive concurrency limits.

9. Scatter-gather fan-out writes with adaptive concurrency for network saturation.

10. Fast hashing and lock-free randomization for minimal contention.

VictoriaLogs
Fast and easy to use database for logs, which can efficiently handle terabytes of logs
https://github.com/VictoriaMetrics/VictoriaLogs

https://x.com/func25/status/1950115605484552333?t=nlInVX9hO2aYSQa_gRZoog&s=35



@gocasts

به شخصه خیلی از TODO استفاده میکنم وقتی که کد مینویسم.
کاربرد TODO فقط لیست کردن کارهای آینده نیست، خیلی وقتا شما در لحظه نمیتونی تصمیم بگیری که یه شرایطی باید در کد لحاظ بشه یا نه. خیلی وقتا میدونی یه چیزی رو رعایت نکردی و بدهی فنی ایجاد کردی، ولی نمیدونی واقعا این بدهی فنی چقدر مهمه. خیلی وقتا میدونی میشه کد رو بهتر کرد و براش ایده هم داری ولی نمیدونی چقدر ضرورت داره اجرا کردنش. خیلی وقتا میدونی یه چیزی باگه ولی نمیخوای رفعش کنی...
من در همه این موارد همون لحظه یه TODO نسبتا مفصل میذارم که بعدا چه خودم و چه دیگران اون تیکه از کد رو خوندن خیلی بهتر onboard بشن روی کد و چالش هاش.
صادقانه بگم اکثر TODOها هیچوقت قرار نیست کد زده بشه، ولی نوشتن TODO به شما و تیم این اطمینان رو میده که دید قابل قبولی نسبت به بدهی های فنی ای که به عمد در پروژه ایجاد کردید دارید. و هیچ لحظه ای از همون لحظه ای که تمام ذهنتون درگیر پیاده سازی کد هست، بهتر نیست برای نوشتن TODO.

این مقاله هم در همین رابطه ست
https://sophiebits.com/2025/07/21/todos-arent-for-doing


@gocasts

اگه طرفدار و کاربر editorهای ترمینالی مثل vim و مشتقاتش هستید پیشنهاد میکنم حتما Helix رو امتحان کنید.
با Rust توسعه داده شده و learning curve خیلی راحت تری داره.
همیشه لیست hotkeyهای مد نظرتون جلوی چشمتونه و لازم نیست همه چیز رو حفظ کنید یا اونقدر تمرین کنید که ملکه ذهنتون بشه.
دو هفته ای میشه که محیط اصلی توسعه خودم هست و بشدت ازش راضیم.
مزیت اصلی ش نسبت به vim همینه که در یه زمان خیلی محدود میتونید روش مسلط بشید و به عنوان محیط اصلی توسعه ازش استفاده کنید.

ترکیب zellij با helix یه محیط خیلی حرفه ای و customize شده توسعه رو میتونه بهتون بده.
اگه تجربه تون با vim شکست خورده مثل من، با helix یه تلاش مجدد کنید شاید این بار موفقیت آمیز باشه...
https://helix-editor.com


@gocasts

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

https://github.com/RezaSi/go-interview-practice



@gocasts

یه محیط خیلی جذاب برای یادگیری الگوهای Concurrency گولنگ بصورت تعاملی

Go Concurrency Explorer
Interactive Learning Platform
https://www.concurrency.rocks


@gocasts

نکاتی در مورد code review

مواردی که اشاره میکنه صرفا نکات فنی نیست و به نظرم نکات غیرفنی ای که بهش اشاره میکنه خیلی موثر هست در ایجاد یک فضای مناسب و پایدار برای داشتن فرهنگ Code Review در تیم.

این مقاله نکات ساده و مهمی رو اشاره میکنه که خوبه مطالعه بشه
https://endler.dev/2025/how-to-review-code/


@gocasts

نسخه ۱.۲۵ گولنگ منتشر شد.

در این نسخه هیچ تغییری در زبان رخ نداده و این از زیبایی های یک زبانه که علاوه بر ساده و جمع و جور بودنش نرخ تغییرات زبانش بقدری کم و آرامه که لازم نیست دغدغه بروزرسانی کدهای قدیمی رو داشته باشی.

شاید مهمترین بهبودی هم که رخ داده container-aware GOMAXPROCS باشه که قبلا مقدارش تعداد logical cpu موجود بود و این برای کانتینرها دردسر ایجاد میکرد و مجبور بودیم همیشه تو کد پکیج معروف uber رو برای حلش استفاده کنیم.
از این نسخه به بعد خود runtime در سیستم عامل لینوکس محدودیت cpu bandwidth از process cgroup رو در نظر میگیره که خیلی خوبه.
همچنین runtime بصورت دوره ای GOMAXPROCS رو بروز میکنه اگه لازم باشه.


بهبود مهم دیگه که البته نسخه آزمایشی ش ارائه شده garbage collector جدید هست که بخاطر بهبودهای طراحی ای که داشته انتظار میره بین ۱۰ تا ۴۰ درصد gc overhead رو کاهش بده برای برنامه هایی که استفاده سنگین از gc دارن.

https://go.dev/doc/go1.25


@gocasts

۵۰ درصد + یک میلیون و ۶۰۰ هزار تومان تخفیف شهریور

سلام به همه دوستان
به لطف خدا تا این لحظه تیمسازی بیش از ۱ سال و ۹ ماهه که ادامه داشته و پروژه پنجم تیمسازی رو چند هفته ست که شروع کردیم.
در مورد اهمیت تیمسازی چند استوری در تلگرام گذاشتم که میتونید از طریق این لینک ببینید
https://news.1rj.ru/str/lifography/s/2

دوره +‌ تیمسازی بکند و گولنگ Go Casts
تخفیف ویژه شهریور
۵۰ درصد + ۱ میلیون و ۶۰۰ هزار تومان تخفیف
کد شهریور
SHAHRIVAR

خرید از سایت
https://gocasts.ir

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

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

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

دوستانی که اکانت پرمیوم تلگرام دارن، اگه تمایل داشتید میتونید به کانال GoCasts منت بذارید و boost بدید که بتونیم استوری هارو از طریق خود کانال GoCasts منتشر کنیم و نه اکانت شخصی
https://news.1rj.ru/str/boost/gocasts


@gocasts

مستند Python منتشر شد، پیشنهاد میکنم ببینید.

پایتون یکی از تاثیرگذارترین زبان های سه دهه گذشته بوده و احتمالا تاثیرگذارترین زبان چند سال یا دهه آینده باشه..

https://youtu.be/GfH4QL4VqJ0?si=cR5PFyhoq7kr7EhQ


@gocasts

سلام به همه دوستان گل

میلاد رسول الله مبارک باشه، ان شاءالله همیشه خوب و خوش باشید ❤️❤️

ببخشید یه مدتی کمتر در خدمت تون بودم.

تو این مقاله پکیج های جدید json برای گولنگ معرفی شدند که بهبودهایی که مدت ها بود تقاضا میشد اضافه شده. فعلا نسخه آزمایشی هست.

https://go.dev/blog/jsonv2-exp

@gocasts

چقدر یه مقاله میتونه تمیز و جذاب باشه. موقع نوشتن این مقاله عشق ریخته پای کلمات و کارهای گرافیکی ش 😁❤️

اومده با کلی کار گرافیکی باحال انواع io deviceها رو مقایسه کرده از نظر latency و چیزای دیگه
https://planetscale.com/blog/io-devices-and-latency


@gocasts

روز برنامه نویس مبارک 🔥

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

۵۰ درصد + ۲ میلیون تومان تخفیف روز برنامه نویس


دوره +‌ تیمسازی بکند و گولنگ Go Casts
تخفیف ویژه روز برنامه نویس
۵۰ درصد + ۲ میلیون تومان تخفیف
کد تخفیف ویژه روز برنامه نویس
PDAY

خرید از سایت
https://gocasts.ir

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

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

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


@gocasts

سازنده Redis در جواب توییتی که نوشته بود تکنولوژی ای رو نام ببرید که quality خیلی زیادی داره و hype کمی داره، از ruby language design نام برده بود.

دلایل مختلفی برای این قضیه وجود داره من چندتا شو سعی میکنم ذکر کنم.
یکی اینکه آقای Matsumoto سازنده Ruby اولویت ش برای طراحی زبان رو productive بودن برنامه نویس ها در نظر گرفته بود و نه speed و چیزای دیگه..
به عبارتی developer happiness با کم کردن confusion در کدنویسی

زبان Ruby یک زمان کاملا Object-Oriented هست. اما فرق میکنه با اون چیزی که از OOP میدونیم..
یکی از نکات جالب طراحی Ruby وفاداری ش به تعریف OOP از آقای Alan Kay هست که در SmalTalk هم طراحی شده.
در تعریف آقای Alan Kay هر object با objectهای دیگه از طریق message passing ارتباط برقرار میکنه و نه از طریق method callها.

این چیزی هست که در زبان ruby هم طراحی شده. در ruby شما send message میکنی به object و اون object میتونه تصمیم بگیره که به پیام شما پاسخ بده و یا نده.

یکی دیگه از ایده های Alan Kay برای oop که به objectها انعطاف بیشتری میده تغییر رفتار objectها در runtime هست.

نکته کلیدی ای که در مورد OOP از نظر آقای Kay وجود داره که در Ruby هم پیاده سازی شده اینه که رفتار یا behaviour که معمولا از طریق interface تعریف میشه به object وابسته ست و نه class.

تعریف مرسومی که ما از OOP تو ذهن داریم رفتار وابسته به class هست. چیزی که در java و cpp هم خیلی رایجه.
اما تعریفی که آقای Kay از oop داره و در ruby هم پیاده سازی شده رفتار وابسته به object هست ونه class.
تعریف آقای Kay اگه درست رعایت بشه باعث میشه اصل composition over inheritance رعایت بشه. اصلی که مهمه و زبان های دیگه مثل گولنگ هم خیلی این مورد رو بهش اهمیت دادن.

آقای Kay معتقده که
behavioral composition is often better than deep inheritance hierarchies


یادگیری یه زبانی مثل ruby کمک میکنه که اصول oop آقای Kay رو بهتر متوجه بشیم و ذهنیتمون کاملا متفاوت بشه نسبت به OOPی که زبان های java و cpp به ما تحمیل کردن...


@gocasts

اگه دارید یه پروژه گولنگی رو سنگین ریفکتور میکنید ‍‍پیشنهاد میکنم از
// Deprecated
خیلی زود استفاده کنید

قشنگی قضیه اینه که lsp گولنگ وقتی چنین کامنتی روی تابع یا type یا field خاصی قرار میگیره متوجه میشه و شما حین ریفکتور خیلی راحت قسمت هایی که deprecate شده رو میتونید از کد حذف کنید و یا صرفا جهت backwardCompatibility نگهشون دارید.
خیلی پیچیدگی ریفکتور رو کم میکنه مخصوصا اگه تعداد تغییرات زیاد باشه.

همچنین اگه به تیم ها و کلاینت هاتون sdk ارائه دادید میتونید برای backward compatibility این فیلدهارو حفظ کنید ولی اون deprecated annotation بهشون هشدار میده که نباید دیگه ازش استفاده کنن.
ضمنا بهتره تو توضیحات روش جایگیزین (اگه وجود داره رو) اشاره کنید که کم کم کلاینت های sdk هم تشویق بشن از روش جایگزین استفاده کنن.

توضیحات بیشتر رو اینجا میتونید بخونید
https://go.dev/wiki/Deprecated


@gocasts

دو تا ابزار pgcli و mycli خیلی میتونه کار با دیتابیس هارو راحت تر و حتی امن تر کنه در محیط ترمینال

اولا که خیلی ux خوبی دارن و auto complete داره خیلی کارو راحت میکنه

دوما اینکه برای دستورات خطرناکی مثل آپدیت و حذف و غیره ازت یه تایید ثانویه دستور میگیره که خیلی ریسک اجرا رو کمتر میکنه اگه ریویو کنی دستور رو قبل از اجرا

مرسی از روزبه جان برای معرفی mycli
@terminal_stuff


pgcli
https://github.com/dbcli/pgcli

mycli
https://github.com/dbcli/mycli


@gocasts

در نگاه اول async کردن یه روند بیزینسی یا فنی شاید ساده به نظر بیاد و خیلی مزیت ها داشته باشه. معماری هایی مثل event-driven هم خیلی معروف هستند و پرطرفدار

اما در واقعیت و روی مقیاس بالا چالش های مهمی هم دارند که باید بهشون توجه بشه
چالش هایی مثل observability و idempotency و حتی درک موضوع eventual consistency خودش میتونه چالش برانگیز باشه

این مقاله کوتاه نکات خوبی رو اشاره کرده در این مورد

Why are Event-Driven Systems Hard?
Understanding the Core Challenges of Asynchronous Architectures

https://newsletter.scalablethread.com/p/why-event-driven-systems-are-hard


@gocasts