من از به اشتراک گذاشتن بینش از مصاحبه یک ساعته با آندرس هجلسببرگ ، خالق TypeScript ، در مورد یک درگاه جدید چشمگیر از Typescript برای به اشتراک گذاشتن ، هیجان زده ام. این توسعه نوید پیشرفت های چشمگیری را می دهد ، و من دوست دارم شما را از طریق جزئیات قدم بزنم!
https://www.youtube.com/watch؟v=10QOWKUW82U
چه چیزی می تواند عملکرد بهتری را برای Node.js باز کند؟ بیایید کاوش کنیم
اعلام رسمی: یک نوع سریعتر 10 برابر سریعتر
کد منبع: github.com/microsoft/typescript-go
در اینجا یادداشت ها و تأملات من بر اساس مصاحبه آورده شده است.
جامعه Typescript از پیشرفتهای عملکردی در اولویت قرار گرفته است ، که اغلب این نیاز را بیش از درخواست های ویژگی های جدید برجسته می کند. این الهام بخش است که ببینیم این تمرکز زنده می شود.
این تیم 80 ٪ از قابلیت ها را فقط در شش ماه بازنویسی می کند ، از آگوست 2024. در حالی که ویژگی هایی مانند JSDOC و JSX هنوز پشتیبانی نمی شوند و 20 ٪ باقی مانده چند سال دیگر برای تصفیه طول می کشد ، این یک قدم امیدوارکننده است. برای پروژه های بزرگ و مستقر ، این جدول زمانی اهمیت دارد ، اما پروژه های جدید – یا آنهایی که به ویژگی های کمتری متکی نیستند – ممکن است کامپایلر جدید را در اوایل سال جاری اتخاذ کنید!
چرا برو؟
در حالی که من در حال نوشتن این مقاله بودم ، اندرس افکار خود را شرح داد: https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12466988
بازنویسی یک پروژه از این مقیاس از ابتدا امکان پذیر نبود ، بنابراین تیم تصمیم گرفت تا آن را به صورت پرونده به پرونده منتقل کند و با هدف حفظ حداقل تغییرات. اولویت اصلی حفظ رفتار تقریباً یکسان – 99.999 ٪ از آن برای پشتیبانی از انتقال صاف برای تیم های توسعه بود.
به دلایل مختلف به عنوان انتخاب ایده آل به عنوان انتخاب ایده آل است:
- این کار با عملکرد در ذهن طراحی شده و در سطح پایین تری فعالیت می کند.
- این به زیبایی با ساختار داده های بازگشتی Typecript (به عنوان مثال برخلاف زنگ زدگی) هماهنگ است.
- این پشتیبانی عالی از پلتفرم (برخلاف C#، که کمتر مناسب بود) ارائه می دهد.
دستاوردهای عملکرد
پایگاه کد فعلی Typecript از یک رویکرد واضح و کاربردی استفاده می کند – عملکردهای ساده و ساختارهای داده عمدتاً تغییر ناپذیر ، از اجتناب از انتزاع پیچیده OOP یا FP. من واقعاً از این طرح متفکر قدردانی می کنم.
ساختار داده های تغییر ناپذیر برای کارهایی مانند بارگیری سریع و ایمن کد در هنگام ویرایش IDE بسیار مهم است ، که به نفع توسعه دهندگان کار بر روی محصولات دنیای واقعی است.
قابلیت های چند گوش GO باعث افزایش عملکرد 3 برابر فوری شد. برخی از فرآیندها هنوز به چهار موضوع محدود شده اند و موازی سازی کامل هنوز کامل نیست. آندرس بر این امر تأکید نکرد ، اما من گمان می کنم حتی بیشتر امکان باز کردن قفل وجود دارد.
یکی از چالش ها با چند رشته ، تغییر از تکیه بر پیش بینی تک رشته ای بود. این باعث کنجکاوی من شد – گاهی اوقات ، طرح هایی که در نگاه اول به نظر می رسد کمتر به نظر می رسد می توانند بی سر و صدا مزایایی را ارائه دهند. به عنوان مثال ، تغییر ناپذیری به طور طبیعی از موضوع ایمن است. آندرس خاطرنشان كرد كه چگونه كد تک رشته ای می تواند به ترتیب اولیه سازی قابل پیش بینی بستگی داشته باشد ، كه در یك مجموعه چند رشته ای كمتر می شود-یک تجارت جذاب برای در نظر گرفتن.
گفته می شود ، این تغییر منجر به واگرایی از پایگاه اصلی کد شده است که تیم با جدیت در تلاش است تا به حداقل برسد.
3 برابر عملکرد 3 برابر دیگر از ساختارهایی حاصل می شود که دسترسی به حافظه را بهبود می بخشد و چند رشته را ساده می کند. آندرس توضیح داد که کاهش حافظه کاهش یافته فقط مربوط به کاهش بار در دستگاه توسعه دهنده نیست – این در مورد بهینه سازی فرایندهای فردی است ، و به جلوگیری از محدودیت حافظه پنهان CPU و سکسکه عملکرد کمک می کند.
آرزو می کنم پیشرفت بیشتری در خود جاوا اسکریپت داشته باشد. به عنوان مثال ، TC39 کار خود را روی Record & Tuple مکث کرد و به آرامی روی ساختارها حرکت می کند. اینها به طور بالقوه می توانند 5 برابر عملکرد را برای Node.js ارائه دهند ، و من دوست دارم در آنجا حرکت بیشتری ببینم. این یک منطقه جالب است که می توان در مورد تکامل اکوسیستم در مورد آن فکر کرد.
آندرس همچنین ستایش کرد که انواع مختلفی از عددی خود را دارد ، و این را با تک و حجیم جاوا اسکریپت متضاد می کند number نوع ، جایی که تغییر کمی در افق به نظر می رسد.
قابلیت همکاری
آندرس چالش دیگری را برجسته کرد: API Typecript. در حالی که برخی ممکن است بگویند که به سختی در آنجا وجود دارد – که اغلب از طریق راه حل های خلاقانه در JS گسترش یافته است – نسخه Go آن شکاف ها را به طور کامل بسته می کند. قسمت هیجان انگیز؟ این تیم با نیاز اکوسیستم به سفارشی سازی و سرعت جدید کامپایلر ، اکنون در ساختن یک رابط عمومی قابل اعتماد برای استفاده خارجی متمرکز شده است.
این همچنین می تواند به یک LSP مناسب برای TypeScript ، بهبود پشتیبانی ابزار – توسعه خوش آمدید منجر شود. آنها حتی در حال بررسی راه های ادغام با LLMS هستند و به آنها این امکان را می دهند تا با دقت بیشتر کد را بهتر درک کنند ، نه اینکه فقط آن را تجزیه کنند.
آینده پایگاه کد Typescript
ممکن است تعجب کنید که آیا دور شدن از زبان اصلی TypeScript از همکاران خودداری می کند. با این حال ، مشارکت های خارجی در اینجا عامل بزرگی نیست ، و GO برای توسعه دهندگان JavaScript بسیار نزدیکتر از مثلاً Rust است.
یک سؤال که من هنوز در مورد آن تأمل می کنم: چگونه آنها به کمبود غذای سگ پرداخته اند؟ من کنجکاو هستم که بیشتر بشنوم.
آندرس به ما اطمینان داد که پایگاه اصلی کد Typescript می تواند سالها پشتیبانی شود ، حتی پس از یک تغییر کامل. این مانند یک استراتژی با دقت برنامه ریزی شده است ، نه فقط یک آزمایش.
افکار نهایی
این مصاحبه واقعاً جذاب بود و نگاهی اجمالی به یک پروژه متفکرانه و جاه طلبانه ارائه می داد. من از تعهد تیم به یک مهاجرت تدریجی و ملاحظه تشویق می شوم.
در اینجا امیدواریم که به زودی شاهد هستیم که عذاب در حال اجرا است typescript-go!
https://www.youtube.com/watch؟v=0mcsluv5fxa
بیایید بحث کنیم:
من دوست دارم افکار شما را در نظرات بشنوم! تصور کنید که شما در حال شروع یک پروژه جدید هستید – آیا می توانید:
- به
typescript-goامسال با افزایش عملکرد 10 برابر خود؟ - چند سال صبر کنید تا ساختارهای بومی ECMAScript را انجام دهید و از TypeScript با افزایش عملکرد 5 برابر استفاده کنید؟
چه چیزی را انتخاب می کنید ، و چرا؟ من واقعاً کنجکاو هستم که ببینم همه چگونه این گزینه ها را وزن می کنند!
