The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Microsoft переписывает компилятор TypeScript на языке Go

12.03.2025 08:06

Андерс Хейлсберг (Anders Hejlsberg), главный архитектор языка TypeScript, в своё время создавший языки C#, Delphi и Turbo Pascal, представил проект по созданию нового компилятора для TypeScript - typescript-go (tsgo), разрабатываемый на языке Go. Как и старый компилятор новый проект распространяется под лицензией Apache 2.0.

Исходный компилятор TypeScript написан на языке TypeScript и транслируется в JavaScript, что создаёт проблемы с масштабированием при использовании в очень больших проектах. Разработчикам приходится мириться с большими задержками при загрузке и проверке кода в интегрированных средах разработки, и жертвовать удобством разработки в пользу сокращения задержек, отключая в редакторах возможности для проверки кода. В экосистеме также назрела потребность в инструментарии командной строки, позволяющем быстро собирать код для проверки его работоспособности.

Предполагается, что создание нативного компилятора и инструментария для TypeScript существенно увеличит скорость сборки, уменьшит потребление памяти и сократит время запуска редакторов кода. Высокая производительность инструментария сделает более удобным процесс разработки в современных редакторах кода, позволит добиться быстрой проверки кода всего проекта, даст возможность реализовать более продвинутые техники рефакторинга и анализа кода, включение которых раньше было слишком затратно в плане потребления ресурсов.

По оценке разработчиков TypeScript, новый инструментарий позволит добиться сокращения времени сборки на порядок. В текущем виде новый вариант компилятора tsc обрабатывает кодовую базу проекта VS Code за 7.5 секунд, в то время как старому компилятору для этой операции требовалось 77.8 секунд. В случае с кодовой базой Playwright загрузка сократилась с 11.1 до 1.1 сек., TypeORM - с 17.5 до 1.3 сек., date-fns с 6.5 до 0.7 сек., tRPC с 5.5 до 0.6 сек., а rxjs c 1.1 до 0.1 сек.

Разработка нового компилятора ведётся с октября 2024 года командой из 9 сотрудников Microsoft. На текущем этапе для тестирования уже доступен рабочий прототип. Предварительную версию инструментария командной строки с новой реализацией tsc, поддерживающей проверку типов, планируют опубликовать до середины года. Выпуск первой полнофункциональной версии, способной собирать проекты и предоставлять LSP-сервисы для сред разработки, намечен к концу года.

Ветка TypeScript 6.x продолжит поставляться со старым компилятором и будет включать отдельные изменения для подготовки к миграции на новую реализацию. Первым выпуском, переведённым на новый инструментарий, станет TypeScript 7. Какое-то время кодовые базы TypeScript 6.x и TypeScript 7.x будут параллельно сопровождаться и сосуществовать, пока ветка TypeScript 7 не достигнет зрелого состояния, готового полностью заменить старый инструментарий.

Перед началом работы над проектом разработчики изучили возможность использования различных языков программирования и поэкспериментировали с прототипами на разных языках. В итоге для создания нового компилятора был выбран язык Go, как оптимальный вариант для выполнения работы по переписыванию кодовой базы старого компилятора. По сравнению с такими языками, как Rust, Go ближе к TypeScript по семантике и структуре кода, что позволяет сохранить при портировании существующие шаблоны. Использование Go упрощает перенос изменений между кодовыми базами и снижает трудоёмкость задачи по сопровождению старого и нового вариантов бок о бок.

Язык Go обеспечивает хорошую производительность, развивается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах, имеет встроенные средства защиты от проблем при работе с памятью. Ценой безопасной работы с памятью является сборщик мусора, который может приводить к появлению задержек во время работы, но для компилятора появление таких задержек не имеет значения.

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

