آیا یک زبان برنامه‌نویسی تازه می‌تواند با زبان‌های چنددهه‌ای رقابت کند؟ جایگاه سلام در اکوسیستم جهانی

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

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

نسل پیشین زبان‌ها چطور راه خود را باز کردند

زبان‌هایی که امروز غالب‌اند با نحو برنده نشدند. پشت هر کدام نیرویی بود که پذیرفتنش را از ماندن با ابزارهای قدیمی آسان‌تر می‌کرد.

سه الگو به چشم می‌آید. صاحب یک سکو می‌تواند زبانی را پیش‌فرض کند (Swift روی دستگاه‌های اپل، C# روی .NET، Kotlin روی اندروید). تعامل‌پذیری هزینه‌ی ترک دنیای قدیم را برمی‌دارد (TypeScript همه‌ی جاوااسکریپت را اجرا می‌کند، Kotlin همه‌ی جاوا را صدا می‌زند، Zig کد C را کامپایل می‌کند). و یک برتری فنی متمایز به پذیرندگان اولیه دلیلی برای پذیرفتن ریسک می‌دهد (تضمین‌های ایمنی Rust، استقرار ساده و هم‌زمانی Go). پایتون یادآوری می‌کند که این مسیر می‌تواند طولانی هم باشد: بیش از پانزده سال از عمرش گذشته بود که پشته‌ی علمی آن را به انتخاب پیش‌فرض تبدیل کرد.

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

اکوسیستم واقعاً چیست

وقتی می‌گویند زبانی «اکوسیستم ندارد»، منظورشان چند چیز متفاوت است و بهتر است از هم جدایشان کنیم:

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

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

زبان سلام امروز کجا ایستاده است

اگر سلام را با همین فهرست بسنجیم، جایگاهش در پایان ۲۰۲۶ این است، فقط با چیزهایی که در مخزن قابل بررسی‌اند.

کامپایلر. کامپایلر سلام با خود سلام نوشته شده و خودش را می‌سازد؛ پیاده‌سازی اولیه‌ی C در اوت ۲۰۲۶ کنار گذاشته شد. از راه C، از راه LLVM یا با پشتوانه‌ی بومی خودش کد تولید می‌کند و لینوکس، مک، ویندوز، WebAssembly، جاوااسکریپت و برنامه‌های مستقلِ بدون سیستم‌عامل (bare-metal) را هدف می‌گیرد. خودمیزبانی نقطه‌ی عطف معناداری است، چون یک کامپایلر تقریباً همه‌ی ویژگی‌های یک زبان را به کار می‌گیرد (درون کامپایلر خودمیزبان سلام را ببینید).

کتابخانه‌ها. این قوی‌ترین بخش است. بیش از ۱۷۰ بسته‌ی کتابخانه‌ی استاندارد همراه کامپایلر عرضه می‌شود، هر کدام با یک صفحه‌ی مرجع و نمونه‌های بررسی‌شده در مرجع کتابخانه: سرورهای HTTP با مسیریابی و میان‌افزار، WebSocket و gRPC، TLS نوشته‌شده با خود سلام، درایورهای PostgreSQL، MySQL، SQLite، Redis و ClickHouse، JSON، YAML، TOML، XML و CSV، فشرده‌سازی و بایگانی، رمزنگاری، تصویر و صدا، ماتریس، تانسور و لایه‌های شبکه‌ی عصبی. یک برنامه‌ی کوچک بدون حتی یک وابستگی می‌تواند کار واقعی انجام دهد:

واردسازی رمزنگاری
واردسازی کدگذاری.جیسون

ساختار انتشار:
    همگانی پرونده: رشته
    همگانی حجم: صحیح
    همگانی sha256: رشته
پایان

تابع ریشه:
    محتوا := "hello from a release file"
    ف := انتشار { پرونده = "notes.txt"، حجم = محتوا.طول()، sha256 = رمزنگاری.شا۲۵۶ شانزدهی(محتوا) }
    سرچاپ جیسون.سریال سازی(ف)
پایان

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

بسته‌های شخص ثالث. این ضعیف‌ترین بخش است. salam add بسته‌ها را از GitHub می‌گیرد، نسخه‌شان را در یک فایل قفل ثبت می‌کند و checksumها را وارسی می‌کند، و salam search یک مخزن عمومی را می‌خواند. این مخزن وجود دارد و برای pull request باز است، اما هنوز عملاً خالی است. هر بسته‌ای که برنامه‌های سلام امروز استفاده می‌کنند یا از کتابخانه‌ی استاندارد می‌آید، یا از خود پروژه، یا از C.

ابزارها. یک فایل اجرایی می‌سازد، اجرا می‌کند، آزمون می‌گیرد، قالب‌بندی می‌کند، گونه‌ها را بررسی می‌کند، میان انگلیسی و فارسی ترجمه می‌کند، صفحه‌ی وب می‌سازد، اشکال‌زدا را راه می‌اندازد و حافظه را بررسی می‌کند. یک سرور زبان (LSP) خطاها و تکمیل خودکار را به ویرایشگرها می‌رساند، و برای Visual Studio Code و ده ویرایشگر دیگر افزونه وجود دارد، به‌علاوه‌ی یک ویرایشگر آنلاین که کامپایلر را در مرورگر اجرا می‌کند.

دانش. یک دوره‌ی رایگان ۴۷ درسی به انگلیسی و فارسی با برنامه‌های کامل و خروجی واقعی، مرجع کتابخانه، و همین مجله. سایت همچنین یک فایل llms.txt و یک مرجع کامل زبان برای دستیارهای کدنویسی منتشر می‌کند، که هر سال اهمیت بیشتری پیدا می‌کند (زبان‌های برنامه‌نویسی در عصر هوش مصنوعی را ببینید).

کارایی. در سنجش پروژه روی ۳۹ برنامه‌ی هم‌الگوریتم، میانگین سلام ۱۰٫۶ میلی‌ثانیه بود در برابر ۱۱٫۷ میلی‌ثانیه‌ی C و ۱۱٫۳ میلی‌ثانیه‌ی Rust، که صفحه‌ی سرعت آن را «یک رده» می‌خواند، نه رتبه‌بندی: برنامه‌ها کوتاه‌اند، راه‌اندازی جزو هر زمان است و فاصله‌های کمتر از حدود ۵٪ نوسان به حساب می‌آیند. سلام در ۶ برنامه جلوتر، در ۲۷ برنامه برابر و در ۶ برنامه عقب‌تر بود.

آدم‌ها و اعتماد. این‌جا سلام در آغاز راه است. جامعه کوچک است، زبان پیش از نسخه‌ی ۱٫۰ است و هنوز میان نسخه‌ها تغییر می‌کند، استقرار عملیاتی اندکی دارد و هیچ صاحب سکویی آن را الزامی نکرده است. مجوزش GPL-3.0 است و توسعه‌اش به‌صورت عمومی در GitHub انجام می‌شود. نوشته‌ی چه چیزی یک زبان برنامه‌نویسی را آماده‌ی محیط عملیاتی می‌کند؟ این موارد را یکی‌یکی بررسی می‌کند.

جایگاهی که هیچ زبان دیگری پر نمی‌کند

الگوی تاریخی می‌گوید زبان تازه به یک برتری متمایز نیاز دارد. متمایزترین برتری سلام سرعت نیست، که C و Rust از قبل دارند؛ این است که سلام یک زبان سیستمی کامل و کامپایلی با دو خط است. هر واژه‌ی کلیدی، گونه، بسته‌ی کتابخانه‌ی استاندارد و پیام خطای کامپایلر، علاوه بر نام انگلیسی یک نام فارسی هم دارد و هر دو به یک برنامه کامپایل می‌شوند. این یک برنامه‌ی کوچک محاسبه‌ی معدل است که تماماً به فارسی نوشته شده:

تابع میانگین(نمره‌ها: اعشار۶۴[]): اعشار۶۴:
    ناپایا جمع := ۰.۰
    هر نمره در نمره‌ها:
        جمع += نمره
    پایان
    برگشت جمع / (طول(نمره‌ها) برگردان اعشار۶۴)
پایان

تابع ریشه:
    نمره‌ها := [۱۷.۵، ۱۹.۰، ۱۴.۲۵، ۱۸.۰]
    معدل := میانگین(نمره‌ها)
    اگر معدل بزرگتربرابر ۱۷.۰:
        سرچاپ "عالی:"، معدل
    وگرنه:
        سرچاپ "معمولی:"، معدل
    پایان
پایان

رقم‌های فارسی، ویرگول فارسی و نام‌های چندکلمه‌ای همه کار می‌کنند، و salam translate واژه‌های کلیدی یک فایل را میان دو نگارش تبدیل می‌کند. ترجمه‌ی واژه‌های کلیدی بخش آسان کار است. آنچه سلام اضافه می‌کند، همه‌ی چیزهای پیرامون آن است: یک کامپایلر بومی خودمیزبان، یک کتابخانه‌ی استاندارد بزرگ، پیام‌های کامپایلر و ابزارهایی که همه با یک خط راست‌به‌چپ و غیرلاتین کار می‌کنند. این به سلام مخاطب روشنی می‌دهد: دانش‌آموزان، دانشجویان، معلمان و توسعه‌دهندگان فارسی‌زبانی که می‌خواهند برنامه‌نویسی را به زبان خودشان شروع کنند و بدون عوض کردن زبان برنامه‌نویسی به انگلیسی برسند. برای همین است که سلام را «زبان برنامه‌نویسی فارسی» می‌نامند. نوشته‌های یک زبان، دو خط و برنامه‌نویسی به زبان مادری این موضوع را می‌کاوند.

بیرون از این جایگاه، برگ برنده‌ی سلام یک ترکیب است و نه یک ویژگی تنها: کارایی بومی در رده‌ی C و Rust، زبانی کوچک‌تر و خواناتر از C++ یا Rust، یک کتابخانه‌ی استاندارد بزرگ در سطح برنامه‌های کاربردی، و یک زنجیره‌ی ابزار. این ترکیب برای سرویس‌های وب، ابزارهای خط فرمان و اجزای سیستمی جذاب است. اما این میدان شلوغی هم هست که Go، Rust و Zig از قبل در آن جا افتاده‌اند.

قرض گرفتن چند دهه C

هر زبان تازه‌ی موفقی راهی برای استفاده از کد دنیای قدیم پیدا کرده است. برای سلام این پل، C است. یک بلوک درون‌داد: (extern:) تابع‌های C را اعلان می‌کند و سلام آن‌ها را مستقیم صدا می‌زند، ساختارها با ABI زبان C روی همان سکو به‌صورت مقداری منتقل می‌شوند و پیوند پویا "name" (link dynamic "name") یک کتابخانه‌ی سیستمی را پیوند می‌دهد. خود کتابخانه‌ی استاندارد هم از همین راه استفاده می‌کند: درایور SQLite به جای پیاده‌سازی دوباره، کتابخانه‌ی sqlite3 سیستم را پیوند می‌دهد. در جهت مخالف، برون‌داد: (export:) و salam build --lib تابع‌های سلام را به شکل یک کتابخانه‌ی C همراه سرآیند منتشر می‌کنند، پس هر زبانی که بتواند C را صدا بزند، می‌تواند کد سلام را هم صدا بزند. جزئیات در صدا زدن C از سلام آمده است.

این کار اکوسیستم npm یا PyPI را به سلام نمی‌دهد، اما یعنی کتابخانه‌ای که وجود ندارد با یک لایه‌ی پوششی به دست می‌آید، نه با بازنویسی کامل؛ همان راهی که Zig، Nim و دیگران برای پر کردن همین شکاف رفته‌اند.

سلام هنوز چه چیزهایی را باید به دست آورد

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

1. پایداری. نسخه‌ی ۱٫۰ با وعده‌ی سازگاری. تا آن زمان، ارتقا ممکن است به معنای تغییر کد باشد، مثل وقتی که اعلان متغیر محلی با گونه‌ی صریح در ۲۰۲۶ حذف شد.
2. بسته‌های شخص ثالث. مدیر بسته کار می‌کند؛ حالا آدم‌هایی لازم است که برای APIها، قالب‌ها و سرویس‌هایی که کتابخانه‌ی استاندارد پوشش نمی‌دهد کتابخانه منتشر کنند.
3. روایت‌های محیط عملیاتی. گزارش‌های عمومی و قابل وارسی از سرویس‌های سلامی که ماه‌ها زیر بار واقعی کار کرده‌اند، با اینکه چه چیزی خراب شد و چطور درست شد.
4. مشارکت‌کنندگان. کامپایلر و کتابخانه‌ی استانداردی به این اندازه، نگهدارنده و بازبین بیشتری از توان یک تیم کوچک لازم دارد.
5. ابزارهای ایمنی حافظه. سلام حافظه‌ی هیپ را صریح آزاد می‌کند و بررسی‌کننده‌ی امانت (Borrow Checker) ندارد. بررسی‌های زمان کامپایل و salam memcheck کمک می‌کنند، اما تیم‌هایی که از زبان‌های دارای زباله‌روب می‌آیند به مرور به اطمینان بیشتری نیاز دارند.
6. دیده شدن. بیشتر توسعه‌دهندگان هرگز نام سلام را نشنیده‌اند و دستیارهای کدنویسی درباره‌ی آن خیلی کمتر از پایتون می‌دانند. مستندات انگلیسی، همین مجله و مرجع‌های ماشین‌خوان یک شروع‌اند.

هیچ‌کدام از این‌ها ناممکن فنی نیست. همه‌شان سال‌ها زمان می‌برند، که با تجربه‌ی همه‌ی زبان‌های جدول بالا سازگار است.

موفقیت واقع‌بینانه چه شکلی دارد

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

پرسش‌های پرتکرار

چرا بیشتر زبان‌های برنامه‌نویسی جدید شکست می‌خورند؟

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

آیا یادگیری یک زبان جدید مثل زبان سلام ارزش دارد؟

به‌عنوان زبان دوم، بله، به‌ویژه اگر می‌خواهید کامپایلرها، برنامه‌نویسی سیستمی یا برنامه‌نویسی به فارسی را بفهمید. به‌عنوان تنها زبان برای مسیر شغلی، نه: یک زبان جاافتاده را هم یاد بگیرید، چون بازار کار سلام امروز بسیار کوچک است.

چقدر طول می‌کشد تا یک زبان برنامه‌نویسی فراگیر شود؟

معمولاً یک دهه یا بیشتر. Rust در ۲۰۱۵ به نسخه‌ی ۱٫۰ رسید و سال‌ها بعد به استفاده‌ی گسترده در صنعت رسید، و پایتون بیش از پانزده سال داشت که به انتخاب پیش‌فرض علم و یادگیری ماشین تبدیل شد.

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

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