Здравствуйте, FR, Вы писали:
FR>Там же упор на то что и в TypeScript и в Go типизация структурная, переписать с нее на обычную номинативную может быть очень трудоемко.
Здравствуйте, hi_octane, Вы писали:
_>А если двухходовочка? Сейчас пишем TS на Go. За пару лет C# выходит на AOT такого-же уровня: компиляция в Native, мелкий экзешник. Через 2 года Хельсберг и ко выкатывают статью что "мы всё переписали с Go, получилось в десять раз хуже чем мы ожидали, сейчас переписываем на C#". Без этапа с Go такую PR-акцию не провернуть
Не знаю, как Хельсберг, а я б с тоски умер, переписывать TS сначала на Go, потом на C#...
Здравствуйте, rudzuk, Вы писали:
R>Вы же в курсе, что Хейлсбрег переписал компилятор TypeScript (с TypeScript) на GO?
Не переписал, а портировал с сохранением семантики и структуры.
R>Вот. Вопрос: почему не на C#?
Потому что портировать TS на C# с сохраннеием структуры и семантики сложнее, чем на C#. Как минимум из-за типизации.
Второй аргумент, который упомянул Андрес в своем 15-минутном анонсе — go имеет возможность управлять memory layout, делать низкоуровневые манипуляции с памятью и делать асинхроноость\параллельность. C# как бы тоже умеет, но что то одно — или асинхронность\параллельность, или низкоуровневые манипуляции. Так как ref структуры нельзя передавать через асинхронные вызовы. Так как C# имеет большую безопасность (safety) по сравнению с go это неизбежно несет ограничения и\или расходы на низкоуровневые операции.
R>Ответ немного очевиден: с шарпом и дотнетом что-то не так, раз их папа предпочел изделие конкурента, а не догфудинг.
А сами то можете сформулировать что?
R>Вощем, кирдык скоро вашей америке дотнетине
Давай посмотрим по-другому.
А почему не Rust, например? Его активно внутри MS продвигают, я думаю они могли бы больше программистов на расте найти внутри MS. И rust даже быстрее go.
Но rust таже не обладает структурной типизацией, повторить семантику tsc при построчном переводе не получится из-за владения, а async в расте все еще не очень стабильная штука.
Несмотря на то, что я недолюбливаю Go я могу согласиться, что для портирования (не переписывания) tsc в нативный код go — идеально подходящий существующий мейнстримный язык.
Здравствуйте, Anton Batenev, Вы писали:
Pzz>> По всему получается, что в качестве скриптового языка придется выбрать Питон. А я его терпеть не могу...
AB>А lua?
Я надеюсь, что срипты буду не только я писать. А lua в среднем малоизвестен.
И потом, у него индексы массивов начинаются с 1, буэ...
Здравствуйте, Pzz, Вы писали:
FR>>Там же упор на то что и в TypeScript и в Go типизация структурная, переписать с нее на обычную номинативную может быть очень трудоемко.
Pzz>Это где это в Go структурная типизация?
Когда пишешь, что должен уметь интерфейс, любая структура с соответствующими методами автоматически подходит под интерфейс, не надо это явно объявлять.
Здравствуйте, netch80, Вы писали:
Pzz>>Это где это в Go структурная типизация?
N>Когда пишешь, что должен уметь интерфейс, любая структура с соответствующими методами автоматически подходит под интерфейс, не надо это явно объявлять.
Здравствуйте, gandjustas, Вы писали:
G>Несмотря на то, что я недолюбливаю Go я могу согласиться, что для портирования (не переписывания) tsc в нативный код go — идеально подходящий существующий мейнстримный язык.
Сегодня на созвоне обсуждали эту новость. Я упомянул, что причиной стала медленная сборка старым компилятором толстых проектов. Попросил опытных компиляторщиков на С++ угадать, сколько времени собиралось 1.5М строк VS Code. Должно ж быть очень долго, аж пичот, чтобы парни взялись за неблагодарный труд по портированию компилятора.
Ближайшая оценка была "1 час"
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, rudzuk, Вы писали:
R>Вы же в курсе, что Хейлсбрег переписал компилятор TypeScript (с TypeScript) на GO? Вот. Вопрос: почему не на C#? Ответ немного очевиден: с шарпом и дотнетом что-то не так, раз их папа предпочел изделие конкурента, а не догфудинг. Вощем, кирдык скоро вашей америке дотнетине
Переписывать с нуля такой большой проект нереально, решено было портировать код файл за файлом с минимальными отличиями. Важной целью стояло сохранение "99.999%" поведения существующей версии для надежной миграции продуктовых команд.
Go оказался наилучшим вариантом для порта по ряду факторов:
он достаточно низкоуровневый и в целом всегда дизайнился под перф,
именно на него лучше всего ложится текущий код TS, который содержит огромное количество рекурсивных данных (это же отметает Rust),
Наше решение портировать на 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 остается сильнее, чем когда-либо, мы постоянно совершенствуем эти технологии, чтобы предоставить разработчикам инструменты, необходимые для успеха сейчас и в будущем.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, rudzuk, Вы писали:
N>> Очевидно: им нужна скорость и не только работы, а и в том числе быстрый запуск.
R>А как же дотнетовский AOT, который для этого и нужен?
дотнетовский AOT работает через компиляцию в С++, это же касается и Unity
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
g> Второй аргумент, который упомянул Андрес в своем 15-минутном анонсе — go имеет возможность управлять memory layout, делать низкоуровневые манипуляции с памятью и делать асинхроноость\параллельность. C# как бы тоже умеет, но что то одно — или асинхронность\параллельность, или низкоуровневые манипуляции. Так как ref структуры нельзя передавать через асинхронные вызовы. Так как C# имеет большую безопасность (safety) по сравнению с go это неизбежно несет ограничения и\или расходы на низкоуровневые операции.
Это здорово, а TypeScript такое умеет? Если нет, то почему это должно быть плюсом при портировании?
g> R>Ответ немного очевиден: с шарпом и дотнетом что-то не так, раз их папа предпочел изделие конкурента, а не догфудинг.
g> А сами то можете сформулировать что?
Я же не Хейлсберг и внутреннюю кухню не вижу. Как сторонний наблюдатель я уже неоднократно говорил, что шарп превратился из простого языка в помойку, куда тащат все, чтобы показать движуху.
g> Давай посмотрим по-другому.
g> А почему не Rust, например? Его активно внутри MS продвигают, я думаю они могли бы больше программистов на расте найти внутри MS. И rust даже быстрее go.
Все растманы в МС уже заняты переписыванием офисного бэка с шарпа
g> Несмотря на то, что я недолюбливаю Go я могу согласиться, что для портирования (не переписывания) tsc в нативный код go — идеально подходящий существующий мейнстримный язык.
В действительности, наличие структурной типизации единственный разумный аргумент в пользу GO
Здравствуйте, Pzz, Вы писали:
AB>>А lua?
Pzz>Я надеюсь, что срипты буду не только я писать. А lua в среднем малоизвестен.
Да уж поизвестнее, чем Go
Pzz>И потом, у него индексы массивов начинаются с 1, буэ...
Хм, не помню такого. Но, может, ошибаюсь.
В squirrel вроде с нуля индексы; с одной стороны он сильно похож на lua, но есть классы, можно перегружать арифметические операторы и вроде индексирование, поприятнее луы
Здравствуйте, rudzuk, Вы писали:
R>Вы же в курсе, что Хейлсбрег переписал компилятор TypeScript (с TypeScript) на GO? Вот. Вопрос: почему не на C#? Ответ немного очевиден: с шарпом и дотнетом что-то не так, раз их папа предпочел изделие конкурента, а не догфудинг. Вощем, кирдык скоро вашей америке дотнетине
А уж с Делфи-то как всё не так, что Хейлсбрегу пришлось Шарп придумывать
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, netch80, Вы писали:
Pzz>>>Это где это в Go структурная типизация?
N>>Когда пишешь, что должен уметь интерфейс, любая структура с соответствующими методами автоматически подходит под интерфейс, не надо это явно объявлять.
Pzz>Ну т.е., утиная типизация?
Ну да.
Я не нашёл разницы между этими двумя названиями (может, есть какие-то специфические контексты, но поймать не получилось).
Здравствуйте, rudzuk, Вы писали:
M>> А уж с Делфи-то как всё не так, что Хейлсбрегу пришлось Шарп придумывать
R>Ему пришлось потому что МС заплатила, видя какая дельфя крутая получилась
Если Дельфя получилась такая крутая, то что ж Borland ему не заплатил, чтобы он сделал Borland C#?
Здравствуйте, Marty, Вы писали:
M> R>Ему пришлось потому что МС заплатила, видя какая дельфя крутая получилась
M> Если Дельфя получилась такая крутая, то что ж Borland ему не заплатил, чтобы он сделал Borland C#?
У борланда небыло задачи копировать переосмысливать жабу
Здравствуйте, rudzuk, Вы писали:
M>> Если Дельфя получилась такая крутая, то что ж Borland ему не заплатил, чтобы он сделал Borland C#?
R>У борланда небыло задачи копировать переосмысливать жабу
Можно же было переосмыслить Дельфю, сделать её в 100 раз круче. Или Дельфя сразу была совершенством?
Здравствуйте, Marty, Вы писали:
M> R>У борланда небыло задачи копировать переосмысливать жабу
M> Можно же было переосмыслить Дельфю, сделать её в 100 раз круче. Или Дельфя сразу была совершенством?
Чего ее переосмысливать, она уже была крутой Никто им за нее исками не угрожал.
