یک زبان برنامه‌نویسی وقتی برای محیط عملیاتی (Production) آماده است که کسب‌وکاری بتواند سال‌ها بدون غافل‌گیری ناخوشایند به آن تکیه کند: کد پس از ارتقا همچنان کامپایل شود، انتشارها قابل‌اعتماد باشند، مشکلات امنیتی مسیری برای گزارش داشته باشند، ابزارها و سکوها پوشش داده شوند، بتوان نیرو استخدام یا تربیت کرد، و پروانه با محصول جور باشد. آمادگی برای محیط عملیاتی ویژگی کل پروژه‌ی اطراف یک زبان است، نه فقط کامپایلرش. این نوشته فهرست بررسی‌ای را می‌آورد که تیم‌های سازمانی معمولاً به یک شکل یا شکل دیگر به کار می‌برند، و زبان برنامه‌نویسی سلام را با آنچه مخزن واقعاً دارد در برابر هر بند ارزیابی می‌کند. نتیجه دوگانه است: سلام در مهندسی قوی است و در تضمین‌های نهادی که با گذشت زمان می‌آیند ضعیف.

فهرست بررسی آمادگی عملیاتی زبان سلام

هیچ استاندارد رسمی واحدی برای «آماده‌ی محیط عملیاتی» وجود ندارد، اما فهرست‌های ارزیابی‌ای که تیم‌های زیرساخت به کار می‌برند به پرسش‌های یکسانی می‌رسند. این‌جا آن‌ها را با وضعیت سلام تا آبان ۱۴۰۵ (نوامبر ۲۰۲۶) می‌بینید. «برآورده» یعنی شاهدش هست؛ «تا حدی» یعنی بخشی از آن هست؛ «هنوز نه» یعنی نیست.

بند	وضعیت سلام	شاهد به‌اختصار
پایداری زبان و سیاست سازگاری	هنوز نه	نسخه‌ی ۰٫۶، نحو هنوز تغییر می‌کند، تعهد مکتوبی نیست
نسخه‌گذاری و روند انتشار	تا حدی	انتشارهای برچسب‌خورده‌ی پرشمار، چکیده‌ها، دروازه‌ی انتشار؛ LTS ندارد
پشتیبانی سکوها	تا حدی	هدف‌های بسیار؛ ساخت‌های ۳۲ بیتی و متقابل بدون تضمین
ابزارهای برنامه‌نویسی	بیشتر برآورده	LSP، قالب‌بند، آزمون، خطایاب، memcheck؛ نیم‌رخ‌گیر برنامه ندارد
تضمین کیفیت کامپایلر	برای سنش برآورده	خودمیزبان، هزاران آزمون، فازینگ تفاضلی
روند امنیتی	هنوز نه	`SECURITY.md` ندارد، ممیزی ندارد، سابقه‌ی اطلاعیه‌ی امنیتی ندارد
ایمنی حافظه	تا حدی	بررسی مرزها و هشدارها؛ بررسی‌کننده‌ی قرض ندارد
شواهد کارایی	برآورده	سنجه‌ی منتشرشده با داده‌ی خام و قید و شرط‌ها
زیست‌بوم و کتابخانه‌ها	تا حدی	کتابخانه‌ی استاندارد بزرگ؛ فهرست بسته‌های شخص ثالث خالی
مستندات	بیشتر برآورده	دوره، مرجع کتابخانه، اسناد طراحی؛ کتاب‌ها قدیمی
حاکمیت و تداوم	هنوز نه	سند حاکمیت ندارد؛ کار در یک نفر متمرکز است
پشتیبانی	هنوز نه	فقط گفت‌وگوی جامعه؛ پشتیبانی تجاری ندارد
پروانه	مشروط	GPL-3.0 در همه‌جا، بدون استثنای زمان اجرا

بخش‌های بعدی شاهد هر ردیف را می‌آورند.

پایداری و سازگاری