Язык TypeScript расширяет возможности JavaScript, оставаясь полностью обратно совместимым, что упрощает перевод на TypeScript существующих приложений. Итоговое приложение на TypeScript компилируется в обычный JavaScript, который можно выполнить в любом современном web-браузере или использовать c платформами Node.js, Bun и Deno. От JavaScript язык TypeScript отличается средствами для явного определения типов, а также поддержкой использования полноценных классов и модулей. Статическая типизация позволяет избежать многих ошибок в процессе разработки, даёт возможность задействовать дополнительные техники оптимизации, упрощает отладку, делает код более читаемым и простым для доработки и сопровождения.

  1. Главная ссылка к новости (https://devblogs.microsoft.com...)
  2. OpenNews: Опубликована платформа Node.js 23.0 с начальной поддержкой языка TypeScript
  3. OpenNews: Предложен компилятор исходных текстов на языке TypeScript в машинный код
  4. OpenNews: Доступен язык TypeScript 2.0, продвигаемый Microsoft в качестве дополнения к JavaScript
  5. OpenNews: Компания Microsoft представила TypeScript, новую открытую альтернативу JavaScript
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/62861-typescript
Ключевые слова: typescript, microsoft, golang
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (112) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:54, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    'Язык Go близок с TypeScript по семантике и структуре кода'
    Что блин?)
     
     
  • 2.2, тоже Аноним (ok), 09:58, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +19 +/
    Читай "по сравнению с Растом, Лиспом и Брейнфаком..."
     
     
  • 3.76, Советский инженер (ok), 13:41, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    что их не устоило в C# так толком и не пояснили
     
     
  • 4.105, Аноним (105), 15:57, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Особо ничем не лучше Джавы и вначале был жёстко привязан к Виндовс
     
  • 4.116, Нуину (?), 17:39, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А как пользователям это поставлять? В go они собирут бинарники для всех нужных платформ и засунут в npm пакет.
     
  • 4.121, тоже Аноним (ok), 17:49, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > что их не устоило в C# так толком и не пояснили

    Кого "их"? Чувака, который сам и создал С#?
    Вряд ли он просто чего-то не знает...

     
  • 2.12, Карлос Сношайтилис (ok), 10:17, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это зумеры, сэр.
    Они думают, что компилятор может написать только на языке с похожей семантикой.

    Тысячи компиляторов/тоанспиляторов/интерпретаторов на С/++, написанных для чего ни попадя, смотрят на них с недоумением.

     
     
  • 3.15, freehck (ok), 10:22, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Они думают, что компилятор можно написать только на языке с похожей семантикой.

    Вряд ли. Если человек садится писать новый язык, то первое, что он узнаёт, когда начинает изучать матчасть -- это lex и yacc. А там уж всё очевидно.

     
     
  • 4.56, Анонимъ (-), 12:07, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > lex/yacc

    Фу, мерзость. Даже полностью вручную лучше, чем это. Ты будто живёшь в мире, отстающем на 10-20 лет.

    Для пирсинга лучше взять любой язык, умеющий в ФП в той или иной степени. Haskell, Ocalm, Rust, Clojure. Да даже, простите, Common Lisp лучше подойдёт.

     
     
  • 5.74, freehck (ok), 13:29, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> lex/yacc
    > Фу, мерзость. Даже полностью вручную лучше, чем это. Ты будто живёшь в
    > мире, отстающем на 10-20 лет.

    Не мерзость, а база. )

    > Для пирсинга лучше взять любой язык, умеющий в ФП в той или
    > иной степени.

    Для пирсинга -- лучше обратиться в специализированное заведение. )

    > Haskell, Ocalm, Rust, Clojure.

    Да ладно, как минимум у трёх из них есть собственные прямые аналоги lex и yacc (а то и не один, как в случае с ocaml). А про кложу я просто не знаю.

     
     
  • 6.89, Аннноним (?), 14:49, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В хаскеле на парсерных комбинаторах прикольно делать парсеры. Правда для компилятора наверное всё-таки более классический подход использовал бы

    В функциональных языках парсить текст всё же удобно. На Лиспе не пробовал, хоть Лисп мне и нравится за красоту, а вот Хаскелл классный

     
  • 3.28, Аноним (28), 10:55, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Они думают, что компилятор может написать только на языке с похожей семантикой.

    Нет. Они портируют проект (по стечению обстоятельств являющийся компилятором) с одного языка на другой.

     
     
  • 4.34, Жироватт (ok), 11:24, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Компилятором?
    Разве на выходе не pure-js?
    Это тогда уж транспилятор.
     
     
  • 5.45, Аноним (45), 11:50, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Поумничал, да? Транспиляторы - подмножество компиляторов. Алсо, https://github.com/microsoft/TypeScript/tree/main/src/compiler
     
     
  • 6.65, Жироватт (ok), 12:40, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Не любо - не слушай.
     
  • 3.36, Аноним (36), 11:28, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +15 +/
    >> Это зумеры, сэр.

    Вы в курсе, кто такой Андерс Хейлсберг?

     
     
  • 4.42, Аноним (42), 11:45, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Вы в курсе, кто такой Андерс Хейлсберг?

    Так для этого ж надо новость читать. Ну его - лучше сразу в комментарии ринуться со своим ценным экспертным мнением.

     
  • 3.111, Нуину (?), 17:09, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Это зумеры, сэр.

    Андерс Хейлсберг (Anders Hejlsberg) зумер?

     
  • 3.112, nw (?), 17:10, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Удивительно, что находятся люди, которые плюсуют фигню, которую Вы написали. Думаю, что у Anders Hejlsberg чуть больше экспертизы, чем у Вас. Его трудно назвать "зумером"
     
  • 2.50, Аноним (50), 12:00, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Когда человек умеет работать только молотком, все вокруг становится гвоздями.
     

  • 1.3, Аноним (3), 10:01, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    После раста, нода/яваскрипт/тайпскрипт кажется чем-то плюшевым, игрушечным, непродуманным. Например, попробуйте создать TCP-сервер и слушать порт 8000. В нормальных языках/платформах это просто вызов bind/listen и обработка ошибки. Но не в ноде. No, sir. В ноде, чтобы поймать ошибку listen или дождаться ее выполнения, надо:

    1. Навесить на сервер обработку listening.
    2. Навесить на сервер обработку error.
    3. Оба обработчика должны сработать лишь один раз (server.once()).
    4. Во время listening резольвим промис.
    5. Во время error режектим промис.
    6. И вот только теперь можно вызывать server.listen().

    Ощущение, что дизайнер ноды осилил только паттерн event emitter, так что он впендюрил его всюду.

     
     
  • 2.5, Аноним (5), 10:03, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • –15 +/
    JavaScript гениальный и самый быстрый. Ты просто делаешь что–то не так либо не можешь постичь суть.
     
  • 2.8, Аноним (8), 10:12, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В ноде, чтобы поймать ошибку listen или дождаться ее выполнения, надо:

    Спешите видеть, разработчик впервые в жизни познает асинхронное программирование без блокировки IO и записывает это в минусы!

     
     
  • 3.20, Аноним (3), 10:35, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Асинхронщина здорового человека:

        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;

     
     
  • 4.30, Аноним (30), 11:02, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    неумение готовить websocket'ы в ноде это, то что отличает "здорового" человека от того, кто умеет:

    const app = uWS.App().get('/*', () => {}).listen(port, () => {})

     
     
  • 5.107, Карлос Сношайтилис (ok), 16:37, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И эти люди ругают синтаксис раста...
     
  • 4.43, _hide_ (ok), 11:49, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Здорового -- это тому, кто не париться?
     
  • 4.87, Аноним (87), 14:40, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Потому что оно так с node 0.1, где колбэки колбэками погоняли. Легаси, сэр...

    Всегда обертываю так, чтобы получить api, похожее на то, что в Rust (с библиотекой neverthrow получается очень rust-like). Такую обертку и на npm найти можно, но я не любитель leftpad-ов, мне и самому несложно 10 строк кода написать.

     
  • 4.90, cheburnator9000 (ok), 14:57, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Что случится со здоровым человеком если у него появится ошибка с TcpListener?
     
     
  • 5.99, Вася Пупкин (?), 15:33, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    вопросик в конце выражения говорит о том, что ошибка будет проброшена наверх по стеку вызовов. но если хотите, можете и тут обработать, разрешаю.
     
  • 5.104, Аноним (3), 15:53, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Дальнейший код выполнен не будет, обрати внимание на символ в конце await В... большой текст свёрнут, показать
     
  • 3.78, Аноним (78), 13:47, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В нормальном асинхронном программирование код отличается от синхронного только наличием await'ов. А навешивание коллбеков - это даже не программирование вообще, это мастурбация.
     
     
  • 4.109, Аноним (109), 16:47, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    api node старше хипстерских await.
     
  • 2.22, morphe (?), 10:39, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ощущение, что дизайнер ноды осилил только паттерн event emitter, так что он впендюрил его всюду.

    Потому что когда в ноде была сеть, в JS ещё не было Promise/async/await

    А event emitter удобнее чем колбеки у каждого метода, тем более что не везде эти колбеки относятся к конкретно методу

     
  • 2.41, freehck (ok), 11:41, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > После раста, нода/яваскрипт/тайпскрипт кажется чем-то плюшевым, игрушечным, непродуманным.

    Это ощущение обычно проходит после изучения N-ного языка.

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

     
     
  • 3.101, Вася Пупкин (?), 15:36, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    так можно же осознанно и игрушечный язык выбирать там где это уместнее. но от этого он неигрушечным не становится. нет противоречия
     
     
  • 4.113, freehck (ok), 17:11, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > так можно же осознанно и игрушечный язык выбирать там где это уместнее.
    > но от этого он неигрушечным не становится. нет противоречия

    А никто ни про какие противоречия и не говорил.

    Проблема тут только в том, что понятие "игрушечности" не определено никак, в отличие от стоимости разработки и стоимости поддержки.

     
  • 2.52, al (??), 12:04, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Жабаскрипт, это чтобы анимированные снежинки на веб-страничке были и чтобы в формах автодополнение, а остальное - от лукавого.
     
     
  • 3.91, Сталин (?), 14:57, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как там в нулевых? Закупай биткоин в конце десятелетия на все деньги.
     
  • 2.59, Аноним (59), 12:20, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А после любого языка с GC, Rust чувствуется небезопасным.
     
     
  • 3.92, Аноним (92), 15:00, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Наоборот, в том же go после rust ощущение дискомфортные, потому что помимо очищения непосредственно памяти есть и другие ресурсы. Например, нужно вручную освободить лок, не забыть вручную прописать defer с релизом. Также в рантайме постоянно ловятся проблемы нулевыми указателями. Rust от этого избааляет во время компиляции.
     
  • 3.102, Вася Пупкин (?), 15:38, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну неее.. после дружелюбного ржавого компилятора попробуй написать мультипоточный мемори-сейф код какой-нибудь жабе или шарпах. совсем обратное чувство.
     
  • 2.84, Вездеход (?), 14:20, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    На js точно так же можно создавать tcp-сервер:
    Bun.listen({ port: 8000, socket: { data(socket, data) {}, error(socket, error) {} }});
     
  • 2.88, Аннноним (?), 14:47, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    По легенде Джаваскрипт накожен Бренданом Айком за 10 дней чтобы что-то было. А в итоге вон какую экосистему породил
     
  • 2.117, Нуину (?), 17:45, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > После раста, нода/яваскрипт/тайпскрипт кажется чем-то плюшевым, игрушечным, непродуманным. Например, попробуйте создать TCP-сервер и слушать порт 8000. В нормальных языках/платформах это просто вызов bind/listen и обработка ошибки. Но не в ноде. No, sir. В ноде, чтобы поймать ошибку listen или дождаться ее выполнения, надо

    Во-первых, сранивать язык и платформу не вполне корректно. Во-вторых, это вопрос исключительно апи. Все node, bun и deno скрывают listen где-то под капотом. Видимо так удобнее им. Вряд ли их авторы не понимают bind/listen.

     

  • 1.4, Аноним (4), 10:03, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Почему не на Rust?
     
     
  • 2.14, Карлос Сношайтилис (ok), 10:20, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что семантика раста не похожа на TS, написано же.

    (почему должна быть похожа – вопрос не ко мне)

     
     
  • 3.25, Anonim (??), 10:49, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что затраты меньше, перепроектировать с нуля с учетом Rust-специфики (нет GC, например) или тупо портировать файл за файлом. И речь не о TS, как языке, а о конкретном коде TS компилятора, который близок к обычному коду на Go.
     
     
  • 4.48, Аноним (48), 11:53, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Затраты на Rust сильно больше и они никогда не окупятся.
     
  • 2.16, Аноним (16), 10:22, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Потому, что ни только Раст следит за безопасностью работы с памятью
     
     
  • 3.119, _ (??), 17:48, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Но это - другое! Понимать надо! :)
     
  • 2.33, Аноним (33), 11:19, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Потому что нет сборщика мусора. А JS - это язык на сборщике мусора.
     
     
  • 3.79, Аноним (78), 13:48, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наличие сборщика мусора в языке никак не коррелирует с необходимостью наличия сборщика мусора в его компиляторе.
     
  • 2.62, Аноним (62), 12:27, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Выбирая Go, мы определенно знали, что будут люди, которые спросят, почему мы не ... большой текст свёрнут, показать
     
  • 2.96, User (??), 15:27, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    По тому, что задача "написания компилятора" по своим НФТ\ограничениям не относится к задачам "системного программирования" в чистом виде - тут у тебя нет долгоиграющих процессов, обрабатывающих недоверенные данные из внешних источников с ограничениями по производительности, не позволяющими использовать GC.
     
  • 2.118, Нуину (?), 17:46, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему не на Rust?

    Даже Андерс Хейлсберг его не смог осилить.

     

  • 1.6, Bottle (?), 10:06, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Ехал Тайпскрипт через Джаваскрипт, который ехал через плюсы, а теперь ехал тайпскрипт через гошечку, чтобы ехать через джаваскрипт, чтобы ехать на плюсах.
    В итоге оверхед оверхедом погоняет на всех этапах разработки.
     
     
  • 2.9, Аноним (9), 10:13, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз часть оверхеда убирают.
     
     
  • 3.11, 12yoexpert (ok), 10:14, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    дааа? и каким же образом?
     
     
  • 4.13, Аноним (9), 10:18, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В новости написано.
     
  • 4.122, _ (??), 17:50, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ты дeбiл? А ну да ... :)
     
  • 3.71, Bottle (?), 13:07, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ...взамен добавляя ненужную сложность в разработку.
    А могли бы wasm'ом пользоваться, а не костыли городить вокруг медленного джаваскрипта. Сколько его не ускоряй, а динамическая типизация не сделает его компилируемым языком.
     
  • 2.10, 12yoexpert (ok), 10:13, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    и всё это при разработке парсит IDE на джаве, которая на плюсах
     
     
  • 3.73, Bottle (?), 13:17, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну ладно IDE, оно, как говорится, выполняет свою, особую задачу, но сам TypeScript и его поддержка становится тем ещё весельем.
    То есть, нужно знать JavaScript, TypeScript, Go, чтобы компилятор работал, не говоря уже о знаниях компиляции. А ещё надо знать то, как именно Хром, Лиса и Сафари этот самый джаваскрипт исполняют, а это требует знание C++, потому что разные реализации имеют разные баги, лол.
    В итоге проект для глубокого понимания без появления ошибок в процессе требует профессионального знания всех четырёх языков. А теперь найдите мне такого специалиста, который это умеет, может, практикует вместе с компиляторостроением.
     
     
  • 4.100, User (??), 15:34, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    И не говорите! Безумие какое-то! Ведь никто другой не пишет для своего языка компиляторов на C++, не использует в своей писанине ассемблерных вставок, не транслирует это писево в "промежуточное представление на языке C", не требует изучения каких-то особых языков для сборки проекта, не...
    Oh, shi! Да это же ДРУГОЕ!!!
     
  • 2.24, нейм (?), 10:46, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > we’ve begun work on a native port of the TypeScript compiler and tools.

    Из оригинальной новости

     
  • 2.29, Минона (ok), 10:58, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А там ниже еще процессор где CISC транслируется в RISC.
     
  • 2.70, mos87 (ok), 13:06, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Пусть учат абезян кодить на Ассемблере - а потом из него транслировать в JS. Воть.
     

  • 1.17, Аноним (17), 10:26, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В жизни бы не стал писать компиляторы на го. Он же совсем к этому не приспособлен. Неудобно. На окамле самое то.
     
     
  • 2.58, Ъ (?), 12:14, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ANTLR4+Go вполне удобен
     
  • 2.120, Нуину (?), 17:49, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > На окамле самое то.

    Интересно увидеть сравнения производительности нового typescript-go с flow.

    А изначально вроде ts (strada) был на f#? По крайей мере один из разработчиков был разработчиком f# как гласит Википедия. А ранние версии https://github.com/microsoft/TypeScript-DOM-lib-generator были на f# (можно посмотреть по истории).

     

  • 1.19, Витюшка (?), 10:28, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Самое забавное что именно на Rust пересели большинство трансплайлеров, билдеров, линтеров и т.п. в мире Typescript.

    Решение крайне сомнительное.

     
     
  • 2.21, нейм (?), 10:38, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Просто сигма-чад архитектор тайпскрипта показал всем этим задавакам с растом где их место.
     

  • 1.23, Аноним (23), 10:45, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Когда программистам делать нечего, они проекты переписывают на другом языке.
     
     
  • 2.27, Аноним (27), 10:55, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там не переписывание с нуля, а скорее прямая трансляция с целью повышения производительности. Большинство кода строчка к строчке совпадает, код просто транслирован в другой синтаксис.
     
     
  • 3.39, Аноним (28), 11:38, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Им надо было транспайлер писать. Заодно избавили бы мир от ноде.жс
     

  • 1.26, Аноним (26), 10:53, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Наконец-то Hugo для замороченных тем не будет тащить npm
     
  • 1.35, turbo2001 (ok), 11:25, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Выглядит как жирный плевок в сторону C#
     
     
  • 2.46, Аноним (48), 11:52, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Даже внутри Майкрософт с шарпом все ясно.
     
     
  • 3.53, Аноним (53), 12:05, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    неужели ты залез внутрь? и как там в aнусе?
     
  • 3.67, Аноним (26), 12:44, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а вот портанули бы MAUI на линух, всё было бы кучеряво
     

  • 1.37, Аноним (37), 11:33, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Go ближе к TypeScript по семантике и структуре кода, что позволяет сохранить при портировании существующие шаблоны

    При этом в оригинальном видео вообще нет примеров, только два экрана с простыней if'ов, которые можно точно так же на любом языке переписать.

    И кстати почему не на C#?

     
     
  • 2.40, Аноним (36), 11:38, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Для господ, которым лень переходить по ссылкам gt оверквотинг удален ... большой текст свёрнут, показать
     
     
  • 3.51, turbo2001 (ok), 12:03, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это рассуждения мимокрокодила, а не официальная позиция.
     
     
  • 4.63, Аноним (36), 12:37, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, был не прав, сорян. Выглядело так, будто он разбирается.
     
  • 2.75, Аноним (75), 13:29, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    OOP
    cross-platform issues
    shared memory concurrency
     

  • 1.44, Аноним (48), 11:50, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Полностью верное и безоговорочно правильное решение.
     
     
  • 2.55, Аноним (53), 12:06, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    глупости. нужно было сразу сделать альтернативу typescript, который сам по себе не нужон
     

  • 1.54, Аноним (54), 12:06, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Java надо было.
     
     
  • 2.80, Аноним (78), 13:50, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не надо.
     
  • 2.123, _ (??), 17:55, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Java надо было.

    20 лет назад. А теперь - не факт.

     

  • 1.57, Аноним (57), 12:10, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Да это просто Майкрософт и Гугл друг другу подлизывают, чтобы вместе двигать свой корпоративный Rust.

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

     
  • 1.60, Аноним (60), 12:24, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Автор C#, который Хейлсберг, будучи и автором TS сам принял решение переписать на go. Люди на гитхабе в афиге, Хейлсберг оправдывается, что это не навязанное решение, а они так решили — говорит в варианте «начнём портирование один-к-одному с минимумом переписывания» го им подошла больше, при этом в отличие от питона получили не замедление, а ускорение (правда всего 3x и больше за счёт многопоточности).
    Раст отмели, поскольку пришлось бы переделать всё. Почему отмели дотнет — непонятно, на многословность не спишешь, а вот по производительности потеряли прилично. Злые языки говорят, что мс сейчас под теми же людьми, что и гугель и начальство будет планомерно внедрять общие зонды, сам де дотнет привычным к яве индусам не интересен.
     
     
  • 2.66, Аноним (26), 12:43, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    привычным к яве индусам и голагне с тупоскриптом не интересны, ты выдыхай уже
     
  • 2.114, Нуину (?), 17:14, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Точно, на презентации Хейлсберг часто моргает, наверняка индусы взяли его в заложники и заставляют переписывать на go.
     

  • 1.64, Аноним (64), 12:38, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я правильно понял, что npm install typescript теперь будет либо качать непонятный блоб с go с домашней странички какого-нибудь анонима из микрософт, либо качать исходники go и компилировать его?
     
     
  • 2.98, Аноним (48), 15:28, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё один стал о чем-то догадываться.
     

  • 1.68, Аноним (68), 12:46, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сначала, вместо того чтобы писать на JavaScript, но при этом отработать зарплату, придумали TypeScript. Теперь парят всем мозг с требованием переделать компилятор, чтобы продолжить генерировать JavaScript и продолжить получать зарплату. А ведь могли просто писать на JavaScript!
    Чего только не придумаешь, лишь бы ничего не делать... и получать зарплату.
     
     
  • 2.85, Аноним (45), 14:21, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кому - всем? От кого требуют? Как много вопросов и как мало ответов.
     

  • 1.83, Аноним (83), 14:12, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отиличное решение, а когда закончите перепишите Go на TypeScript...
     
  • 1.93, Аноним (93), 15:08, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Остался один шаг чтобы понять, что Typescript - вообще не нужен.
     
     
  • 2.94, Аноним (-), 15:14, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, вот он как-раз таки нужен. Если тебе интересно комментарии писать вместо типов - пиши
     
  • 2.97, Аноним (48), 15:27, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Нативная поддержка тайпскрипта должна появится в браузерах.
     
     
  • 3.103, Аноним (53), 15:51, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    почему ещё не сделал?
     
  • 3.106, Аноним (-), 16:35, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Так дорогой давай стандарт для начала. Вот у JavaScript он есть. Правда не американских браузеров нет, но все-же.
     
  • 3.108, th3m3 (ok), 16:40, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Давно не следил за этим болотом, но если не ошибаюсь, там речь шла не про поддержку TS в браузере, а поддержку статичной типизации в ванильном js, что сделает ненужным TS в принципе.
     
     
  • 4.126, Нуину (?), 18:46, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > поддержку статичной типизации в ванильном js

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

     
  • 3.125, Нуину (?), 18:45, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Хотели сказать нативная поддержка go?
     

  • 1.95, Аноним (-), 15:15, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Меня лично устраивает текущий TypeScript
     
     
  • 2.124, Нуину (?), 18:45, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ой. Ну тогда срочно отменяем все.
     

  • 1.110, Я (??), 17:03, 12/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    сначала typescript на go, потом go на typescript, а там глядишь сделают rustoscript с nodecargo
     
     
  • 2.127, Аноним (127), 18:49, 12/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    конечно сделают, причём 100500 различных вариаций, другим способом безработицу не победить
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру