تصور کنید بخواهید یکی از پیچیده‌ترین ابزارهای زیرساختی دنیای وب را از ابتدا بازنویسی کنید؛ کاری که برای تیم‌های مهندسی ماه‌ها زمان می‌برد، حالا در یک بعدازظهر توسط هوش مصنوعی انجام شده است. Claude 5.5 Opus ثابت کرد که می‌تواند یک کامپایلر صنعتی عظیم را بدون دخالت انسانی و با دقت بالا به زبانی سریع‌تر منتقل کند.
نتیجه این آزمایش، ابزاری به نام ts-rust (یا tsc-rs) است؛ یک پورت آزمایشی از کامپایلر TypeScript 7 به زبان Rust که در سرعت خام، حتی از نسخه مبتنی بر Go نیز پیشی گرفته است.
اکوسیستم TypeScript سال‌هاست با گلوگاه‌های عملکردی کامپایلر مبتنی بر جاوااسکریپت دست‌وپنجه نرم می‌کند. مایکروسافت اخیراً برای حل این مشکل به سراغ پیاده‌سازی با زبان Go رفت، اما انتقال به Rust گام منطقی بعدی برای توسعه‌دهندگانی است که به دنبال حداکثر سرعت اجرا و ایمنی حافظه هستند. این پروژه دقیقاً در زمانی رخ می‌دهد که صنعت در حال پرسش از توانایی هوش مصنوعی زاینده (Generative AI) برای مدیریت مهاجرت‌های معماری در مقیاس بزرگ بدون نظارت انسانی است؛ شبیه به یک معمار خبره که می‌تواند نقشه‌های یک ساختمان قدیمی را به متریال مدرن تبدیل کند. این تحول در مدیریت ابزارهای توسعه، در کنار پیشرفت‌هایی مانند تبدیل ترمینال‌های دسکتاپ به رابط‌های برنامه‌پذیر برای عامل‌های هوش مصنوعی، نشان‌دهنده تسلط بیشتر مدل‌های زبانی بر محیط‌های عملیاتی پیچیده است.
نبرد مدل‌های زبانی
به نقل از مستندات گیت‌هاب این پروژه که در ۸ اکتبر ۲۰۲۶ منتشر شد، فرآیند پورت کردن به یک رقابت مستقیم میان خانواده‌های مدل تبدیل شد. توسعه‌دهنده ابتدا این مسیر را با مدل‌های GPT-5.6 Sol و GPT-6 Astra آغاز کرد.
این مدل‌های OpenAI ماه‌ها در «حلقه‌های هدف» (Goal Loops) گیر کردند و در این مدت بیش از ۱.۳ میلیون خط کد Rust نوشتند. با وجود سرمایه‌گذاری عظیم و هزینه بیش از ۴۰۰ هزار دلار برای توکن‌های API، آن‌ها هرگز نتوانستند از ۸۴٪ سازگاری با کامپایلر اصلی فراتر بروند.
در مقابل، Claude 5.5 Opus رویکردی کاملاً متفاوت داشت. این مدل به‌جای تکیه بر کدهای تولید شده توسط Codex یا اصلاح کدهای قبلی، همه چیز را از صفر شروع کرد. نتیجه این استراتژی این بود که Opus تنها در ۱۰ ساعت، نسخه اولیه (v0) فعال و قابل اجرا را تحویل داد.
هزینه نهایی این موفقیت حدود ۲۴,۰۴۷ دلار در بازه دو هفته بود؛ رقمی که در مقایسه با هزینه‌های هنگفت و شکست‌خورده GPT-6 بسیار ناچیز است. توسعه‌دهنده اشاره کرد که این مبلغ در واقع بین ۹۲۵٪ تا ۹۸۳٪ محدودیت‌های طرح هفتگی ۲۰۰ دلاری او بوده است.
بنچمارک‌ها و عملکرد فنی
ابزار tsc-rs یک پورت مستقیم از کامپایلر بومی TypeScript است که پیش‌تر با Go نوشته شده بود (مخزن microsoft/TypeScript یا همان typescript-go). این ابزار رابط خط فرمان (tsc)، سرور زبان و رفتار API را دقیقاً حفظ کرده اما از قدرت و بهینگی Rust استفاده می‌کند.
در بررسی ۶۰ پروژه متن‌باز، زمان بررسی نوع (Type Checking) با tsc-rs تقریباً نصف نسخه Go شد (بر اساس میانگین هندسی). اما تفاوت واقعی و خیره‌کننده هنگام مقایسه با کامپایلر اصلی جاوااسکریپت (tsc 6) نمایان می‌شود.
بر اساس داده‌های به‌دست‌آمده از ۶ اپلیکیشن واقعی، میانگین هندسی سرعت افزایش یافته ۲۰.۹ برابر است. نتایج جزئی به شرح زیر است:
- VS Code (۳.۷۵ میلیون خط): زمان از ۵۴.۵۶ ثانیه (tsc 6) به ۴.۲۰ ثانیه (tsc-rs) کاهش یافت که معادل ۱۳.۰ برابر سرعت بیشتر است.
- Sentry frontend (۲.۱۱ میلیون خط): زمان از ۵۸.۷۶ ثانیه (tsc 6) به ۴.۴۶ ثانیه (tsc-rs) رسید که معادل ۱۳.۲ برابر سرعت بیشتر است.
- Playwright (۵۸۵ هزار خط): زمان از ۴.۴۸ ثانیه (tsc 6) به ۰.۳۴ ثانیه (tsc-rs) کاهش یافت که معادل ۱۳.۲ برابر سرعت بیشتر است.
- Excalidraw (۴۴۹ هزار خط): زمان از ۵.۳۲ ثانیه (tsc 6) به ۰.۷۰ ثانیه (tsc-rs) رسید که معادل ۷.۶ برابر سرعت بیشتر است.
- TypeORM (۳۸۶ هزار خط): زمان از ۳.۸۶ ثانیه (tsc 6) به ۰.۳۶ ثانیه (tsc-rs) کاهش یافت که معادل ۱۰.۷ برابر سرعت بیشتر است.
- tRPC server package (۲۰۹ هزار خط): زمان از ۱.۱۰ ثانیه (tsc 6) به ۰.۰۹ ثانیه (tsc-rs) رسید که معادل ۱۲.۰ برابر سرعت بیشتر است.
اگرچه Bun check همچنان سریع‌ترین ابزار برای بررسی‌های پایه است، اما tsc-rs یک مزیت حیاتی برای پروژه‌های Effect دارد. این ابزار تشخیص‌های سرویس زبان Effect (کدهای 377xxx) را مستقیماً در مرحله بررسی ادغام می‌کند و نیاز به اجرای دومین کامپایلر را کاملاً از بین می‌برد.
تحلیل عمیق تشخیص‌های Effect
برای پروژه‌هایی که از زبان Effect استفاده می‌کنند، tsc-rs تجربه‌ای بهینه و یکپارچه ارائه می‌دهد. قوانین و گزینه‌های این ابزار، پورتی از نسخه Effect-TS/tsgo 0.46.1 هستند. این تشخیص‌ها تنها زمانی اجرا می‌شوند که پلاگین مربوطه در فایل tsconfig تعریف شده باشد:
{ "compilerOptions": { "plugins": [{ "name": "@effect/language-service" }] } }
در بنچمارک T3 Code که شامل ۵ پروژه (apps/server, apps/web, apps/mobile, packages/client-runtime, and packages/shared) است، تفاوت‌ها کاملاً واضح است:
- بدون تشخیص‌های Effect: زمان اجرای tsc-rs برابر ۷.۲۵ ثانیه بود، در حالی که tsc 7 حدود ۱۶.۱۰ ثانیه و tsc 6 حدود ۶۲.۶۳ ثانیه زمان برد.
- با تشخیص‌های Effect: زمان اجرای tsc-rs (با Effect داخلی) به ۱۱.۱۳ ثانیه رسید. در مقابل، ترکیب tsc 7 و @effect/tsgo حدود ۲۱.۰۷ ثانیه و ترکیب tsc 6 و @effect/language-service حدود ۱۳۸.۶۳ ثانیه زمان برد.
در حالی که Bun check در پروژه‌های غیر Effect سریع‌تر است، اما به دلیل نبود این تشخیص‌ها، پروژه‌های Effect مجبور به اجرای یک مرحله (Pass) اضافی هستند؛ کاری که tsc-rs هر دو را در یک مرحله انجام می‌دهد. در بنچمارک T3 Code، هر دو ابزار tsc-rs و tsc 7 + @effect/tsgo دقیقاً تعداد یکسانی (۲۲۱ مورد) تشخیص Effect را گزارش کردند.
محدودیت‌ها و سازگاری
با وجود این سرعت، پروژه هنوز در مراحل اولیه انتشار است. این ابزار به یک بازبینی (Revision) خاص از TypeScript 7.1.0-dev مورخ ۲۹ سپتامبر ۲۰۲۶ متصل است (microsoft/TypeScript 673a5f17d713). برای مقایسه دقیق نتایج، کاربران باید از نسخه [email protected] استفاده کنند و نه نسخه‌های 7.0.x یا @typescript/native-preview.
طبق گزارش توسعه‌دهنده، سازگاری در اکثر پروژه‌های واقعی تست شده ۱۰۰٪ است و تمام ۱۸۱,۷۱۱ تست پورت‌شده از Go با موفقیت پاس شده‌اند. پاسخ‌های سرور زبان و API نیز با نتایج Go در مجموعه‌های تست Oracle مطابقت دارد. با این حال، برخی موارد خاص (Edge Cases) همچنان وجود دارد:
- مونو-ریپوها (Monorepos): در برخی موارد، فایل‌های منبع هم از طریق node_modules و هم از طریق Importهای مستقیم قابل دسترسی هستند. tsc-rs ممکن است خطای TS6059 (فایل زیر rootDir نیست) را با سخت‌گیری بیشتری نسبت به tsc گزارش کند، زیرا tsc این مورد را بر اساس زمان‌بندی تصمیم می‌گیرد.
- ارجاعات پروژه: در دستور
tsc -bاگر یک پروژه خروجی پروژه دیگر را بدون داشتن Project Reference وارد کند، tsc-rs ممکن است خروجی‌های قدیمی یا گم‌شده را بخواند (خطاهای TS2305 یا TS2307). - حافظه ادیتور: مصرف حافظه در جلسات طولانی به‌آرامی رشد می‌کند (حدود ۲۰ مگابایت به ازای هر ۱,۰۰۰ ویرایش)، هرچند این مقدار همچنان کمتر از میزان مصرف tsc است.
نصب این ابزار از طریق npm با دستور npm install -D tsc-rs و اجرا با npx tsc-rs -p tsconfig.json انجام می‌شود. در حال حاضر این ابزار از لینوکس x64 (استاتیک) و مک arm64 پشتیبانی می‌کند و پشتیبانی از ویندوز و لینوکس arm64 هنوز فراهم نشده است.
معماری داخلی
پروژه برای مدیریت مقیاس عظیم کامپایلر به چندین بخش تخصصی تقسیم شده است:
- هسته کامپایلر: کریت
crates/ts_goportمنطق اصلی را مدیریت می‌کند که خود به دو بخشgoport_utilوgoport_lsprotoتقسیم شده است. این بخش از فایل‌های lib در مسیرcrates/ts_goport/libsاستفاده می‌کند. - ابزارهای تولید کد: ابزار
tools/ts_ast_codegenداده‌های AST را درcrates/ts_goport/src/astdataتولید می‌کند، در حالی کهtools/ts_diagnostics_codegenکاتالوگ تشخیص‌ها را درcrates/ts_goport/src/diagnostics/catalog.rsوcrates/ts_goport/src/diag.rsمی‌سازد. - پشتیبانی از WASM: یک بیلد اختصاصی در
crates/ts_wasmاجازه می‌دهد کامپایلر در محیط وب‌اسمبلی اجرا شود. - تأییدیه: اسکریپت‌های
scripts/verify.shوscripts/run-cargo-capped.shتضمین می‌کنند که باینری‌های Rust (شاملgoportوtsgo) با تست‌های پایه Go مطابقت دارند. تست‌های پایه Go با استفاده از مسیرهایTS_GO_REPOاجرا می‌شوند.
متدولوژی اندازه‌گیری
برای دقت بیشتر، بنچمارک‌های اپلیکیشن‌های واقعی روی یک Apple M4 Pro (۱۲ هسته، ۴۸ گیگابایت رم) با سیستم‌عامل macOS 26.5.1 اجرا شدند. تیم از ابزار hyperfine برای محاسبه میانگین ۵ اجرا (پس از یک اجرای گرم‌کننده) استفاده کرد و گزینه‌های --noEmit و --incremental false را فعال نمود.
جزئیات محیطی شامل موارد زیر است:
- نسخه Node: tsc 6 روی Node 24.19 با ۱۶ گیگابایت Heap اجرا شد تا از خطای کمبود حافظه (Out-of-memory) در پروژه‌های سنگین مانند VS Code و Sentry جلوگیری شود.
- اجرای باینری: tsc 7 و tsc-rs به صورت باینری بومی و بدون لانچر npm اجرا شدند.
- نسخه‌ها: tsc-rs 0.1.0، TypeScript 7.0.2 و 6.0.3، و Bun canary bd599f5af.
چهار اپلیکیشن برای رسیدن به وضعیت ۰ خطا تحت tsc 7 نیاز به تغییرات پیکربندی داشتند: Excalidraw (حذف baseUrl)، TypeORM (تغییر moduleResolution به nodenext)، VS Code (تایپ‌های electron) و Playwright (منابع تولید شده توسط build).
تحلیل: مرگ پورت‌های دستی
این آزمایش معیار ما را برای آنچه «بیش از حد بزرگ» برای مدیریت توسط یک LLM تلقی می‌شد، تغییر می‌دهد. پورت کردن یک کامپایلر یک تسک ترجمه ساده نیست؛ بلکه نیازمند حفظ منطق پیچیده و سازگاری سخت‌گیرانه در میان میلیون‌ها خط کد است.
این واقعیت که یک مدل توانست از صفر شروع کند و در جایی موفق شود که مدل‌های دیگر شکست خوردند، نشان می‌دهد که استدلال معماری (Architectural Reasoning) در حال تبدیل شدن به روشی قابل‌اعتمادتر از وصله‌پینه‌های تکراری است. برای یک توسعه‌دهنده معمولی، این بدان معناست که هزینه مهاجرت کدهای قدیمی (Legacy) به زبان‌های با کارایی بالا مانند Rust در حال سقوط است.
ما در حال حرکت از عصر «کدنویسی با کمک هوش مصنوعی» به عصر «مهاجرت به رهبری هوش مصنوعی» هستیم. گلوگاه اصلی دیگر توانایی مدل در نوشتن کد نیست، بلکه توانایی انسان در تأیید خروجی است؛ به‌ویژه وقتی که سازنده ts-rust اعتراف می‌کند که هرگز حتی یک خط از کد تولید شده را نخوانده است.
برای اینکه ببینید این افزایش سرعت برای پروژه شما کار می‌کند یا خیر، می‌توانید بسته را از طریق npm نصب کرده و آن را روی tsconfig.json خود اجرا کنید تا زمان‌های بررسی را مقایسه نمایید.
گفتگو