تصویر از بنجامین وینز از Pixabay.
تصویر از بنجامین وینز از Pixabay.

قدرت Go: شرط‌بندی جسورانه مایکروسافت بر روی ابزارهای سریع‌تر TypeScript

مایکروسافت ابتکاری را برای انتقال کامپایلر TypeScript و ابزارها به یک پیاده‌سازی بومی Golang، با نام رمز "Corsa" آغاز کرده است.

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

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

مایکروسافت توانست با انتقال کامپایلر TypeScript به زبان Go به این عملکرد دست یابد و چالش‌های مقیاس‌بندی را برآورده کند.

عملکرد

بهبودهای کلیدی عملکرد شامل کاهش زمان ساخت تقریباً 10 برابر، بهبود 8 برابری در زمان بارگذاری پروژه، تقریباً نصف مصرف حافظه پیاده‌سازی فعلی (با بهینه‌سازی‌های بیشتر مورد انتظار) و بهبود خدمات زبان شامل سرعت‌های قابل توجه برای تکمیل، اطلاعات سریع، رفتن به تعریف و یافتن همه مراجع است.

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

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

  • VS Code (1,505,000 LOC): 77.8s ? 7.5s (10.4x سریع‌تر)
  • Playwright (356,000 LOC): 11.1s ? 1.1s (10.1x سریع‌تر)
  • TypeORM (270,000 LOC): 17.5s ? 1.3s (13.5x سریع‌تر)
  • date-fns (104,000 LOC): 6.5s ? 0.7s (9.5x سریع‌تر)
  • tRPC (18,000 LOC): 5.5s ? 0.6s (9.1x سریع‌تر)
  • rxjs (2,100 LOC): 1.1s ? 0.1s (11.0x سریع‌تر)

در واقع، هایلزبرگ نوشت: «بهبود عملکرد 10 برابری نشان‌دهنده یک جهش بزرگ در تجربه توسعه TypeScript و JavaScript است...».

هایلزبرگ در یک ویدیو اشاره کرد که JavaScript (که TypeScript بر اساس آن است) عمدتاً "برای استفاده از رابط کاربری و مرورگر استفاده می‌شود و نه برای حجم کاری محاسباتی فشرده مانند کامپایلرها و ابزارهای سطح سیستم." او افزود که مایکروسافت احتمالاً به حد "آنچه می‌توانیم از JavaScript استخراج کنیم" رسیده است.

انتقال یا بازنویسی

هایلزبرگ گفت که تیمش می‌دانست که می‌خواهند یک انتقال انجام دهند و نه یک بازنویسی کامپایلر TypeScript به Go.

رایان کاوانا، سرپرست توسعه تیم TypeScript، در یک پرسش و پاسخ در مورد تلاش TypeScript نوشت:

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

  • در یک "بازنویسی" شما از هیچ شروع می‌کنید و یک سیستم جدید را پیاده‌سازی می‌کنید که سعی می‌کند همان مشکلی را حل کند که سیستم اصلی حل می‌کند، بدون توجه به استراتژی‌های پیاده‌سازی پایگاه کد اصلی
  • در یک "انتقال" شما پایگاه کد موجود را می‌گیرید و آن را به زبان جدید تبدیل می‌کنید در حالی که سعی می‌کنید تا حد امکان همان را نگه دارید

اجرای انتقال سریع‌تر است، اما مستلزم این است که زبان جدید حداقل از نظر معماری تا حدودی با زبان اصلی سازگار باشد...»

چرا Go؟

هایلزبرگ گفت که مایکروسافت سعی کرد نمونه‌سازی را در تمام زبان‌های هدف معمول (C#، C++، Rust و غیره) انجام دهد، اما متوجه شد که Go مناسب‌ترین زبان برای حجم کاری خاصی است که آنها در تلاش برای انجام آن بودند.

دیوید میتون، مدیرعامل Arcjet، به The New Stack گفت: «بسیار جالب است! توسعه‌دهندگان JS متأسفانه به ابزارهای کند عادت کرده‌اند، بنابراین یک کامپایلر سریع‌تر که امکان بهبود زمان راه‌اندازی ویرایشگر را فراهم می‌کند، بسیار خوشایند است. انتقال به یک کامپایلر بومی منطقی به نظر می‌رسد، اگرچه Go یک انتخاب غیرعادی برای این نوع پروژه است. وقتی این اعلامیه را دیدم، فرض کردم که این در Rust خواهد بود مانند بیشتر بازنویسی‌های ابزار JS دیگر: Rolldown، Turbo (که از Go به Rust منتقل شدDeno... من تعجب می‌کنم که چه چیزی پشت این تصمیم است.»

کاوانا در پاسخ به این سوال، در پرسش و پاسخ نوشت که Go بهترین کار را انجام داد هنگام در نظر گرفتن معیارهای متعددی که خاص این وضعیت هستند.

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

پیاده‌سازی مبتنی بر Go در GitHub (مخزن typescript-go) موجود است و در حال حاضر قادر به بارگیری بسیاری از پروژه‌های محبوب TypeScript، از جمله خود کامپایلر TypeScript است.

نسخه‌ها

مایکروسافت انتظار دارد پیش‌نمایشی از tsc بومی که قادر به بررسی نوع خط فرمان باشد، تا اواسط سال 2025 ارائه شود. tsc کامپایلر TypeScript است. انتظار می‌رود یک پیاده‌سازی کامل برای ساخت پروژه‌ها و خدمات زبان تا پایان سال 2025 ارائه شود.

آخرین نسخه TypeScript، TypeScript 5.8 بود و TypeScript 5.9 به زودی عرضه می‌شود. هایلزبرگ گفت که توسعه پایگاه کد مبتنی بر JS به سری 6.x ادامه خواهد داشت و TypeScript 6.0 برخی از منسوخ‌شدگی‌ها و تغییرات مخرب را برای همسویی با پایگاه کد بومی آینده معرفی خواهد کرد.

او گفت: «وقتی پایگاه کد بومی به برابری کافی با TypeScript فعلی رسید، آن را به عنوان TypeScript 7.0 منتشر خواهیم کرد.»

هایلزبرگ نوشت: «و برای وضوح بیشتر، ما به سادگی به آنها TypeScript 6 (JS) و TypeScript 7 (بومی) اشاره خواهیم کرد، زیرا این نامگذاری برای آینده قابل پیش‌بینی خواهد بود. همچنین ممکن است در بحث‌ها یا نظرات کد داخلی به "Strada" (نام رمز اصلی TypeScript) و "Corsa" (نام رمز این تلاش) اشاره کنیم.»

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

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