Комментарии 31
Если семерка реально выйдет на свет - это будет величайшим событием для тайпскрипта
Очень жаль что не Rust.
почему?
Rust быстрее и вообще для мира веба делался, от создателей фаерфокса, не смотря на то что в ядро линукса теперь можно на нем писать.
Ну и конечно потому что я, помимо TypeScript, пишу и на Rust :)
На Rust и Go уже разрабатываются сторонние компиляторы и вариант с Rust быстрее. Microsoft вполне могли бы на Rust создать безальтернативный инструмент, а так всегда будет но
Майкрософту проще портировать код с TS на Go (оба имеют garbage collector), чем заново имплементировать на Rust, у которого работа с памятью организована по-другому.
На мой взгляд, ужасное решение
Большинство фич, фиксов, и даже просто плагинов делаются обычными разработчиками, пользующимися этими инструментами
А теперь представьте, сколько их них захотят внести contribution в проект, когда они открывают инструмент экосистемы - а в нем самого ничего из этой экосистемы нет, и вообще нужно разбираться с другим ЯП
Автор языка утверждает обратное - большинство правок делается ограниченным кругом разработчиков.
да, быть пограмистом сложно
надо знать язык, а иногда даже 2, нереальный уровень
п.с. сарказм
Конечно намного лучше было бы, если бы они сделали компилятор TS в нативный код. Это позволило бы делать нативные сборки и других инструментов: eslint, webpack, etc. Но, разумеется, на это нужно гораздо больше ресурсов.
В качестве варианта в Microsoft рассматривались и другие языки, такие как Rust, но они слишком сильно концептуально отличаются от TypeScript и при их использовании портирование превратилось бы в разработку компилятора с нуля, при которой было бы трудно добиться полной совместимости со старым компилятором, пришлось бы заново решать уже решённые в старой кодовой базе проблемы и проект потребовал бы значительно больше времени и ресурсов.
Я что-то не понимаю или это выглядит как бред? Они прогнали через ChatGPT код компилятора и перевели его в Go 1к1? С точки зрения принципов ЯП к TypeScript ближе именно Rust -- процедурное программирование (с базовыми возможностями функционального) с безопасной работой с памятью. Многопоточность на уровне ядра ОС.
Go -- таки больше про горутины, параллельную обработку и легковесный код (напиши это сам за 5 минут, а не подключай библиотеку, написанную непонятно кем и когда)
Ну т.е. они взяли старые проблемы, обмазанные древними костылями, сложенную в коробку легаси кода и перекралили в Go, попутно добавив еще костылей и поперчив все это изрядным количеством багов, а код все равно остался с пометкой легаси? Ускорение в 10 раз? Подозреваю, что если бы они не просто переписали все в однопоток на другой ЯП, а воспользовались всеми возможностями Go, не переносили бы ненужную логику и вообще взяли бы крутых Goшников, а не переучивали бы TSников на Go, то ускорение бы могло быть и в 100 раз.
Если кому интересно почему используется не C#, который является разработкой MS и во многих аспектах целится в ту же нишу, что и Go, то дизайнер Typescript дал развёрнутый ответ, в котором, если опустить то в чём C# не уступает Go, остаётся один важный пункт:
Совместимость с существующим JavaScript-кодом. Go позволил сохранить структурное сходство с текущей кодовой базой (функции и структуры данных, без использования классов), что сделало построчное портирование проще. Код на идиоматичном Go похож на код их оригинального компилятора.
C# тоже рассматривался как кандидат (был прототип), и это сработало бы, но его использование потребовало бы значительных изменений (в сторону OOP), так как изначально задача не предполагала полной переработки компилятора. По мнению Андерса, выбор Go был оптимальным для порта, а не из-за недостатков C#.
Этот аргумент звучит здраво, если объяснять почему не Rust. Без GC ручное управление памятью превратило бы порт в переписывание компилятора. Но если выбирали нативный язык с GC, то выбором Go, вместо C#, озадачены многие в обсуждении на GitHub.
Хотя, в одном из интервью, Андерс сказал, что C# bytecode-first, а NativeAOT слишком молод ("doesn't have a decade or more of hardening") и не на всех платформах поддерживается, в ответ на этот же вопрос. Учитывая, что он покинул в своё время команду разработки C# в пользу разработки Typescript, могу предположить, что он слегка предвзят.
В видео на канале Microsoft'а был показан кусок кода оригинального компилятора и нового, похожих на построчный порт. Там же был пример ускорения в 10 раз на большом проекте. Помимо просто ускорения, полученного от перехода на компилируемый язык, они теперь при проверке типов компилятором Typescript делят файлы на 4 части и строят графы типов параллельно и независимо друг от друга, что заставляет их делать лишнюю работу (для базовых типов) и увеличивает потребление памяти из-за этого, но зато быстрее.
Примеры цифр ускорения на различных проектах есть в оригинальном посте в DevBlog.
Как я понял существенное увеличение скорости сделано именно для компиляции Typescript (что актуально), но не ясно ускорился ли сам код производимый новым компилятором или скорость работы производимых бинарников не изменилась
Там не бинарники производятся а ЖС ;)
Я грешным делом успел подумать про AOT-компиляцию самого typescript) Тогда рано еще радоваться
Это вряд ли возможно в принципе для тайпскрипта в том виде как он есть и как задумывался.
Есть доклад интересный на эту тему https://www.youtube.com/watch?v=gS9a_NBHdw0
Хотя вот такое нашел https://github.com/ASDAlexander77/TypeScriptCompiler
И вот такое еще есть от авторов самого JavaScript (но это не точно) - asm.js
Я не пробовал, но вроде как имеет довольно хорошую поддержку в браузерах уже и в WebAssembly.
Но это же не сам JS, а его подмножество + предполагается компиляция в него, а не ручное написание, amirite?
В целом - да. Я просто привел как еще один пример попытки приблизить JavaScript к native. Имел ввиду, что похоже это именно тренд. Чем дальше - тем чаще у ЖСа прорывы по перформансу в текущих средних размерах проектов.
Суть асм.жс - урезаный ЖС, через урезаную гибкость и работу с типами (сделать более С-подобным; Го-подобным, так как есть CG) - и тогда сильно уменьшается объем инфраструктурной логики, что делает его сильно ближе к нативному С по производительности.
Зачем это называется компиляцией, а не трансляцией?
Парни внезапно поняли что JS медленный?
Странно, в 10х быстрее? Я всегда думал что у Node и Go схожая производительность.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html
Microsoft разрабатывает на Go проект TypeScript 7