این مهم‌ترین بند است و همان بندی که سلام امروز آشکارتر از همه در آن ناکام است. خط انتشار کنونی ۰٫۶ است و زبان هنوز میان انتشارها به شکل‌هایی تغییر می‌کند که کد را می‌شکند. اعلان متغیر محلی با گونه‌ی صریح (x: int = 5) در سال ۲۰۲۶ به نفع x := 5 حذف شد. شکل pattern => expr برای بازوهای match در نسخه‌ی ۰٫۵٫۰ همراه با توکن => حذف شد. در ۰٫۶٫۳، خودانتسابی‌هایی مانند x = x + 1 به خطای کامپایل E162 تبدیل شدند (برای افزودن یک واحد x++ و برای مقدارهای دیگر x += n بنویسید). هر تغییر دلیلی دارد و پیام خطای روشنی، اما تیمی با ۱۰۰ هزار خط کد سلام هنگام ارتقا باید به کدش دست بزند.

هیچ سیاست سازگاری مکتوبی، هیچ شاخه‌ی پشتیبانی بلندمدت و هیچ تاریخ اعلام‌شده‌ای برای نسخه‌ی ۱٫۰ وجود ندارد. آنچه هست قطعه‌های سازنده‌ی خوبی برای چنین سیاستی است. می‌توان تابعی را بی‌کاره (deprecated) علامت زد؛ هر فراخوان آن هشدار W013 می‌گیرد و نام قدیمی همچنان کار می‌کند:

سلام

همگانی تابع جمع کل(قیمت‌ها: صحیح[]): صحیح:
    ناپایا جمع := ۰
    هر ق در قیمت‌ها:
        جمع += ق
    پایان
    برگشت جمع
پایان

همگانی بی‌کاره تابع جمع قیمت(قیمت‌ها: صحیح[]): صحیح:
    برگشت جمع کل(قیمت‌ها)
پایان

تابع ریشه:
    سرچاپ جمع کل([۱۲۰، ۸۰، ۴۵])
    سرچاپ جمع قیمت([۱۰، ۲۰])
پایان

خروجی245 30

کامپایلر هشدار را چاپ می‌کند و برنامه همچنان ساخته و اجرا می‌شود:

متن

هشدار[هشدار۰۱۳]: فراخوانی تابع بی‌کاره 'جمع قیمت'
 --> dep.salam:15:11
   |
15 |     سرچاپ جمع قیمت([۱۰، ۲۰])
   |           ^

بسته‌ها هم می‌توانند قدیمی‌ترین کامپایلری را که پشتیبانی می‌کنند در salam.toml اعلام کنند (salam = ">=0.6.1") و فرمان‌های بسته روی کامپایلر قدیمی‌تر با پیامی روشن متوقف می‌شوند. سیاستی که این ابزارها را ترکیب کند («هر چیز پیش از حذف دست‌کم N انتشار بی‌کاره بماند») ارزشمندترین گام تکی به سوی استفاده در محیط عملیاتی خواهد بود.

نسخه‌گذاری و روند انتشار

سازوکار انتشار از آنچه شماره‌ی نسخه نشان می‌دهد پخته‌تر است. از v0.3.0 در ۱۵ اوت ۲۰۲۶ تا v0.6.3 در ۱۱ نوامبر ۲۰۲۶ پروژه ۳۳ انتشار برچسب زده، به‌علاوه‌ی ساخت‌های شبانه‌ای که یک زمان‌بندی روزانه راهشان می‌اندازد. روند کار انتشار:

