TypeScript Native (AOT) Compiler

хотелось бы понять.

1. цель написания компилятора…ну типа писать десктопные аппы на ts или еще что.

2. насколько ускорилось исполнение, если приложение скомпилировано?

3. что значит преальфа - полное множество языка реализовано в компиляторе? что недоделано?

формальный сканер должен читать из потокового интерфейса вида, без возможности репозиционирования.

class Reader{
  charType get_char()=0; ///взять след. символ потока, если конец потока - возвращает nullChar, ну или eofChar.
  bool is_eof()=0; ///последнее  чтение дало конец потока, все последующие чтения валидны, но возвращают (см выше)
}

другие функции нежелательны.

тогда разными реализациями ридера сможете парсить хоть строку, хоть файл, хоть поток из порта, хоть черта лысого.

Wasm-код может работать прилично быстрее js, это уже хорошая годная цель.

Закопать, поставить крест, положить тяжёлый камень и сверху ещё катком проехать.

Закопать, поставить крест, положить тяжёлый камень и сверху ещё катком проехать.

Если это про typescript как таковой, то +1.

для LLVM, и позволяет генерировать бинари для всех целевых платформ, в том числе в WASM.

Вообще, конечно, унификация – это хорошо. Может хотя бы 0.01% из попробовавших это поделие догадается, что в WASM можно компилировать и из более приличных языков.

UPD. Впрочем, остальные 99.99% начнуть писать на ts под десктоп.

Да, это про всё вот это, около js-ное. Идея выглядит привлекательной (хотя на самом-то деле любой браузер и так транслирует js в машинный код, или во всяком случае некоторое время назад транслировал - не знаю, как сейчас стало). Поэтому на неё клюнут. На node.js клюнули же. Потому это и Зло.

Это не мой проект, поэтому развернутых комментариев дать не могу.

Я это сюда притащил лишь потому, что тут очень много (судя по темам о жсе) любителей тса.

Насколько могу знать, на данный момент не реализована поддержка дженериков.

Сам автор русскоязычный.

Тут у автора идея в том, что на выходе ты имеешь полностью независимый, нативный, AOT скомпилированный бинарь. Не тащащий с собой в рантайме ни интерпретаторов, ни жита.

Со сборкой мусора и интероперабельностью с пллюсами, как он заверяет.

Этакий golang/dlang со вкусом ts.

А когда уже node.js переделают на TypeScript?

А когда уже node.js переделают на TypeScript?

Никогда. Это не нужно.

