Андерс Хейлсберг (Anders Hejlsberg), главный архитектор языка TypeScript, в своё время создавший языки C#, Delphi и Turbo Pascal, представил проект по созданию нового компилятора для TypeScript - typescript-go (tsgo), разрабатываемый на языке Go. Как и старый компилятор новый проект распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62861
`Язык Go близок с TypeScript по семантике и структуре кода`
Что блин?)
Читай "по сравнению с Растом, Лиспом и Брейнфаком..."
что их не устоило в C# так толком и не пояснили
Особо ничем не лучше Джавы и вначале был жёстко привязан к Виндовс
А как пользователям это поставлять? В go они собирут бинарники для всех нужных платформ и засунут в npm пакет.
Точно так же собираешь бинарники с native aot
> Точно так же собираешь бинарники с native aotКакой размер итоговый будет? Что нужно для разработки устанавливать?
> Точно так же собираешь бинарники с native aotНу и еще важный вопрос: как это интегрировать с бандлерами?
> что их не устоило в C# так толком и не пояснилиКого "их"? Чувака, который сам и создал С#?
Вряд ли он просто чего-то не знает...
> Кого "их"?приям в статье говорится что портирует команда из 9 человек.
что, не осилил прочитать статью?> Вряд ли он просто чего-то не знает...
опять же, я не утверждал что чувак чегото не знает.
у меня какраз то притензия что он что-то знает, но не рассказывает.
> приям в статье говорится что портирует команда из 9 человек.Сильно сомневаюсь, что окончательное решение принималось голосованием.
Это зумеры, сэр.
Они думают, что компилятор может написать только на языке с похожей семантикой.Тысячи компиляторов/тоанспиляторов/интерпретаторов на С/++, написанных для чего ни попадя, смотрят на них с недоумением.
> Они думают, что компилятор можно написать только на языке с похожей семантикой.Вряд ли. Если человек садится писать новый язык, то первое, что он узнаёт, когда начинает изучать матчасть -- это lex и yacc. А там уж всё очевидно.
> lex/yaccФу, мерзость. Даже полностью вручную лучше, чем это. Ты будто живёшь в мире, отстающем на 10-20 лет.
Для пирсинга лучше взять любой язык, умеющий в ФП в той или иной степени. Haskell, Ocalm, Rust, Clojure. Да даже, простите, Common Lisp лучше подойдёт.
>> lex/yacc
> Фу, мерзость. Даже полностью вручную лучше, чем это. Ты будто живёшь в
> мире, отстающем на 10-20 лет.Не мерзость, а база. )
> Для пирсинга лучше взять любой язык, умеющий в ФП в той или
> иной степени.Для пирсинга -- лучше обратиться в специализированное заведение. )
> Haskell, Ocalm, Rust, Clojure.
Да ладно, как минимум у трёх из них есть собственные прямые аналоги lex и yacc (а то и не один, как в случае с ocaml). А про кложу я просто не знаю.
В хаскеле на парсерных комбинаторах прикольно делать парсеры. Правда для компилятора наверное всё-таки более классический подход использовал быВ функциональных языках парсить текст всё же удобно. На Лиспе не пробовал, хоть Лисп мне и нравится за красоту, а вот Хаскелл классный
yacc становится серьёзной обузой когда нужны вменяемые сообщения об ошибках.
>Они думают, что компилятор может написать только на языке с похожей семантикой.Нет. Они портируют проект (по стечению обстоятельств являющийся компилятором) с одного языка на другой.
Компилятором?
Разве на выходе не pure-js?
Это тогда уж транспилятор.
Поумничал, да? Транспиляторы - подмножество компиляторов. Алсо, https://github.com/microsoft/TypeScript/tree/main/src/compiler
Не любо - не слушай.
>> Это зумеры, сэр.Вы в курсе, кто такой Андерс Хейлсберг?
> Вы в курсе, кто такой Андерс Хейлсберг?Так для этого ж надо новость читать. Ну его - лучше сразу в комментарии ринуться со своим ценным экспертным мнением.
> Это зумеры, сэр.Андерс Хейлсберг (Anders Hejlsberg) зумер?
Ну не милленниал же, хотя с возрастом и не такое бывает
Удивительно, что находятся люди, которые плюсуют фигню, которую Вы написали. Думаю, что у Anders Hejlsberg чуть больше экспертизы, чем у Вас. Его трудно назвать "зумером"
С Андерсем всё понятно как раз – дяденька хочет поэкспериментировать за счёт MS. Ноль процентов осуждения, сто процентов понимания.Я дал оценку окружающим коллегам, у которых вопросов не возникало.
Не льсти себе, ты не "оценку дал", а продемонстрировал своё неумение читать. Мало того, что ты упустил Андерса, так ты ещё упустил специфику задачи перед ним стоящую. Задача _переписать_ компиль с typescript на что-нибудь побыстрее. Не написать с нуля, а переписать. А вот чтобы переписывать, полезно выбрать язык близкий к тому, на чём уже написано.Или может это не неумение читать? Может ты просто не в теме, и не представляешь себе как такие вещи делаются и с какими проблемами приходится сталкиваться?
> Это зумеры, сэр."Андерс Хейлсберг (Anders Hejlsberg), главный архитектор языка TypeScript, в своё время создавший языки C#, Delphi и Turbo Pascal..."
Главный зумер, да.
Когда человек умеет работать только молотком, все вокруг становится гвоздями.
И при чем тут схожесть и не схожесть языка, на котором будет делаться компилятор, с языком, для которого будет делаться компилятор???
После раста, нода/яваскрипт/тайпскрипт кажется чем-то плюшевым, игрушечным, непродуманным. Например, попробуйте создать TCP-сервер и слушать порт 8000. В нормальных языках/платформах это просто вызов bind/listen и обработка ошибки. Но не в ноде. No, sir. В ноде, чтобы поймать ошибку listen или дождаться ее выполнения, надо:1. Навесить на сервер обработку listening.
2. Навесить на сервер обработку error.
3. Оба обработчика должны сработать лишь один раз (server.once()).
4. Во время listening резольвим промис.
5. Во время error режектим промис.
6. И вот только теперь можно вызывать server.listen().Ощущение, что дизайнер ноды осилил только паттерн event emitter, так что он впендюрил его всюду.
JavaScript гениальный и самый быстрый. Ты просто делаешь что–то не так либо не можешь постичь суть.
> В ноде, чтобы поймать ошибку listen или дождаться ее выполнения, надо:Спешите видеть, разработчик впервые в жизни познает асинхронное программирование без блокировки IO и записывает это в минусы!
Асинхронщина здорового человека:let listener = TcpListener::bind(&addr).await?;
Асинхронщина курильщика:
const { promise, resolve, reject } = Promise.withResolvers();
const handleListening = () => {
server.off("error", handleError);
resolve();
};const handleError = (error) => {
server.off("listening", handleListening);
reject(error);
};server.once("listening", handleListening);
server.once("error", handleError);// Вроде ничего не забыли. И теперь, перекрестясь...
server.listen(port, host);
await promise;
неумение готовить websocket'ы в ноде это, то что отличает "здорового" человека от того, кто умеет:const app = uWS.App().get('/*', () => {}).listen(port, () => {})
И эти люди ругают синтаксис раста...
Здорового -- это тому, кто не париться?
Потому что оно так с node 0.1, где колбэки колбэками погоняли. Легаси, сэр...Всегда обертываю так, чтобы получить api, похожее на то, что в Rust (с библиотекой neverthrow получается очень rust-like). Такую обертку и на npm найти можно, но я не любитель leftpad-ов, мне и самому несложно 10 строк кода написать.
Что случится со здоровым человеком если у него появится ошибка с TcpListener?
вопросик в конце выражения говорит о том, что ошибка будет проброшена наверх по стеку вызовов. но если хотите, можете и тут обработать, разрешаю.
Дальнейший код выполнен не будет, обрати внимание на символ "?" в конце await. В ноде код будет выполняться так, словно ошибки нет, потому что она еще не возникла (возникнет позже).Заходишь на официальный сайт ноды, копируешь хелловорлд из главной страницы, меняешь порт на недопустимый (например 1000, который требует рута) и вставляешь в конце console.log("Этот console.log выполнился даже после того, как нода не смогла забиндиться к порту 1000."). Сделать await не получится, потому что у listen дурацкий апи, возвращающий вместо промиса черт-те что.
Обрати внимание на стектрейс, с какого места падает. Падает с абсолютно нелогичного места в связи с автомагией ноды крашить все приложение, если любой (любой!) event emitter не имеет обработчика error на момент его возникновения.
import { EventEmitter } from "node:events";
const ee = new EventEmitter();
ee.emit("hello");
console.log("Этот console.log() будет выполнен");
ee.emit("error");
console.log("Этот console.log() выполнен НЕ будет: нода за тебя решила, что тут надо грохать сразу весь процесс.");И вот таким образом оформлена вся стд либа ноды. Всюду неприятные сюрпризы, и никогда нет уверенности, что ты подписался на все возможные источники ошибок. Нода -- это современный пхп.
ну пистец какая гениальность.
В нормальном асинхронном программирование код отличается от синхронного только наличием await'ов. А навешивание коллбеков - это даже не программирование вообще, это мастурбация.
api node старше хипстерских await.
> Ощущение, что дизайнер ноды осилил только паттерн event emitter, так что он впендюрил его всюду.Потому что когда в ноде была сеть, в JS ещё не было Promise/async/await
А event emitter удобнее чем колбеки у каждого метода, тем более что не везде эти колбеки относятся к конкретно методу
> После раста, нода/яваскрипт/тайпскрипт кажется чем-то плюшевым, игрушечным, непродуманным.Это ощущение обычно проходит после изучения N-ного языка.
После определённого количества оных в голове, становится очевидным, что языки следует выбирать исходя из задач, для решения которых они созданы, и методика сравнения несколько меняется.
так можно же осознанно и игрушечный язык выбирать там где это уместнее. но от этого он неигрушечным не становится. нет противоречия
> так можно же осознанно и игрушечный язык выбирать там где это уместнее.
> но от этого он неигрушечным не становится. нет противоречияА никто ни про какие противоречия и не говорил.
Проблема тут только в том, что понятие "игрушечности" не определено никак, в отличие от стоимости разработки и стоимости поддержки.
Жабаскрипт, это чтобы анимированные снежинки на веб-страничке были и чтобы в формах автодополнение, а остальное - от лукавого.
Как там в нулевых? Закупай биткоин в конце десятелетия на все деньги.
А после любого языка с GC, Rust чувствуется небезопасным.
Наоборот, в том же go после rust ощущение дискомфортные, потому что помимо очищения непосредственно памяти есть и другие ресурсы. Например, нужно вручную освободить лок, не забыть вручную прописать defer с релизом. Также в рантайме постоянно ловятся проблемы нулевыми указателями. Rust от этого избааляет во время компиляции.
Ну неее.. после дружелюбного ржавого компилятора попробуй написать мультипоточный мемори-сейф код какой-нибудь жабе или шарпах. совсем обратное чувство.
GC -- это иллюзия безопасности. Во-первых, gc сам по себе не избавляет от выхода за границы массива или от разадресации нуля. Единственная задача, которую он гарантированно решает (теоретически), это отсутствие мемликов. Некоторые вещи, относящиеся к safety он делает попроще, по сравнению с каким-нибудь C, но не решает этих проблем. А поскольку gc как правило сочетается с динамической типизацией, то это порождает аж целый новый огромный класс ошибок, которые бьют граблями в рантайме, и поэтому отлов этих ошибок упирается в проблему останова.Штуки типа TypeScript указывают на то, что люди наконец начали понимать, что динамическая типизация отстой, и может у нас появятся хорошие языки с gc без динамической типизации. Но это сложно, потому что gc для своей работы требует информации о типах значений в рантайме, значит динамическая типизация уже как бы есть, и поэтому требуется очень высокий уровень самодисциплины от разработчиков языков, чтобы спрятать эту динамическую типизацию от разработчика.
На js точно так же можно создавать tcp-сервер:
Bun.listen({ port: 8000, socket: { data(socket, data) {}, error(socket, error) {} }});
По легенде Джаваскрипт накожен Бренданом Айком за 10 дней чтобы что-то было. А в итоге вон какую экосистему породил
> После раста, нода/яваскрипт/тайпскрипт кажется чем-то плюшевым, игрушечным, непродуманным. Например, попробуйте создать TCP-сервер и слушать порт 8000. В нормальных языках/платформах это просто вызов bind/listen и обработка ошибки. Но не в ноде. No, sir. В ноде, чтобы поймать ошибку listen или дождаться ее выполнения, надоВо-первых, сранивать язык и платформу не вполне корректно. Во-вторых, это вопрос исключительно апи. Все node, bun и deno скрывают listen где-то под капотом. Видимо так удобнее им. Вряд ли их авторы не понимают bind/listen.
Почему не на Rust?
Потому что семантика раста не похожа на TS, написано же.(почему должна быть похожа – вопрос не ко мне)
Потому что затраты меньше, перепроектировать с нуля с учетом Rust-специфики (нет GC, например) или тупо портировать файл за файлом. И речь не о TS, как языке, а о конкретном коде TS компилятора, который близок к обычному коду на Go.
Затраты на Rust сильно больше и они никогда не окупятся.
Потому, что ни только Раст следит за безопасностью работы с памятью
Но это - другое! Понимать надо! :)
Потому что нет сборщика мусора. А JS - это язык на сборщике мусора.
Наличие сборщика мусора в языке никак не коррелирует с необходимостью наличия сборщика мусора в его компиляторе.
... если сам компилятор не написан на языке со сборкой мусора.
Выбирая Go, мы определенно знали, что будут люди, которые спросят, почему мы не выбрали Rust. Это хороший вопрос, потому что Rust — отличный язык, и, если нет других ограничений, это сильный выбор при написании нового нативного кода.Портируемость (то есть возможность создать новую кодовую базу, алгоритмически похожую на текущую) всегда была ключевым ограничением, когда мы думали о том, как это сделать. Мы перепробовали массу подходов, чтобы получить представление, которое сделало бы этот подход к портированию осуществимым в Rust, но все они либо имели неприемлемые компромиссы (производительность, эргономика и т. д.), либо сводились к стратегиям типа "напиши свой собственный GC". Некоторые из них были близки к цели, но часто требовали использования большого количества небезопасного кода, и, казалось, не существует большого количества комбинаций примитивов в Rust, которые позволили бы эргономично портировать код JavaScript (что неудивительно, если сформулировать это таким образом — большинство языков не считают приоритетом облегчение портирования с JavaScript/TypeScript!).
В конце концов, у нас было два варианта — сделать полный рерайт с нуля на Rust, что могло занять годы и привести к несовместимой версии TypeScript, которую никто не смог бы использовать, или просто сделать порт на Go и получить что-то пригодное для использования примерно через год и иметь что-то чрезвычайно совместимое с точки зрения семантики и чрезвычайно конкурентоспособное с точки зрения производительности.
И даже не совсем ясно, в чем будет преимущество этого (помимо того, что не придется отвечать на множество вопросов "Почему вы не выбрали Rust?"). Мы по-прежнему хотим иметь четко разделенную поверхность API, чтобы наши варианты реализации оставались открытыми, поэтому недостатки Go в плане взаимодействия не имеют особого значения. Go обладает отличной генерацией кода и отличным представлением данных, как и Rust. Go обладает отличными примитивами параллелизма, как и Rust. Производительность на одном ядре находится в пределах погрешности. И хотя можно было бы добиться некоторого прироста производительности, используя небезопасный код в Go, мы получили отличную производительность и использование памяти, не используя никаких небезопасных примитивов.
На наш взгляд, Rust добился огромных успехов в достижении своих целей, но "легкость портирования на Rust с этой конкретной кодовой базы JavaScript" очень рационально не является одной из его целей. Это не является целью и для Go, но в нашем случае, учитывая то, как мы написали код до сих пор, он оказался довольно хорош в этом.
https://www.reddit.com/r/typescript/comments/1j8s467/comment...
Это надо же, они ещё и оправдываться перед фанатиками за то, что их выбор был обусловлен не трендами и личными предпочтениями, а, прости Господи, техническими и экономическими ограничениями
По тому, что задача "написания компилятора" по своим НФТ\ограничениям не относится к задачам "системного программирования" в чистом виде - тут у тебя нет долгоиграющих процессов, обрабатывающих недоверенные данные из внешних источников с ограничениями по производительности, не позволяющими использовать GC.
> Почему не на Rust?Даже Андерс Хейлсберг его не смог осилить.
Ехал Тайпскрипт через Джаваскрипт, который ехал через плюсы, а теперь ехал тайпскрипт через гошечку, чтобы ехать через джаваскрипт, чтобы ехать на плюсах.
В итоге оверхед оверхедом погоняет на всех этапах разработки.
Как раз часть оверхеда убирают.
дааа? и каким же образом?
В новости написано.
...взамен добавляя ненужную сложность в разработку.
А могли бы wasm'ом пользоваться, а не костыли городить вокруг медленного джаваскрипта. Сколько его не ускоряй, а динамическая типизация не сделает его компилируемым языком.
Сколько десятилетии прошло, а всё ругают "медленный" Джаваскрипт. Да он побыстрее ваших ПитоновДжав будет!
и всё это при разработке парсит IDE на джаве, которая на плюсах
Ну ладно IDE, оно, как говорится, выполняет свою, особую задачу, но сам TypeScript и его поддержка становится тем ещё весельем.
То есть, нужно знать JavaScript, TypeScript, Go, чтобы компилятор работал, не говоря уже о знаниях компиляции. А ещё надо знать то, как именно Хром, Лиса и Сафари этот самый джаваскрипт исполняют, а это требует знание C++, потому что разные реализации имеют разные баги, лол.
В итоге проект для глубокого понимания без появления ошибок в процессе требует профессионального знания всех четырёх языков. А теперь найдите мне такого специалиста, который это умеет, может, практикует вместе с компиляторостроением.
И не говорите! Безумие какое-то! Ведь никто другой не пишет для своего языка компиляторов на C++, не использует в своей писанине ассемблерных вставок, не транслирует это писево в "промежуточное представление на языке C", не требует изучения каких-то особых языков для сборки проекта, не...
Oh, shi! Да это же ДРУГОЕ!!!
> we’ve begun work on a native port of the TypeScript compiler and tools.Из оригинальной новости
А там ниже еще процессор где CISC транслируется в RISC.
В жизни бы не стал писать компиляторы на го. Он же совсем к этому не приспособлен. Неудобно. На окамле самое то.
ANTLR4+Go вполне удобен
> На окамле самое то.Интересно увидеть сравнения производительности нового typescript-go с flow.
А изначально вроде ts (strada) был на f#? По крайей мере один из разработчиков был разработчиком f# как гласит Википедия. А ранние версии https://github.com/microsoft/TypeScript-DOM-lib-generator были на f# (можно посмотреть по истории).
Что значит удобно? Это не технический параметр. Я могу понять вот на языке Х компилятор пишется за Y дней/часов/лет, а на языке Z за Y*N дней/часов/лет. А что такое удобно мне лично не понятно.
Любой компилятор по факту работает рекурсивно с деревьями. В функциональных языках, где есть паттерн матчинг это гораздо удобнее делать.
Легко можно описывать на уровне типов структуру ast и потом это всё разворачивать и рабоать с этим. Со всеми гарантиями, что ты обработал все варианты. Как без вменяемых алгебраических типов данных работать с этим я не представляю.
Промазал. Это ответ BeLord-у
Самое забавное что именно на Rust пересели большинство трансплайлеров, билдеров, линтеров и т.п. в мире Typescript.Решение крайне сомнительное.
Просто сигма-чад архитектор тайпскрипта показал всем этим задавакам с растом где их место.
Что то (наверное жизненный опыт?) мне подсказывает что такого уровня людям ... им "с прибором" на мнения за бортом, он "сам себе энциклопедия" :)
Он кстати может и на расте сделать, если ему будет интересно.PS: Если бы все ржавчики были Андерсами Хейлсбергами ... я бы наверное сильно больше времени на раст тратил бы :)
PPS: Всё равно новость не в тренде :) Какое то чуйство что нам не всё сказали :)))
Когда программистам делать нечего, они проекты переписывают на другом языке.
Там не переписывание с нуля, а скорее прямая трансляция с целью повышения производительности. Большинство кода строчка к строчке совпадает, код просто транслирован в другой синтаксис.
Им надо было транспайлер писать. Заодно избавили бы мир от ноде.жс
Наконец-то Hugo для замороченных тем не будет тащить npm
Выглядит как жирный плевок в сторону C#
Даже внутри Майкрософт с шарпом все ясно.
неужели ты залез внутрь? и как там в aнусе?
а вот портанули бы MAUI на линух, всё было бы кучеряво
>Go ближе к TypeScript по семантике и структуре кода, что позволяет сохранить при портировании существующие шаблоныПри этом в оригинальном видео вообще нет примеров, только два экрана с простыней if'ов, которые можно точно так же на любом языке переписать.
И кстати почему не на C#?
Для господ, которым лень переходить по ссылкам:>[оверквотинг удален]
>> This choice is basically a language preference of Typescript team and also an attempt to please the ts/js community which cheers adoption of Rust / Go in js tooling.
>> My opinion is that C# ticks all the boxes and would do a better job than Go.
>> But TS team acknowledged they would be better Go developers than they would be C# developers.
>> They want to build this with TS / JS community not with .NET Community.
>> Also, there was an issue with their justification:
>> They shouldn't have said C# is sub-par, but they should have been honest:
>> We think we are better Go developers and we like Go more than C#. And I think that would have been acceptable.
>> Trying to justify with technical arguments that don't hold, pisses some C#/.NET old timers.
>> Overall Go is not a bad choice, but I believe you would have achieved same or better results with C# if you opted for it.
>> Also I think C#/.NET teams would have happily cleared any bumps in your way.
Это рассуждения мимокрокодила, а не официальная позиция.
Да, был не прав, сорян. Выглядело так, будто он разбирается.
OOP
cross-platform issues
shared memory concurrency
Полностью верное и безоговорочно правильное решение.
глупости. нужно было сразу сделать альтернативу typescript, который сам по себе не нужон
Java надо было.
Не надо.
>Java надо было.20 лет назад. А теперь - не факт.
Да это просто Майкрософт и Гугл друг другу подлизывают, чтобы вместе двигать свой корпоративный Rust.Это чисто политика, тут нет никакой другой реальной причины, а все заявленные - обыкновенный лживый предлог.
А миром правят масоны
Автор C#, который Хейлсберг, будучи и автором TS сам принял решение переписать на go. Люди на гитхабе в афиге, Хейлсберг оправдывается, что это не навязанное решение, а они так решили — говорит в варианте «начнём портирование один-к-одному с минимумом переписывания» го им подошла больше, при этом в отличие от питона получили не замедление, а ускорение (правда всего 3x и больше за счёт многопоточности).
Раст отмели, поскольку пришлось бы переделать всё. Почему отмели дотнет — непонятно, на многословность не спишешь, а вот по производительности потеряли прилично. Злые языки говорят, что мс сейчас под теми же людьми, что и гугель и начальство будет планомерно внедрять общие зонды, сам де дотнет привычным к яве индусам не интересен.
привычным к яве индусам и голагне с тупоскриптом не интересны, ты выдыхай уже
Точно, на презентации Хейлсберг часто моргает, наверняка индусы взяли его в заложники и заставляют переписывать на go.
Индусы заставляют его переписывать, чтобы он заставлял переписывать индусов и таким образом стимулируют экономическое развитие Индии, чтобы Индия ставила палки в колеса Китаю
> чтобы Индия ставила палки в колеса КитаюПонятно теперь почему го: много китайских проектов пишут на расте.
Я правильно понял, что npm install typescript теперь будет либо качать непонятный блоб с go с домашней странички какого-нибудь анонима из микрософт, либо качать исходники go и компилировать его?
Ещё один стал о чем-то догадываться.
Просто уже собранные бинари как делает flow на ocaml.
Сначала, вместо того чтобы писать на JavaScript, но при этом отработать зарплату, придумали TypeScript. Теперь парят всем мозг с требованием переделать компилятор, чтобы продолжить генерировать JavaScript и продолжить получать зарплату. А ведь могли просто писать на JavaScript!
Чего только не придумаешь, лишь бы ничего не делать... и получать зарплату.
Кому - всем? От кого требуют? Как много вопросов и как мало ответов.
Отиличное решение, а когда закончите перепишите Go на TypeScript...
Остался один шаг чтобы понять, что Typescript - вообще не нужен.
Нет, вот он как-раз таки нужен. Если тебе интересно комментарии писать вместо типов - пиши
Для таких целей прекрасно подойдёт ocaml, reasonml, rescript, выбирай по вкусу
Нативная поддержка тайпскрипта должна появится в браузерах.
почему ещё не сделал?
Так дорогой давай стандарт для начала. Вот у JavaScript он есть. Правда не американских браузеров нет, но все-же.
Давно не следил за этим болотом, но если не ошибаюсь, там речь шла не про поддержку TS в браузере, а поддержку статичной типизации в ванильном js, что сделает ненужным TS в принципе.
> поддержку статичной типизации в ванильном jsВроде как собираются добавить поддержку указания типов и их игнор в рантайме по аналогии с аннотациями типов в питоне.
Так у JS нет не рантайма, он же не компилируемый. А аннотации, так это же уже было в flow. Так и в чём смысл, если просто будет происходить затирание аннотаций, как в "компиляторе" flow или просто игнор в рантайме, это же не повлияет на отлов ошибок. А вот TypeScript, если убрать из него Any как раз позволяет добавить статическую типизацию поверх динамического языка.
Хотели сказать нативная поддержка go?
Меня лично устраивает текущий TypeScript
Ой. Ну тогда срочно отменяем все.
сначала typescript на go, потом go на typescript, а там глядишь сделают rustoscript с nodecargo
конечно сделают, причём 100500 различных вариаций, другим способом безработицу не победить
>Андерс ХейлсбергУченик Никлауса Вирта. Если Майкрософт именно его задействовал, то это серъёзно. Очень серъёзно.
Мда, а свой же .net с native aot даже не рассмотрели
Скорее всего потому, что размер транспилятора получился бы огромным из-за рантайма навороченного и большой BCL. Даже с trim’ом.Тот случай, когда инструмент подбирают под задачу, а не из фанатизма.
По-моему это победа Go.
Компилятор для языка на другом языке? Это все, что нужно знать про язык.Лучше уж вскод переписали бы тогда.
По-вашему, какой-нибудь gfortran следует писать на фортране?
Да. Это же не интерпретатор, к нему и требования соответствующие.Если он не может решить эту задачу, тогда зачем его вообще рассматривать вместо:
- Go.
- C.
- Cpp.
- C#.
- Rust.
Потому что TS создавался для удобного написания другого класса программ? Не?
Ну как скажешь! :)
Ну, доверие это точно подрывает.Кстати, у них в полиси написано, что никакие оптимизации они не вкручивают в него и не планируют, это полностью на плечах v8.
Так что фактически это тулза для ide. И, справедливости ради, там это реально помогает.
Хотя, некоторые вообще съезжают с него. https://www.opennet.dev/opennews/art.shtml?num=59729
Думаю, с развитием ecma спецификации, сие поделие можно будет в мусорку отправить.
Теперь осталось выкинуть typescript не только из компилятора, но и из другх мест, куда его успели внедрить
> Исходный компилятор TypeScript написан на языке TypeScript и транслируется в JavaScript,
> что создаёт проблемы с масштабированием при использовании в очень больших проектах.Может, им просто на Go перейти всей толпой и не заниматься - вон тем?