از به کار بردن دوباره‌ی شماره‌ی نسخه‌ای که انتشار منتشرشده دارد خودداری می‌کند، چون برچسب‌های انتشار تغییرناپذیر به حساب می‌آیند؛
می‌تواند کل مجموعه‌ی آزمون را به‌عنوان دروازه‌ی انتشار اجرا کند، با نمونه‌های زنده‌ی MySQL، PostgreSQL، Redis، Elasticsearch و OpenSearch برای بسته‌های پایگاه داده؛
کنار هر فایل یک پرونده‌ی .sha256 و یک پرونده‌ی SHA256SUMS برای همه‌ی آن‌ها منتشر می‌کند و فهرست را پیش از بارگذاری راستی‌آزمایی می‌کند؛
وقتی کلید امضا پیکربندی شده باشد، یک برچسب گیت امضاشده و توضیح‌دار می‌سازد؛
ساخت‌های تکرارپذیر کامپایلر را از راه SOURCE_DATE_EPOCH پشتیبانی می‌کند، همان‌طور که در راهنمای بسته‌بندی آمده است.

یادداشت‌های انتشار از درخواست‌های ادغام‌شده ساخته می‌شوند؛ پرونده‌ی CHANGELOG دست‌نویسی در ریشه‌ی مخزن نیست. ضعف این‌جا در آهنگ انتشار است، نه در دقت: ۳۳ انتشار در کمتر از سه ماه تکرار سریع است و سازمان‌ها معمولاً یک خط کندتر و پشتیبانی‌شده را کنار آن می‌خواهند. هیچ انتشار پشتیبانی بلندمدتی نیست و هیچ صورت‌حساب مواد نرم‌افزاری (SBOM) همراه انتشارها منتشر نمی‌شود.

سکوها، ابزارها و تضمین کیفیت

سکوها. ساخت‌های انتشار لینوکس روی x86-64، ARM64، ARMv7 و x86 سی‌ودو بیتی، مک روی تراشه‌های اپل، ویندوز روی x64، x86 و ARM64، به‌علاوه‌ی وب‌اسمبلی، جاوااسکریپت و اندروید را پوشش می‌دهند. نصب‌کننده‌ها BSDها و معماری‌های دیگر را هم می‌پذیرند. قید صادقانه در docs/PLATFORMS.md و روند کار انتشار آمده است: کارهای ساخت ۳۲ بیتی و متقابل با continue-on-error علامت خورده‌اند؛ پس انتشاری ممکن است بدون آن‌ها عرضه شود. هیچ سیاست رسمی رده‌بندی پشتیبانی نیست که بگوید کدام هدف‌ها تضمین‌شده‌اند. نوشته‌ی کامپایل متقابل با سلام جزئیات را دارد.

ابزارها. فرمان واحد salam یک سرور زبان (LSP)، یک قالب‌بند، یک اجراکننده‌ی آزمون، یک تولیدکننده‌ی مستندات، یک راه‌انداز خطایاب برای GDB و LLDB، یک بررسی‌کننده‌ی حافظه بر پایه‌ی AddressSanitizer، یک محیط تعاملی (REPL) و افزونه‌هایی برای یازده ویرایشگر را در خود دارد. یک کمبود: docs/PROFILING.md یک نیم‌رخ‌گیر (Profiler) برنامه (salam prof) را طراحی‌شده اما پیاده‌نشده توصیف می‌کند؛ پس نیم‌رخ‌گیری یک برنامه‌ی سلام یعنی استفاده از ابزارهای عمومی کد بومی. نوشته‌ی ابزارهای برنامه‌نویسی سلام این مجموعه را پوشش می‌دهد.

تضمین کیفیت. این‌جا سلام برای یک زبان جوان خوب عمل می‌کند. کامپایلر خودمیزبان است؛ پس هر انتشار خود کامپایلر را کامپایل می‌کند، که بیشتر زبان را به کار می‌گیرد. درخت tests/ حدود ۷ هزار پرونده‌ی سلام، شامل برنامه‌های آزمون و کمک‌کارهایشان، به انگلیسی و فارسی دارد. یک فازر تفاضلی برنامه‌های تصادفی می‌سازد و خروجی پشتوانه‌ی بومی را با خروجی پشتوانه‌ی C یا LLVM مقایسه می‌کند، و یک کار CI کامپایلر را با AddressSanitizer می‌سازد و آن را با بودجه‌ای برای نشت حافظه می‌سنجد که قرار است فقط پایین بیاید. پویش CodeQL روی درخواست‌های ادغام اجرا می‌شود.

