چرا سایز استاندارد لایبرری مهم نیست
خلاصهٔ کاملتر
دعوای همیشگی بین برنامهنویسها اینه که standard library (یعنی مجموعه ابزارها و توابعی که خود زبان از اول همراهش میاره) یه زبان باید مینیمال باشه یا همهچیزو پوشش بده. نویسنده این پست میگه این اصلا سوال درستی نیست. سوال واقعی اینه که تیم پشت زبان چقدر ظرفیت سازمانی داره تا APIهای خوب طراحی کنه، نگهداریشون کنه و جاهای خالیشو پر کنه.
پایتون همیشه بهعنوان نمونهی بد این ماجرا معرفی میشه، ولی مشکلش سایز نیست، کیفیت ناهمگونشه؛ مثلا ماژول unittest اسمش از قوانین نامگذاری خود پایتون پیروی نمیکنه. اما به گفتهی نویسنده همین ویژگی یه مزیت هم هست: پایتون زود قابلیتها رو در دسترس میذاره بدون اینکه زیادی نگران آینده باشه، و دقیقا همین باعث شده اکوسیستم دیتا ساینس روی پایتون شکل بگیره.
استاندارد لایبرری گو هم بزرگه ولی برخلاف پایتون خیلی مورد احترامه، چون تیم گو ظرفیت اینرو داره که APIهای خوب طراحی کنه، و حتی یه مخزن جدا به اسم golang.org/x داره برای چیزایی که هنوز به استاندارد اصلی نرسیدن. رست یه داستان دیگهست: استاندارد لایبرری نسخه ۱٫۰ش (مثل کالکشنها و iterator ها، یعنی ابزارهایی که رو دادهها یکییکی حرکت میکنن) عالی طراحی شده، ولی تیم فعلیش بیشتر تمرکزش رو نگهداری همینایی که هست میذاره تا گرفتن تصمیمهای تازه.
نویسنده یه مثال جالب میزنه: تا سال ۲۰۲۶ رست تو استاندارد لایبرریش راه سادهای برای گرفتن بایتهای تصادفی واقعی از سیستمعامل نداره، درحالیکه از نظر فنی کار سختی نیست. مشکل اینجا فنی نیست، سازمانیه؛ حل کردنش نیاز به هماهنگی جهانی و حتی تامین مالی داره، برخلاف golang.org/x که ظرفیت اضافه رو جمع میکنه، مخزن rust-lang-nursery بیشتر شبیه یه قبرستونه.
نکات کلیدی:
- سوال درست دربارهٔ استاندارد لایبرری «کوچیک یا بزرگ» نیست، بلکه ظرفیت تیم برای طراحی و نگهداریشه
- ناهماهنگی استاندارد لایبرری پایتون (مثل نامگذاری unittest) از سایزش مهمتره
- گو با golang.org/x یه مسیر رسمی برای بلوغ قابلیتهای جدید داره
- استاندارد لایبرری ۱٫۰ رست (کالکشنها، iterator ها) قوی طراحی شده ولی تصمیمگیریهای جدید کنده
- رست تا ۲۰۲۶ هنوز راه سادهای برای گرفتن بایت تصادفی از سیستمعامل نداره؛ دلیلش سازمانیه نه فنی
- مخزن rust-lang-nursery برخلاف golang.org/x عملا غیرفعاله
