سلام در صنعت کجا جا می‌گیرد: سرویس‌های وب، زیرساخت ابری، نرم‌افزارهای سازمانی و نرم‌افزار سیستمی

زبان برنامه‌نویسی سلام می‌تواند در صنعت هر جا به کار بیاید که تیمی کارایی بومی، استقرار با یک فایل اجرایی و کتابخانه‌ی استاندارد داخلی بزرگ بخواهد: سرویس‌های HTTP و gRPC، ابزارهای خط فرمان و زیرساخت، کارهای پردازش داده، و نرم‌افزارهای اداری، به‌ویژه برای سازمان‌های فارسی‌زبان. کاربرد صنعتی یک زبان برنامه‌نویسی یعنی اجرای آن در نرم‌افزاری که کسب‌وکاری به آن وابسته است، با همه‌ی لوازمش: پایداری، پشتیبانی، استخدام و پروانه‌ی استفاده. با این تعریف، سلام امروز یک نامزد است، نه زبانی جاافتاده. پروژه هیچ مطالعه‌ی موردی یا فهرستی از کاربران در محیط عملیاتی منتشر نکرده است؛ پس این نوشته درباره‌ی تناسب فنی و شرط‌های پذیرش است، نه درباره‌ی اینکه چه کسی همین حالا از آن استفاده می‌کند.

صنعت واقعاً از یک زبان برنامه‌نویسی چه می‌خواهد؟

مدیران فنی به‌ندرت زبانی را به خاطر نحوش انتخاب می‌کنند. پرسش‌هایی که پذیرش را تعیین می‌کنند معمولی‌ترند:

1. کار را سریع و قابل‌پیش‌بینی انجام می‌دهد؟ توان عملیاتی، تأخیر، مصرف حافظه، زمان راه‌اندازی.
2. می‌توانیم مستقر و اداره‌اش کنیم؟ خروجی ساخت، کانتینرها، کامپایل متقابل، مشاهده‌پذیری.
3. می‌توانیم برایش نیرو استخدام یا تربیت کنیم؟ بازار نیروی کار، منحنی یادگیری، مستندات.
4. پنج سال دیگر هنوز هست، و هنوز سازگار است؟ سیاست پایداری، نگهدارندگان، روند انتشار.
5. می‌توانیم از نظر حقوقی در محصولمان از آن استفاده کنیم؟ شرایط پروانه‌ی کامپایلر، زمان اجرا و کتابخانه‌ی استاندارد.
6. وقتی خراب شد چه کسی کمک می‌کند؟ کانال‌های پشتیبانی، پاسخ به مشکلات امنیتی، گزینه‌های تجاری.

سلام به دو پرسش نخست خوب پاسخ می‌دهد، به سومی و چهارمی ضعیف، و به پنجمی با شرطی که هر شرکتی باید بررسی کند. باقی این نوشته هر حوزه را با همین پرسش‌ها در ذهن بررسی می‌کند؛ نوشته‌ی همراه، یک زبان برنامه‌نویسی چه وقت برای محیط عملیاتی آماده است؟، یک فهرست بررسی کامل را اجرا می‌کند.

سرویس‌های وب و API با زبان سلام

این طبیعی‌ترین تناسب صنعتی است. کتابخانه‌ی استاندارد یک سرور HTTP با مسیریاب و میان‌افزار، HTTP/2، WebSocket، gRPC، GraphQL، TLS 1.3 و 1.2 بدون وابستگی به OpenSSL، نشست‌ها، اعتبارسنجی و تولید Swagger دارد. یک سرویس کوچک موجودی انبار این شکل را دارد:

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

ناپایا انبار := وکتور {} برگردان وکتور<کالا>

ساختار کالا:
    @جیسون "sku"
    همگانی کد کالا: رشته = ""
    @جیسون "count"
    همگانی موجودی: صحیح = ۰
پایان

تابع سلامت(زمینه: صحیح۶۴):
    اچ تی تی پی.جیسون(زمینه، `{"status":"ok"}`)
پایان