امنیت و ایمنی حافظه

روند. این کمبودی آشکار است. مخزن هیچ SECURITY.md یا روند منتشرشده‌ی دیگری برای گزارش خصوصی آسیب‌پذیری‌ها ندارد، هیچ سابقه‌ای از اطلاعیه‌های امنیتی ندارد و هیچ ممیزی مستقلی روی کامپایلر یا بسته‌های حساس از نظر امنیتی انجام نشده است. پروژه بخشی از کار بازبینی را آشکارا انجام داده است: یک بازبینی امنیتی مکتوب از بسته‌های VPN و پراکسی‌اش، که خودش می‌گوید «یک بازبین است که کد را می‌خواند و تجزیه‌گرها را فاز می‌کند؛ ممیزی نیست». پیاده‌سازی TLS 1.3 و 1.2 در کتابخانه‌ی استاندارد به OpenSSL نیاز ندارد؛ این یک وابستگی را حذف می‌کند، اما یعنی درستی آن به بازبینی خود این پروژه وابسته است.

ایمنی حافظه. سلام نه زباله‌روب دارد و نه بررسی‌کننده‌ی قرض (Borrow Checker). دسترسی به آرایه‌ها و وکتورها در ساخت‌های معمولی با بررسی مرز انجام می‌شود، کامپایلر درباره‌ی اشتباه‌های مالکیت هشدار می‌دهد و salam memcheck برنامه را زیر AddressSanitizer اجرا می‌کند. دو قید باید در هر ارزیابی خطر بیاید: آزاد کردن حافظه‌ی هیپ کار برنامه‌نویس است، و ساخت --release بررسی مرزها را برای سرعت حذف می‌کند. برای کدی که ورودی خصمانه را تجزیه می‌کند، تضمین‌های زمان کامپایل Rust محکم‌ترند؛ نوشته‌ی مقایسه‌ی سلام و Rust این دو را منصفانه مقایسه می‌کند.

مدیریت خطا صریح است، که به ممیزی کمک می‌کند. تابع‌هایی که ممکن است شکست بخورند خطادار (throws) علامت می‌خورند و فراخوان باید خطا را مدیریت یا به بالا منتقل کند:

سلام

واردسازی تبدیل

تابع خواندن درگاه(متن: رشته): صحیح خطادار:
    درگاه := تلاش تبدیل.رشته به عدد(متن)
    اگر درگاه < ۱ یا درگاه > ۶۵۵۳۵:
        پرتاب خطا خطا { پیام = «درگاه خارج از بازه است: » + متن }
    پایان
    برگشت درگاه
پایان

تابع ریشه:
    هر متن در [«8080»، «http»، «70000»]:
        تلاش:
            سرچاپ «گوش دادن روی درگاه»، خواندن درگاه(متن)
        گرفتن خطا خ:
            سرچاپ «خطای پیکربندی:»، خ.به رشته()
        پایان
    پایان
پایان

خروجیگوش دادن روی درگاه 8080 خطای پیکربندی: conv: invalid character 'h' (line 1, column 1) خطای پیکربندی: درگاه خارج از بازه است: 70000

متن خطای دوم را بسته‌ی تبدیل (conv) ساخته و، چنان‌که خروجی نشان می‌دهد، حتی در برنامه‌ی فارسی به انگلیسی چاپ می‌شود.

شواهد کارایی