Для тебя есть deno (https://deno.land/). С растами и тсами.

что в WASM можно компилировать и из более приличных языков.

Нет никакого резона компилировать в wasm из языков со сборкой мусора. Потому что такой модуль, с огромной вероятностью будет тащить с собой очень здоровый оверхед в виде рантайма исходного языка и сборщика.

А загрузка и выполнение здоровых приложений на васме выглядит ровно так, словно ты каждый раз загружаешь приложение из апп стора, а не переходишь по ссылке в браузере. Это убивает всю суть веба, как таковую, никто этим пользоваться не будет.

Wasm не для приложений. Он для узкоспециализированных вспомогательных библиотек.

Ну и под него, помимо сабжа, уже есть вполне удобный AssemblyScript

При запуске интерпретатора или простого байт-кода время выполнения программы неминуемо будет тратиться на компиляцию этого кода в машинный код. Если программа серверного типа, т.е. работает очень долго, то это время будет ничтожно мало и на него можно не обращать внимания. Но если твоя программа сама по себе работает, например, 50 мс (скажем это лямбда), и из них 10 мс занимают накладные расходы интерпретатора/jit-компилятора, то это уже проблема. AOT-компиляция позволяет решить эту проблему: ты время тратишь один раз до запуска этой программы.

Сборку мусора в wasm-е обещают и когда-нибудь таки сделают. В остальном - согласен, пока не завезли, wasm для языков без GC.

Да уже пять лет обещают и сборку, и прямой проброс нативных апи окружения и треды. Сколько еще времени пройдет до того, когда это случится и что из этого получится неизвестно. Лично я не восхищюсь этой перспективой, и никаких особых надежд на это не возлагаю. Васм оперирует буферами памяти, а не объектами и ссылками, и если там и будет реализован gc, то он тоже будет оперировать этими буферами, а не объектами. Так что любой высокоуровневый язык все равно будет тащить свой рантайм и свой gc.

Это круто звучит по роадмапу в той части, где они говорят о том, что wasm как целевая платформа вообще не обязана быть в браузере. И вполне уже пишут отдельные исполнительные среды для васма вне браузера. Такая себе jvm.

Но для клиентских веб-приложений, на самом деле скорости js-движков хватает с головой (а мономорфный js-код вовсе не уступает коду на wasm), и быстрее это все равно не будет работать. Боттлнек всегда совершенно в других местах - сеть, отрисовка, и прочее. А не язык.

Это не голанг. У голанга всё же есть какой-то набор идей. А js - это инвалид от рождения. Можно кое-как оправдать его использование в вебе, учитывая специфику веба. ts - это костыль, который дали инвалиду. Теперь к этому костылю приделали литиевую батарейку и назвали электросамокатом. Горбатого могила исправит, олимпийцем он всё равно не станет, максимум - параолимпийцем.

Ты же просто хейтерок.

На гитхабе доступна для тестирования всеми желающими пре-альфа компилятора TypeScript в нативный машинный код.

ИМХО все это похоже на
Мы создадим себе массу проблем и будем их

ГЕРОИЧЕСКИ РЕШАТЬ!

Неа, я просто вижу, что данная дурная затея может иметь успех, и мир станет ещё насколько-то хуже. Ненависть вызывает то, от встречи с чем сложно уклониться, а тут только проросток. До реальной угрозы далеко. Пока что только брезгливость вызывает, чтобы заслужить ненависть - нужно ещё дорасти, посмотрим, что дальше будет.

для клиентских веб-приложений, на самом деле скорости js-движков хватает с головой

Вот, кстати, интересный момент, иногда васм ведёт себя так, будто код исполняется поверх виртуальной машины питона.

А js - это инвалид от рождения

Современный жс мало похож на то, что было при его рождении.

Это не так. Я с жсом уже давно сижу. Ну про рождение не скажу, но за последние 15 лет он не изменился вообще никак. Все изменения - тупо прикручивают синтаксический сахар, но это вообще ничего не меняет по сути.

Пожалуй одно могу отметить - нынче eval-ом не пользуются. Это, кстати, интересное явление. По идее eval это очень мощная штука, метапрограммирование и всё такое. Но с другой стороны эффективно его выполнять практически невозможно, eval ломает все оптимизации в хлам. Может оно и к лучшему.

Нет никакого резона компилировать в wasm из языков со сборкой мусора. Потому что такой модуль, с огромной вероятностью будет тащить с собой очень здоровый оверхед в виде рантайма исходного языка и сборщика.

Видимо, М$ другого мнения.

Это убивает всю суть веба, как таковую, никто этим пользоваться не будет.

А переход по ссылке на какое-то здоровое веб-приложение, где надо ждать, пока оно прогрузится, не убивает суть веба? Ну и подумайте с точки зрения конечно пользователя, что важнее: один раз подождать, пока приложение кешируется где-то в браузере или терпеть тормоза?

Недавно читал список изменений в ЕС6, их много.

Все изменения - тупо прикручивают синтаксический сахар, но это вообще ничего не меняет по сути.

А много изменить нельзя. Нет возможности на сайте сделать как с питоном или пхп: объявить последнюю версию интерпретатора поддерживаемой. Поэтому сложно внести много изменений, нарушающих обратную совместимость.

Пожалуй одно могу отметить - нынче eval-ом не пользуются. Это, кстати, интересное явление. По идее eval это очень мощная штука, метапрограммирование и всё такое. Но с другой стороны эффективно его выполнять практически невозможно, eval ломает все оптимизации в хлам. Может оно и к лучшему.

Ивал ломает восприятие. Его, конечно, можно правильно использовать, но это редкость.

Дело даже не в обратной совместимости. Ничего не мешает в теории делать что-то принципиально новое. Вот взять систему классов. Классов, как таковых, в жаваскрипте не было. Могли бы сделать всё по-новому. Однако сделали всё на старых прототипах, просто приделали синтаксический сахар к тому, что и так люди использовали.

Вообще показателен бабель. Берёшь новый код, суёшь в бабель, и видишь, что то, что он выплёвывает, примитивное преобразование один в один.

Пожалуй только async/await отсюда выбивается, там не совсем примитивное.

Зачем нужно это говно ? Есть же грааль с поддержкой АОТ, жабоскрипта, пытона и прочего говна.

Ты какой-то простачок, ей богу.

Метапрограммирование засунь себе в жопу! Навертят абстракций, а на выходе тормозное неподдерживаемое говно.

curl | sh

На помойку. Вместе с авторами.

TypeScript Native (AOT) Compiler

Для чего он нужен и какие проекты его используют?
Так то красиво …

Я не использую

После рождения он перенёс ещё ряд болезней.

После рождения он перенёс ещё ряд болезней

А мини инфаркты были?

https://github.com/search?q=TypeScriptCompiler

10 repository results

Там все репозитории это обертки над простым компилятором ts -> js. Транспилятором.

Сабж про совершенно другое.

Сабж про совершенно другое

Так какие проекты сабж используют?
На github таковых нет …

доступна для тестирования всеми желающими пре-альфа компилятора

Вот что пишет автор проекта

 **ASDAlexander77/ASDAlexander77** is a ✨ _special_ ✨ repository because its `README.md` (this file) appears on your GitHub profile.
...
- ⚡ Fun fact: ...
-->

Прими таблетки.

Прими таблетки.

От вас другого ответа и не ожидал …

Потому что я работаю предсказуемо, согласно спецификации.

Потому что я работаю предсказуемо, согласно спецификации.

Вы просто хамло.

Это предсказуемо

Никогда. Это не нужно.

Не, ну в начале по лозунгом, то код будет одинаков во фронте и на беке запилили node.js.

Потом осознав, то JS немного не тот язык, на котором следует делать что-то большое, запилили TS. (Тем самым , начальная идея одинаковости провалилась, но мыши продолжают кушать кактус.)

Казалось бы следующий логичный шаг - вместо node.js запилить node.ts , тем самым признать статус-кво и упростить тулчейн. Тем более совместимость позволяет сделать это постепенно.

Но нет. Это типа не нужно. А компилируемый TypeScript, можно подумать, нужен.

А компилируемый TypeScript, можно подумать, нужен.

Так он а-ля Kotlin для Java.
Весь вэб это HTML + КОСТЫЛИ …

Ты живешь в каком-то самостоятельно выдуманном мире, не понимаю тебя.

По-твоему это все пилят одни и те же люди? Или хотя бы одни и те же компании? Или хотя бы одни и те же сообщества?

О чем ты вообще?

Казалось бы следующий логичный шаг - вместо node.js запилить node.ts

Я же тебе дал ссылку, на node.ts от создателя самой ноды.

Нужно на JS написать AOT компилятор JS, вот это Ъ.

Но для клиентских веб-приложений, на самом деле скорости js-движков хватает с головой (а мономорфный js-код вовсе не уступает коду на wasm), и быстрее это все равно не будет работать.

только почему-то какое electron-приложение не возьмёшь, с производительностью стабильно какая-то ёбань

А много изменить нельзя. Нет возможности на сайте сделать как с питоном или пхп: объявить последнюю версию интерпретатора поддерживаемой. Поэтому сложно внести много изменений, нарушающих обратную совместимость.

<script type="text/javascript">
/* some code */
</script>

вместо javascript можно было бы писать es6,es7,es2018,es3000 итд и проектировать новую версию в стиле PHP, не боясь сломать обратную совместимость

но вендоры решили решить проблему радикально, что тоже имеет смысл

И поддерживать старые стандарты в движке?

Это сложно, долго и только увеличит размер браузера.

вместо javascript можно было бы писать es6,es7,es2018,es3000

<script type="module">
// этот код выполнится только в браузерах, которые поддерживают es6+
</script>

<script nomodule>
// этот код выполнится только в браузерах, которые не поддерживают es6
</script>

<script>
// этот код выполнится во все браузерах, которые поддерживают js
</script>