تابع موجودی کالا(زمینه: صحیح۶۴):
    کد := اچ تی تی پی.پارامتر(زمینه، «sku»)
    هر ک در انبار:
        اگر ک.کد کالا == کد:
            اچ تی تی پی.جیسون(زمینه، جیسون.سریال سازی(ک))
            برگشت
        پایان
    پایان
    اچ تی تی پی.تنظیم وضعیت(زمینه، ۴۰۴)
    اچ تی تی پی.جیسون(زمینه، `{"error":"unknown sku"}`)
پایان

تابع ریشه:
    انبار.بیفزا(کالا { کد کالا = «RACK-42U»، موجودی = ۷ })
    انبار.بیفزا(کالا { کد کالا = «CABLE-CAT6»، موجودی = ۳۱۰ })
    ناپایا مسیرها := مسیریاب.مسیریاب جدید()
    مسیریاب.دریافت(مسیرها، «/healthz»، سلامت)
    مسیریاب.دریافت(مسیرها، «/stock/:sku»، موجودی کالا)
    درگاه := محیط.دریافت با پیش فرض(«PORT»، «8080»)
    ناپایا سرور := اچ تی تی پی.سرور جدید(درگاه.به صحیح())
    اچ تی تی پی.استفاده(سرور، مسیرها)
    اچ تی تی پی.اجرا(سرور)
پایان

پروژه پشته‌ی HTTP خود را با هشت سرور دیگر روی یازده مسیر سنجیده است. در آن اجرا، net.http سلام با میانگین هندسی ۹۴٬۸۵۰ درخواست در ثانیه پاسخ داد، در برابر ۶۲٬۴۹۳ برای چارچوب Fiber در Go و ۳۴٬۹۸۷ برای کتابخانه‌ی استاندارد Go. قید و شرط‌ها به اندازه‌ی خود عددها مهم‌اند: محیط سنجش یک ماشین اشتراکی ۶ هسته‌ای مجازی با بار نامرتبط بود، برتری بر Fiber روی ماشین آرام ۱۶ درصد و زیر آن بار ۵۲ درصد بود، و روی مسیر / برتری فقط ۴ درصد بود. صفحه‌ی سرعت جدول کامل و ابزار سنجش را منتشر کرده است. این را شاهدی بدانید که پشته‌ی HTTP در رده‌ی سرورهای کامپایلی سریع است، نه تضمینی برای بار کاری شما. نوشته‌ی ساخت وب‌سرورهای سریع با سلام عمیق‌تر به این موضوع می‌پردازد.

برای عملیات، salam serve --config یک وب‌سرور چندسایتی را از روی یک پرونده‌ی پیکربندی با میزبان‌های مجازی، تغییر مسیرها و پشتوانه‌های FastCGI مانند php-fpm اجرا می‌کند، و همان برنامه‌ی net.http را می‌توان برای wasm32-wasi ساخت و روی Cloudflare Workers مستقر کرد.

زیرساخت ابری و ابزارهای DevOps

تیم‌های زیرساخت به خروجی ساخت اهمیت می‌دهند. برنامه‌ی سلام به یک فایل اجرایی بومی، بدون ماشین مجازی و بدون زباله‌روب، تبدیل می‌شود؛ پس تصویر کانتینر می‌تواند تقریباً فقط همان فایل باشد. روی لینوکس x86-64، پیونددهنده‌ی داخلی پشتوانه‌ی بومی یک فایل اجرایی ایستا با musl می‌سازد. کامپایل متقابل یک گزینه است: --target=x86_64-w64-windows-gnu یا یک سه‌تایی ARM از روی همان دستگاه برای سکوی دیگری می‌سازد، همان‌طور که نوشته‌ی کامپایل متقابل با سلام نشان می‌دهد. خود کامپایلر هم به شکل تصویر داکر (basemax/salam) برای x86-64، ARM64، ARMv7 و i386 عرضه می‌شود.

ابزارهایی که با این مشخصات جور درمی‌آیند همان‌هایی‌اند که Go با آن‌ها محبوب شد: عامل‌ها (agent)، ابزارهای خط فرمان، پراکسی‌های کوچک، صادرکننده‌های سنجه، ابزارهای کمکی استقرار. کتابخانه‌ی استاندارد بخش بزرگی از نیازهایشان را پوشش می‌دهد: فرایندها و پوسته‌ها، بسته‌ای برای شبه‌پایانه، SSH، TLS، DNS، NATS، زمان‌بندی‌های cron و کلاینت‌های Redis، ClickHouse، Elasticsearch و OpenSearch.