سلام همان نوع شواهد کارایی را منتشر می‌کند که یک تیم ارزیابی باید بخواهد: برنامه‌ها، روش، همه‌ی عددها و زمان خام هر اجرا. روی ۳۹ برنامه که در همه‌ی زبان‌ها الگوریتم یکسانی دارند، در سنجش ۲۷ اکتبر ۲۰۲۶ (۵ آبان ۱۴۰۵)، میانگین سلام ۱۰٫۶ میلی‌ثانیه، C ۱۱٫۷ میلی‌ثانیه و Rust ۱۱٫۳ میلی‌ثانیه بود؛ در برابر سریع‌ترینِ C، C++، Rust و Go در هر برنامه، سلام در ۶ برنامه جلوتر، در ۲۷ برنامه برابر و در ۶ برنامه عقب‌تر بود. صفحه‌ی سرعت محدودیت‌ها را صریح می‌گوید: برنامه‌های کوتاهی که زمان راه‌اندازی در آن‌ها به حساب می‌آید، یک ماشین مجازی اشتراکی CI، و فاصله‌های زیر حدود ۵ درصد که میان اجراها جابه‌جا می‌شوند. جمع‌بندی منصفانه برای این نوع کد «در رده‌ی C و Rust» است. این سنجه برنامه‌های بزرگ، بارهای کاری پرمصرف از نظر حافظه یا زمان ساخت را پوشش نمی‌دهد؛ پس یک تیم همچنان باید سرویس خودش را بسنجد.

زیست‌بوم، مستندات، آدم‌ها و پشتیبانی

زیست‌بوم. کتابخانه‌ی استاندارد بزرگ است، بیش از ۱۷۰ بسته‌ی مستند از HTTP و gRPC تا راه‌اندازهای پایگاه داده، فشرده‌سازی و رمزنگاری، که بیشتر نیازها را بدون کد شخص ثالث پوشش می‌دهد. مدیر بسته خوب طراحی شده است (ماژول‌های مبتنی بر گیت، فایل قفل، چکیده‌ها، فهرست بازبینی‌شده‌ی چکیده‌ها). اما فهرست بسته‌ها هنوز هیچ بسته‌ی شخص ثالثی ندارد و فهرست چکیده‌ها خالی است. نوشته‌ی زیست‌بوم متن‌باز سلام به این می‌پردازد.

مستندات. یک دوره‌ی ۴۷ درسی به انگلیسی و فارسی، یک صفحه‌ی مرجع برای هر بسته‌ی کتابخانه‌ی استاندارد با مثال‌های کامپایل‌شده، و اسناد طراحی در docs/. برخی اسناد از کد عقب‌اند: خود پروژه کتاب‌های LaTeX را قدیمی اعلام کرده و برخی یادداشت‌های طراحی هنوز به پیاده‌سازی C ای اشاره می‌کنند که در اوت ۲۰۲۶ کنار گذاشته شد.

حاکمیت و تداوم. یک آیین‌نامه‌ی رفتاری و یک پرونده‌ی CODEOWNERS هست که بازبینی را به تیم نگهدارندگان می‌سپارد، اما سندی برای حاکمیت پروژه نیست که بگوید تصمیم‌ها چطور گرفته می‌شوند یا نگهداری پروژه چطور دست‌به‌دست می‌شود. در سال ۲۰۲۶ حدود دو سوم کامیت‌های شاخه‌ی اصلی از طراح زبان بوده است. برای یک خریدار، این تمرکز مهم‌ترین خطر غیرفنی است.

پشتیبانی. کمک از کانال‌های جامعه (issueهای گیت‌هاب، تلگرام، دیسکورد، ایتا و بله) و دستیار هوشمند سلام می‌آید. هیچ پشتیبانی تجاری، هیچ توافق‌نامه‌ی سطح خدمت (SLA) و هیچ شرکتی پشت پروژه نیست.

پروانه: GPL-3.0 بدون استثنای زمان اجرا

کامپایلر، کتابخانه‌ی استاندارد و ابزارها زیر پروانه‌ی GNU GPL نسخه‌ی ۳ منتشر شده‌اند. پوشه‌ی افزونه‌ی Visual Studio Code با پروانه‌ی MIT است تا دستور زبانش قابل استفاده‌ی دوباره باشد. جزئیات مهم برای کسب‌وکارها این است که هیچ استثنای کتابخانه‌ی زمان اجرا وجود ندارد، از نوعی که «استثنای کتابخانه‌ی زمان اجرای GCC» برای کدی که با کتابخانه‌های خود GCC پیوند می‌خورد فراهم می‌کند. readme کد سلامی را که کتابخانه‌ی استاندارد را وارد می‌کند، پس از ساخته شدن، مشتق از GPL توصیف می‌کند.

