Здравствуйте, rudzuk, Вы писали:

R>Вы же в курсе, что Хейлсбрег переписал компилятор TypeScript (с TypeScript) на GO? Вот. Вопрос: почему не на C#? Ответ немного очевиден: с шарпом и дотнетом что-то не так, раз их папа предпочел изделие конкурента, а не догфудинг. Вощем, кирдык скоро вашей америке дотнетине

Разбор интервью с автором TypeScript о портировании его на Go

Выбор языка
Как раз во время публикации этой статьи Андерс высказался подробным текстом на этот счет: https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12466988

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

Go оказался наилучшим вариантом для порта по ряду факторов:

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

именно на него лучше всего ложится текущий код TS, который содержит огромное количество рекурсивных данных (это же отметает Rust),

он очень кроссплатформенный (это же отметает C#).

Здравствуйте, rudzuk, Вы писали:

R>Вы же в курсе, что Хейлсбрег переписал компилятор TypeScript (с TypeScript) на GO? Вот. Вопрос: почему не на C#? Ответ немного очевиден: с шарпом и дотнетом что-то не так, раз их папа предпочел изделие конкурента, а не догфудинг. Вощем, кирдык скоро вашей америке дотнетине

Разбор интервью с автором TypeScript о портировании его на Go

Выбор языка
Как раз во время публикации этой статьи Андерс высказался подробным текстом на этот счет: https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12466988

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

Go оказался наилучшим вариантом для порта по ряду факторов:

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

именно на него лучше всего ложится текущий код TS, который содержит огромное количество рекурсивных данных (это же отметает Rust),

он очень кроссплатформенный (это же отметает C#).

Из ветки ответ соавтора, гугл-переводчик.

https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12466988

Наше решение портировать на Go подчеркивает нашу приверженность прагматичным инженерным решениям. Мы сосредоточились на достижении наилучшего возможного результата независимо от используемого языка. В Microsoft мы используем несколько языков программирования, включая C#, Go, Java, Rust, C++, TypeScript и другие, каждый из которых был тщательно выбран на основе технической пригодности и производительности команды. Фактически, C# по-прежнему остается самым популярным языком внутри компании, безусловно.

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

На зелёном поле это был бы совсем другой разговор. Но это было не зелёное поле — это порт существующей кодовой базы с 100 человеко-лет инвестиций. Да, мы могли бы перепроектировать компилятор на C# с нуля, и это бы сработало. Фактически, собственный компилятор C#, Roslyn, написан на C# и сам себя загружает. Но это не было перепроектированием компилятора, и переход с TypeScript на Go был гораздо более автоматизированным и более однозначным в своём отображении. Наша существующая кодовая база — это все функции и структуры данных — без классов. Идиоматический Go выглядел так же, как наша существующая кодовая база, поэтому порт был значительно упрощен.

Хотя это решение хорошо подходило для конкретной ситуации TypeScript, оно не умаляет наших глубоких и постоянных инвестиций в C# и .NET. Большинство сервисов и продуктов Microsoft в значительной степени зависят от C# и .NET из-за их непревзойденной производительности, надежной экосистемы и высокой масштабируемости. C# отлично подходит для сценариев, требующих быстрой, поддерживаемой и масштабируемой разработки, поддерживая критически важные системы и многочисленные внутренние и внешние решения Microsoft. Современный, кроссплатформенный .NET также обеспечивает выдающуюся производительность, что делает его идеальным для создания облачных сервисов, которые без проблем работают в любой операционной системе и у нескольких поставщиков облачных услуг. Недавние улучшения производительности в .NET 9 еще раз демонстрируют наши постоянные инвестиции в эту мощную экосистему ( https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/ ).

Давайте будем реалистами. Использование Microsoft Go для написания компилятора для TypeScript было бы невозможно или немыслимо в прошлые годы. Однако за последние несколько десятилетий мы увидели сильную и постоянную приверженность Microsoft программному обеспечению с открытым исходным кодом, отдавая приоритет производительности разработчиков и сотрудничеству с сообществом. Наша цель — предоставить разработчикам лучшие доступные инструменты, не обремененные внутренней политикой или узкими ограничениями. Эта свобода выбора правильного инструмента для каждой конкретной работы в конечном итоге приносит пользу всему сообществу разработчиков, стимулируя инновации, эффективность и улучшенные результаты. И вы не можете спорить с десятикратным результатом!

Ни один язык не идеален для всех задач, и в Microsoft мы празднуем силу, которая исходит от разнообразия языков программирования. Наша приверженность C# и .NET остается сильнее, чем когда-либо, мы постоянно совершенствуем эти технологии, чтобы предоставить разработчикам инструменты, необходимые для успеха сейчас и в будущем.