آنچه برای کار ابری کم است زیست‌بوم اطراف است، نه خود زبان. هیچ SDK رسمی از ارائه‌دهندگان ابر وجود ندارد (کتابخانه‌ی استاندارد یک بسته‌ی aws برای S3، SQS و STS و یک بسته‌ی google برای احراز هویت حساب سرویس دارد، که از گستره‌ی SDKهای رسمی Go یا پایتون بسیار دور است)، کتابخانه‌ی OpenTelemetry نیست و کلاینت Kubernetes هم نیست. تیم‌ها باید این یکپارچه‌سازی‌ها را خودشان بنویسند یا APIهای REST ارائه‌دهندگان را از راه HTTP فراخوانی کنند.

نرم‌افزارهای اداری سازمانی و کسب‌وکارهای ایرانی

نرم‌افزارهای کسب‌وکار بیشتر این‌اند: داده وارد می‌شود، قاعده‌ها اعمال می‌شوند، داده بیرون می‌رود. سلام راه‌اندازهای SQLite، PostgreSQL، MySQL و ClickHouse را دارد، فرمان salam sql check که رشته‌های SQL را بدون پایگاه داده اعتبارسنجی می‌کند، و salam sql generate که پرس‌وجوهای برچسب‌خورده را به تابع‌های گونه‌دار سلام تبدیل می‌کند (نوشته‌ی SQL گونه‌دار هر دو را پوشش می‌دهد). برای پول یک بسته‌ی دقیق decimal هست و برای تاریخ یک بسته‌ی تقویم با تقویم‌های جلالی، قمری و میلادی و منطقه‌های زمانی.

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

واردسازی اعشاری
واردسازی تقویم

ساختار ردیف:
    همگانی شرح: رشته
    همگانی بها: رشته
    همگانی تعداد: صحیح
پایان

تابع مبلغ(متن: رشته): اعشاری.اعشاری:
    ناپایا موفق := نادرست
    برگشت اعشاری.تجزیه(متن، موفق)
پایان

تابع ریشه:
    ردیف‌ها := [
        ردیف { شرح = «رک سرور»، بها = «1250.00»، تعداد = ۲ }،
        ردیف { شرح = «ساعت پشتیبانی»، بها = «45.50»، تعداد = ۱۲ }،
        ردیف { شرح = «بسته‌ی کابل»، بها = «19.99»، تعداد = ۳ }،
    ]
    ناپایا جمع جزء := اعشاری.از صحیح(۰)
    هر ر در ردیف‌ها:
        هزینه := اعشاری.ضرب صحیح(مبلغ(ر.بها)، ر.تعداد برگردان صحیح۶۴)
        سرچاپ ر.شرح، «x»، ر.تعداد، «=»، اعشاری.به رشته ثابت(هزینه، ۲)
        جمع جزء = اعشاری.جمع(جمع جزء، هزینه)
    پایان
    مالیات := اعشاری.گردکردن نیم بالا(اعشاری.درصد(جمع جزء، مبلغ(«9»)، ۴)، ۲)
    سرچاپ «جمع جزء:»، اعشاری.قالب گروهی(جمع جزء، ۲، «,»، «.»)
    سرچاپ «مالیات ۹٪:»، اعشاری.قالب گروهی(مالیات، ۲، «,»، «.»)
    سرچاپ «جمع کل:»، اعشاری.قالب گروهی(اعشاری.جمع(جمع جزء، مالیات)، ۲، «,»، «.»)
    صدور := تقویم.میلادی به جلالی(تقویم.تاریخ میلادی { سال = ۲۰۲۶، ماه = ۱۱، روز = ۱۱ })
    سررسید := تقویم.افزودن روز جلالی(صدور، ۳۰)
    سرچاپ «صدور»، تقویم.قالب جلالی(صدور)، «سررسید»، تقویم.قالب جلالی(سررسید)، تقویم.نام ماه جلالی(سررسید.ماه)
پایان

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

وزنه‌ی مقابل این است که نرم‌افزار سازمانی ده‌ها سال عمر می‌کند و بارها دست‌به‌دست می‌شود. زبانی پیش از نسخه‌ی ۱٫۰ با بازار کار کوچک، در این حوزه سخت‌تر از هر جای دیگری پذیرفته می‌شود.

نرم‌افزار سیستمی و تعبیه در سامانه‌های موجود

در پایین‌ترین سطح، سلام به جاهایی می‌رسد که بیشتر زبان‌های جوان نمی‌رسند. می‌تواند فایل‌های اجرایی مستقل (freestanding) بدون سیستم‌عامل بسازد و مخزن یک هسته‌ی آزمایشی کوچک دارد که زیر QEMU بالا می‌آید (نوشته‌ی سلام روی سخت‌افزار خام را ببینید). سلام تابع‌های C را از راه بلوک‌های درون‌داد (extern) فراخوانی می‌کند؛ پس کتابخانه‌های C موجود بدون بازنویسی قابل استفاده‌اند.

برای صنعت، ویژگی کاربردی‌تر در جهت عکس کار می‌کند. salam build --lib یک کتابخانه‌ی اشتراکی یا ایستا به‌علاوه‌ی یک سرآیند C برای تابع‌هایی که در بلوک برون‌داد (export) آمده‌اند می‌سازد. یعنی تیم می‌تواند یک جزء را با سلام بنویسد، مثلاً یک تجزیه‌گر، یک موتور قیمت‌گذاری یا یک پردازنده‌ی پروتکل، و آن را از راه ABI زبان C به یک سامانه‌ی موجود C، C++، Go یا Rust پیوند دهد. معرفی یک زبان تازه به شکل کتابخانه‌ای پشت یک رابط C بسیار کم‌خطرتر از بازنویسی یک سرویس است، و راهی است که بیشتر سازمان‌ها باید یک زبان ناآشنا را با آن بیازمایند.

موانع پذیرش زبان سلام در صنعت، بی‌پرده

ارزیابی منصفانه باید این‌ها را کنار نقاط قوت بگذارد.

• پروانه. کامپایلر، کتابخانه‌ی استاندارد و ابزارها با GPL-3.0 منتشر شده‌اند. readme پروژه کد سلامی را که کتابخانه‌ی استاندارد را وارد می‌کند، پس از ساخته شدن، مشتق از GPL می‌داند، و پرونده‌ی پروانه هیچ استثنای کتابخانه‌ی زمان اجرا از نوعی که کتابخانه‌های زمان اجرای GCC دارند ندارد. بنابراین شرکت‌هایی که فایل اجرایی را به مشتریان توزیع می‌کنند تعهدات GPL-3.0 را می‌پذیرند. نرم‌افزاری که فقط درون سازمان اجرا می‌شود، یا فقط از راه شبکه سرویس می‌دهد، در GPL-3.0 وضع دیگری دارد، چون این پروانه برخلاف AGPL استفاده از راه شبکه را توزیع به حساب نمی‌آورد. این مهم‌ترین پرسش برای واحد حقوقی است و پاسخش را باید آن‌ها بدهند، نه یک وبلاگ.
• پایداری. سلام در نسخه‌ی ۰٫۶ است و نحوش هنوز میان انتشارها تغییر می‌کند. اعلان متغیر محلی با گونه‌ی صریح در سال ۲۰۲۶ حذف شد و در نسخه‌ی ۰٫۶٫۳ خودانتسابی‌هایی مانند x = x + 1 خطای کامپایل شدند. هنوز نه انتشاری با پشتیبانی بلندمدت (LTS) وجود دارد و نه تعهد مکتوبی برای سازگاری.
• تمرکز. بیشتر کامیت‌ها از طراح زبان است. این برای یک زبان جوان عادی است و برای یک کسب‌وکار خطری واقعی برای تداوم.
• نیروی کار. عملاً هیچ بازار استخدامی برای برنامه‌نویسان سلام وجود ندارد. تیم‌ها باید نیروی خودشان را تربیت کنند، که نحو زبان آن را معقول می‌کند اما رایگان نه.
• پشتیبانی و روند امنیتی. هیچ پشتیبانی تجاری‌ای عرضه نمی‌شود و هیچ سیاست امنیتی منتشرشده‌ای (SECURITY.md) وجود ندارد که بگوید آسیب‌پذیری‌ها چطور گزارش و اصلاح می‌شوند.
• ایمنی حافظه. سلام بررسی مرزها، هشدارهای مالکیت و یک بررسی‌کننده‌ی حافظه دارد، اما بررسی‌کننده‌ی قرض (Borrow Checker) ندارد. برای کد سیستمی حساس از نظر امنیتی، Rust تضمین‌های محکم‌تری می‌دهد.

یک پروژه‌ی آزمایشی معقول چه شکلی دارد؟

برای سازمانی که این تناسب را جالب می‌بیند، مسیر کم‌خطر باریک و برگشت‌پذیر است:

1. یک جزء محدود انتخاب کنید: یک ابزار خط فرمان داخلی، یک کار دسته‌ای، یک API داخلی کوچک، یا کتابخانه‌ای پشت یک رابط C.
2. نسخه‌ی کامپایلر را ثابت کنید. یک انتشار مشخص را در CI نصب کنید (نصب‌کننده گزینه‌ی --version X.Y.Z را می‌پذیرد)، قدیمی‌ترین کامپایلر پشتیبانی‌شده را در salam.toml ثبت کنید (salam = ">=0.6.2") و آگاهانه ارتقا دهید.
3. پروانه را بازبینی حقوقی کنید، متناسب با مدل توزیعتان، پیش از نوشتن کد عملیاتی.
4. بار کاری خودتان را بسنجید. سنجه‌های منتشرشده برنامه‌های کوتاه و یک ابزار سنجش HTTP‌اند؛ سرویس شما هیچ‌کدام از این‌ها نیست.
5. راه خروج را برنامه‌ریزی کنید. رابط‌ها را مستقل از زبان نگه دارید (HTTP، gRPC، ABI زبان C) تا اگر آزمایش شکست خورد بتوان جزء را جایگزین کرد.

این کمتر از یک بازنویسی کامل هیجان دارد، و راهی است که زبان‌هایی مانند Go و Rust در واقع وارد بیشتر شرکت‌ها شدند: یک ابزار، یک سرویس، یک تیم در هر نوبت. نوشته‌ی آینده‌ی سلام بررسی می‌کند که خود پروژه برای هموارتر کردن این مسیر چه باید بکند.

پرسش‌های متداول درباره‌ی کاربرد صنعتی زبان سلام

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

پروژه هیچ مطالعه‌ی موردی یا فهرستی از کاربران در محیط عملیاتی منتشر نمی‌کند؛ پس شاهد عمومی‌ای برای نشان دادن وجود ندارد. سلام را زبانی برای آزمودن روی اجزای محدود بدانید، نه زبانی با سابقه‌ی اثبات‌شده در محیط عملیاتی.

آیا می‌توان با زبان سلام نرم‌افزار تجاری ساخت؟

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

آیا سلام برای ریزسرویس‌ها (Microservices) انتخاب خوبی است؟

از نظر فنی تناسب خوبی دارد: فایل‌های اجرایی بومی تکی، پشتیبانی سریع از HTTP و gRPC و راه‌اندازهای پایگاه داده‌های رایج. خطرها پایداری پیش از نسخه‌ی ۱٫۰، زیست‌بوم کوچک (بدون SDK ارائه‌دهندگان ابر یا کتابخانه‌ی OpenTelemetry) و بازار کار کوچک است.

آیا می‌توان کد سلام را از یک سامانه‌ی موجود C یا C++ فراخوانی کرد؟

بله. salam build --lib یک کتابخانه‌ی اشتراکی یا ایستا با سرآیند C برای تابع‌هایی که برون‌داد کرده‌اید می‌سازد؛ پس یک جزء سلام را می‌توان به C، C++ یا هر زبانی که میانجی تابع‌های بیگانه‌ی C دارد پیوند داد.