معنای عملی این به شیوه‌ی توزیع بستگی دارد. ابزارهای داخلی و نرم‌افزاری که فقط به‌عنوان سرویس شبکه اجرا می‌کنید در GPL-3.0 وضع دیگری دارند، چون این پروانه برخلاف AGPL استفاده از راه شبکه را توزیع به حساب نمی‌آورد. توزیع فایل اجرایی به مشتریان تعهدات GPL درباره‌ی در دسترس گذاشتن کد منبع را به همراه دارد. این انتخابی مشروع برای یک پروژه‌ی نرم‌افزار آزاد است و برای بسیاری از محصولات انحصاری عامل تعیین‌کننده. پیش از تکیه بر هر برداشتی از آن، از جمله همین برداشت، از یک حقوق‌دان بپرسید.

نتیجه، و آنچه آن را تغییر می‌دهد

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

خبر خوب برای کسی که پروژه را دنبال می‌کند این است که بیشتر این کمبودها سیاست‌اند، نه کد: یک SECURITY.md با نشانی‌ای برای افشای مسئولانه، یک سیاست مکتوب برای بی‌کاره‌سازی و سازگاری، یک سند حاکمیت، یک خط انتشار پشتیبانی‌شده، و بیانیه‌ای روشن درباره‌ی استثناهای پیوند. نوشته‌ی سلام در صنعت توضیح می‌دهد که تا آن زمان چطور سلام را با خیال راحت آزمایش کنید، و سلام در پنج تا ده سال آینده به مسیر بلندتر تا نسخه‌ی ۱٫۰ نگاه می‌کند.

پرسش‌های متداول درباره‌ی آمادگی زبان سلام برای محیط عملیاتی

آیا زبان سلام برای محیط عملیاتی آماده است؟

برای بیشتر کاربردهای سازمانی هنوز نه. کیفیت کامپایلر، ابزارها و شواهد کارایی‌اش برای یک زبان جوان قوی است، اما پیش از نسخه‌ی ۱٫۰ است و نحوش تغییر می‌کند، روند امنیتی منتشرشده و پشتیبانی بلندمدت ندارد، و پروانه‌اش GPL-3.0 بدون استثنای زمان اجراست.

آمادگی یک زبان برنامه‌نویسی برای محیط عملیاتی یعنی چه؟

یعنی کسب‌وکار بتواند سال‌ها به زبان تکیه کند: نحو و کتابخانه‌های پایدار در طول ارتقاها، انتشارهای قابل‌اعتماد، روندی برای پاسخ به مشکلات امنیتی، ابزارهای خوب، پوشش سکوها، برنامه‌نویس و پشتیبانی در دسترس، و پروانه‌ای که با محصول جور باشد.

آیا سلام نسخه‌ی پایدار دارد؟

انتشارهای برچسب‌خورده با چکیده‌ی رمزنگاشتی دارد که تازه‌ترینشان در خط ۰٫۶ است، به‌علاوه‌ی ساخت‌های شبانه. هیچ‌کدام تضمین سازگاری یا پشتیبانی بلندمدت ندارند و تغییرهای ناسازگار هنوز میان نسخه‌های فرعی رخ می‌دهند.

آیا می‌توانم نرم‌افزار بسته (غیرمتن‌باز) را با سلام بنویسم و توزیع کنم؟

کتابخانه‌ی استاندارد GPL-3.0 است و استثنای پیوند ندارد، و پروژه برنامه‌هایی را که از آن استفاده می‌کنند مشتق از GPL می‌داند. توزیع فایل‌های اجرایی بسته با این در تعارض است؛ پس پیش از شروع، پرسش را با مشاور حقوقی در میان بگذارید.