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

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

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

Очевидно: им нужна скорость и не только работы, а и в том числе быстрый запуск.

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

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

N> Очевидно: им нужна скорость и не только работы, а и в том числе быстрый запуск.

А как же дотнетовский AOT, который для этого и нужен?

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

N>> Очевидно: им нужна скорость и не только работы, а и в том числе быстрый запуск.

R>А как же дотнетовский AOT, который для этого и нужен?

Unity пошли по другому пути, и компилируют IL в c++

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

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

А вы не видели на ЛОРе недавнее обсуждение?! Время от времени посматриваю издалека тамошние баталии. Там ответили, что так было проще перенести работающий код с JavaScript на Go из-за близости языков. Вполне выглядит правдоподобно, хотя JavaScript я давно и успешно забыл, а c Go почти не знаком. Если языки действительно близки, то на реальную причину очень похоже. Не вижу смысла искать другие. Да и, может, просто автору захотелось разнообразия, потому что любая технология приедается, даже самая совершенная.

А дотнет сам по себе очень хорош за всем, кроме одного такого маленького нюанса, что он — американский

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

Не надо искать сложные ответы там, где есть простой. Простой ответ — Go моложе и не успел обрасти дичайшим легаси. К тому же внутрикорпоративные запросы почти всегда перерастают в политику. Мне тоже было куда проще работать с адекватной open source community и другими компаниями (тем же Ericsson), чем с индус-триализованной частью моего предыдущего места работы. Объяснимо, конечно — open source community работает на открытых принципах, тогда как внутренние копроративные процессы завязаны на "кому сколько достанется на очередном performance review". То бишь, открытая разработка vs кулуарные переговоры.

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

А если двухходовочка? Сейчас пишем TS на Go. За пару лет C# выходит на AOT такого-же уровня: компиляция в Native, мелкий экзешник. Через 2 года Хельсберг и ко выкатывают статью что "мы всё переписали с Go, получилось в десять раз хуже чем мы ожидали, сейчас переписываем на C#". Без этапа с Go такую PR-акцию не провернуть

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

wl.> R>А как же дотнетовский AOT, который для этого и нужен?

wl.> Unity пошли по другому пути, и компилируют IL в c++

Полагаю, они не стали бы этого делать, появись AOT раньше.

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

SD> Не надо искать сложные ответы там, где есть простой. Простой ответ — Go моложе и не успел обрасти дичайшим легаси. К тому же внутрикорпоративные запросы почти всегда перерастают в политику.

SD> Объяснимо, конечно — open source community работает на открытых принципах, тогда как внутренние копроративные процессы завязаны на "кому сколько достанется на очередном performance review". То бишь, открытая разработка vs кулуарные переговоры.

Так дотнет уже давно опенсорс. Компилятор TypeScript тоже опенсорс. Ну а какая такая легаси в дотнете или шарпе могла помешать Хейлсбергу я вообще не догоняю

Зато мы видим, что МС свой облачный офис переписывает с шарпа на раст: https://www.opennet.ru/opennews/art.shtml?num=60533 А теперь такой удар в спину собственному детищу от Хейлсберга. Однако, еще немного и будет уже тенденция.

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

d> А вы не видели на ЛОРе недавнее обсуждение?! Время от времени посматриваю издалека тамошние баталии. Там ответили, что так было проще перенести работающий код с JavaScript на Go из-за близости языков.

Этот тезис я на опенете видел, он, вроде, от самого. Однако, он выглядит неубедительным. На мой взгляд, схожесть TypeScript и Go, скажем так, несколько преувеличена, в то время, как о C# и TypeScript говорится, примерно, так:
https://learn.microsoft.com/ru-ru/dotnet/csharp/tour-of-csharp/tips-for-javascript-developers

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

https://www.quora.com/Why-are-TypeScript-and-C-so-much-alike

They’re alike because their development was led by the same guy: Anders Hejlsberg.

Да что там, даже вика говорит, что TypeScript инфлюенсед бай C#, что, как бы, намекает

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

h> А если двухходовочка? Сейчас пишем TS на Go. За пару лет C# выходит на AOT такого-же уровня: компиляция в Native, мелкий экзешник. Через 2 года Хельсберг и ко выкатывают статью что "мы всё переписали с Go, получилось в десять раз хуже чем мы ожидали, сейчас переписываем на C#". Без этапа с Go такую PR-акцию не провернуть


Звучит разумно.

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

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

Да вот тоже это удивило. Почему не шарп от МС, а го от гугла? Действительно странно.

BE>Да вот тоже это удивило. Почему не шарп от МС, а го от гугла? Действительно странно.

Да может челу просто захотелось новый инструмент изучить.
Мне вот тоже интересно что-нибудь на Расте написать. Не потому, что язык крутой, а просто любопытно.

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

R>Этот тезис я на опенете видел, он, вроде, от самого. Однако, он выглядит неубедительным. На мой взгляд, схожесть TypeScript и Go, скажем так, несколько преувеличена

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

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

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

На хабре же есть с ним интервью как раз по поводу этого приекта: https://habr.com/ru/articles/890056/

Говорят, Go — очень кроссплатформенный, в отличии от C#

Жалко, что это порт именно компилятора, и нет режима работы в качестве интерпретатора, не зависящего от node.js.

У меня сейчас возникла потребность вставить в программу на Go некий встроенный скриптинг. По всему получается, что в качестве скриптового языка придется выбрать Питон. А я его терпеть не могу...

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

Pzz> На хабре же есть с ним интервью как раз по поводу этого приекта: https://habr.com/ru/articles/890056/

Pzz> Говорят, Go — очень кроссплатформенный, в отличии от C#

Так дотнет же тоже

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

FR> Там же упор на то что и в TypeScript и в Go типизация структурная, переписать с нее на обычную номинативную может быть очень трудоемко.
FR> Тут и выбора кроме Go и нет среди хотя бы относительно популярных языков, еще и OCaml бы подошел и практически нет больше кандидатов.

А вот это действительно веский аргумент. Спасибо.

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

Pzz>> Говорят, Go — очень кроссплатформенный, в отличии от C#

R>Так дотнет же тоже

Ну вот смотрю я на эту табличку: https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md

Получается, что на линухе дотнет поддерживает Arm32, Arm64, x64, ppc64le и s390x. Причем в зависимости от дистрибутива, список может быть короче.

Go, для сравнения, поддерживает вот такой список:

$ go tool dist list | grep linux
linux/386
linux/amd64
linux/arm
linux/arm64
linux/loong64
linux/mips
linux/mips64
linux/mips64le
linux/mipsle
linux/ppc64
linux/ppc64le
linux/riscv64
linux/s390x

Я понимаю, какой-нибудь условный 386 уже и мало кому нужен сейчас. Но loong64, riscv64 и любимый китайцами mips...

И это, притом на любом дистре. И можно кросс-компилировать свободно, откуда хочешь и куда хочешь.

Про всякие там FreeBSD и NetBSD я уж не говорю...

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

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

R>>Этот тезис я на опенете видел, он, вроде, от самого. Однако, он выглядит неубедительным. На мой взгляд, схожесть TypeScript и Go, скажем так, несколько преувеличена

FR>Там же упор на то что и в TypeScript и в Go типизация структурная, переписать с нее на обычную номинативную может быть очень трудоемко.
FR>Тут и выбора кроме Go и нет среди хотя бы относительно популярных языков, еще и OCaml бы подошел и практически нет больше кандидатов.

Я уж думал что не найду адекватное мнение в этом треде, но оказывается еще есть думающие люди.

Хейлсберг даже в 15 минутном анонсе раза три упомянул, что это не переписывание компилятора на другой язык, а портирование, буквально построчный перевод на другой язык, а это возможно только если фичи языка +\- совпадают. То есть целевой язык для переписывания ts должен иметь структурную типизацию интерфейсов и сборщик мусора.

Я думаю если бы хотели именно переписать компилятор на другом языке, то взяли бы Rust, он даже внутри MS более модный.

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

FR>Там же упор на то что и в TypeScript и в Go типизация структурная, переписать с нее на обычную номинативную может быть очень трудоемко.

Это где это в 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 — идеально подходящий существующий мейнстримный язык.

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

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

А lua?

Здравствуйте, 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 час"

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

S>Ближайшая оценка была "1 час"

Тяжело в учении, легко в бою

Здравствуйте, 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 остается сильнее, чем когда-либо, мы постоянно совершенствуем эти технологии, чтобы предоставить разработчикам инструменты, необходимые для успеха сейчас и в будущем.

Здравствуйте, 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>Ну т.е., утиная типизация?

Ну да.
Я не нашёл разницы между этими двумя названиями (может, есть какие-то специфические контексты, но поймать не получилось).

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

M> А уж с Делфи-то как всё не так, что Хейлсбрегу пришлось Шарп придумывать

Ему пришлось потому что МС заплатила, видя какая дельфя крутая получилась

Здравствуйте, 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 раз круче. Или Дельфя сразу была совершенством?

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

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

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

Почему вообще переписал на внешний язык? node работает не так уж плохо. Игры с компиляцией C++ и Go в WASM и потом замеры попугаев в сравнении с тупо жаваскриптом приводят к удивительным результатам, типа было быстрее, потом в хроме что-то подшаманили- и стало небыстрее.

Скорей всего, какая-то политика и никакого отношения к рациональности не имеет.

Pzz>У меня сейчас возникла потребность вставить в программу на Go некий встроенный скриптинг. По всему получается, что в качестве скриптового языка придется выбрать Питон. А я его терпеть не могу...

Lua же.

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

M>> Можно же было переосмыслить Дельфю, сделать её в 100 раз круче. Или Дельфя сразу была совершенством?

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

Ну, она и щас мега крута, только лишь кхимики пишут на ней

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

M>В squirrel вроде с нуля индексы; с одной стороны он сильно похож на lua, но есть классы

А в lua разве нет классов? ну либо что-то очень похожего:

local addonName, addon = ...
_G[addonName] = addon

addon.Version = "v11.1.001"
addon.VersionNum = 1101001

LibStub("LibMVC-1.0"):Embed(addon)

local L = AddonFactory:GetLocale(addonName)
local LibSerialize = LibStub:GetLibrary("LibSerialize")
local commPrefix = addonName

AddonFactory:AddKeyBinding("ALTOHOLIC", addonName, "Altoholic - Toggle UI")

function addon:Print(text)    
    DEFAULT_CHAT_FRAME:AddMessage(format("|cff33ff99%s|r: %s", addonName, text))
end

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

M> R>Чего ее переосмысливать, она уже была крутой Никто им за нее исками не угрожал.

M> Ну, она и щас мега крута

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

M> только лишь кхимики пишут на ней

Вот видишь, даже на политологическом сайте нашелся дельфист

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

Pzz>>Я надеюсь, что срипты буду не только я писать. А lua в среднем малоизвестен.

M>Да уж поизвестнее, чем Go

Я б поспорил.

Он старше, это да. Говорят, его игровики очень любят, в качестве скриптового языка. Но за пределами этой ниши он не слишком известен.

Pzz>>И потом, у него индексы массивов начинаются с 1, буэ...

M>Хм, не помню такого. Но, может, ошибаюсь.

У него можно задать параметром. По умолчанию (в стандартной конфигурации) — 1. А если сделаешь 0, получишь такой диалект lua, с 0-based массивами.

M>В squirrel вроде с нуля индексы; с одной стороны он сильно похож на lua, но есть классы, можно перегружать арифметические операторы и вроде индексирование, поприятнее луы

Выглядит, как недо-JS...

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

Pzz>>Ну т.е., утиная типизация?

N>Ну да.
N>Я не нашёл разницы между этими двумя названиями (может, есть какие-то специфические контексты, но поймать не получилось).

Я просто название "структурная типизация" раньше не слышал. Полез в интернет, а там пишут, что это когда структуры с одинаковым набором и совместимым типом полей между собой совместимы (что может и верно для JS, у него структура — это unordered map, насколько я помню, но неверно для Go, у него струкытура, как в Си).

Вот и хотел уточнить.

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

А> Скорей всего, какая-то политика и никакого отношения к рациональности не имеет.

Причины выглядят вполне рационально:

Предполагается, что создание нативного компилятора и инструментария для 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 сек.

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

N>Ну да.
N>Я не нашёл разницы между этими двумя названиями (может, есть какие-то специфические контексты, но поймать не получилось).

Так и не должно быть: утиная это жаргонное название структурной.

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

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

g>> Второй аргумент, который упомянул Андрес в своем 15-минутном анонсе — go имеет возможность управлять memory layout, делать низкоуровневые манипуляции с памятью и делать асинхроноость\параллельность. C# как бы тоже умеет, но что то одно — или асинхронность\параллельность, или низкоуровневые манипуляции. Так как ref структуры нельзя передавать через асинхронные вызовы. Так как C# имеет большую безопасность (safety) по сравнению с go это неизбежно несет ограничения и\или расходы на низкоуровневые операции.

R>Это здорово, а TypeScript такое умеет?
Нет, если бы умел, то какой смысл был бы переписывать на go&

R>Если нет, то почему это должно быть плюсом при портировании?
Потому что это дополнительная возможность оптимизации

g>> R>Ответ немного очевиден: с шарпом и дотнетом что-то не так, раз их папа предпочел изделие конкурента, а не догфудинг.
g>> А сами то можете сформулировать что?
R>Я же не Хейлсберг и внутреннюю кухню не вижу. Как сторонний наблюдатель я уже неоднократно говорил, что шарп превратился из простого языка в помойку, куда тащат все, чтобы показать движуху.
А как это связано с TypeScript и go?

g>> Давай посмотрим по-другому.
g>> А почему не Rust, например? Его активно внутри MS продвигают, я думаю они могли бы больше программистов на расте найти внутри MS. И rust даже быстрее go.
R>Все растманы в МС уже заняты переписыванием офисного бэка с шарпа
Что такое офисный бек на шарпе? И зачем его переписывать на rust?

g>> Несмотря на то, что я недолюбливаю Go я могу согласиться, что для портирования (не переписывания) tsc в нативный код go — идеально подходящий существующий мейнстримный язык.
R>В действительности, наличие структурной типизации единственный разумный аргумент в пользу GO
Ну и возможность сделать код менее требовательным к памяти и за счет этого более быстрым из-за общей низкоуровневости go.

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

g> g>> R>Ответ немного очевиден: с шарпом и дотнетом что-то не так, раз их папа предпочел изделие конкурента, а не догфудинг.

g> g>> А сами то можете сформулировать что?

g> R>Я же не Хейлсберг и внутреннюю кухню не вижу. Как сторонний наблюдатель я уже неоднократно говорил, что шарп превратился из простого языка в помойку, куда тащат все, чтобы показать движуху.

g> А как это связано с TypeScript и go?

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

g> R>Все растманы в МС уже заняты переписыванием офисного бэка с шарпа

g> Что такое офисный бек на шарпе? И зачем его переписывать на rust?

Зачем-то переписывают.

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

FR>>Там же упор на то что и в TypeScript и в Go типизация структурная, переписать с нее на обычную номинативную может быть очень трудоемко.
FR>>Тут и выбора кроме Go и нет среди хотя бы относительно популярных языков, еще и OCaml бы подошел и практически нет больше кандидатов.

G>Я уж думал что не найду адекватное мнение в этом треде, но оказывается еще есть думающие люди.

G>Хейлсберг даже в 15 минутном анонсе раза три упомянул, что это не переписывание компилятора на другой язык, а портирование, буквально построчный перевод на другой язык, а это возможно только если фичи языка +\- совпадают. То есть целевой язык для переписывания ts должен иметь структурную типизацию интерфейсов и сборщик мусора.

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

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

S>Сегодня на созвоне обсуждали эту новость. Я упомянул, что причиной стала медленная сборка старым компилятором толстых проектов. Попросил опытных компиляторщиков на С++ угадать, сколько времени собиралось 1.5М строк VS Code. Должно ж быть очень долго, аж пичот, чтобы парни взялись за неблагодарный труд по портированию компилятора.
S>Ближайшая оценка была "1 час"

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

Здравствуйте, Pzz, Вы писали:
Pzz>Я просто название "структурная типизация" раньше не слышал.
Очень странно, термину сто лет в обед. Но — бывает, чо уж.

Pzz>Полез в интернет, а там пишут, что это когда структуры с одинаковым набором и совместимым типом полей между собой совместимы (что может и верно для JS, у него структура — это unordered map, насколько я помню, но неверно для Go, у него структура, как в Си).
См. https://go.dev/doc/faq#implements_interface:

A Go type implements an interface by implementing the methods of that interface, nothing more. This property allows interfaces to be defined and used without needing to modify existing code. It enables a kind of structural typing that promotes separation of concerns and improves code re-use, and makes it easier to build on patterns that emerge as the code develops. The semantics of interfaces is one of the main reasons for Go’s nimble, lightweight feel.

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

M>>В squirrel вроде с нуля индексы; с одной стороны он сильно похож на lua, но есть классы

wl.>А в lua разве нет классов? ну либо что-то очень похожего:

wl.>

wl.>

Это эмуляция через таблицы. В squirrel под капотом в принципе то же самое, но там есть синтаксис классов в языке, и это удобнее.

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


M>> только лишь кхимики пишут на ней

R>Вот видишь, даже на политологическом сайте нашелся дельфист

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

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


Pzz>Он старше, это да. Говорят, его игровики очень любят, в качестве скриптового языка. Но за пределами этой ниши он не слишком известен.

А за пределами этой ниши он и не нужен. Тем не менее, тебе он нужен тоже именно в таком же качестве — как встройка в свой софт


M>>В squirrel вроде с нуля индексы; с одной стороны он сильно похож на lua, но есть классы, можно перегружать арифметические операторы и вроде индексирование, поприятнее луы

Pzz>Выглядит, как недо-JS...

Возможно. Только он весьма просто интегрируется в плюсовый или сишный проект, не уверен, что это легко можно сделать с JS

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

BE>>Да вот тоже это удивило. Почему не шарп от МС, а го от гугла? Действительно странно.

SD>Да может челу просто захотелось новый инструмент изучить.
SD>Мне вот тоже интересно что-нибудь на Расте написать. Не потому, что язык крутой, а просто любопытно.

Нифига, вот здесь он говорит что выбор вполне осознанный, было много вариантов
https://www.youtube.com/watch?v=pNlq-EVld70

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

M> M>> только лишь кхимики пишут на ней

M> R>Вот видишь, даже на политологическом сайте нашелся дельфист

M> Я про то, что на ней сейчас пишут только фрики и умственные инвалиды

Марти, ты снова все напутал. Ты пишешь на сисиплюсе, не забывай!

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

M>> Я про то, что на ней сейчас пишут только фрики и умственные инвалиды

R>Марти, ты снова все напутал. Ты пишешь на сисиплюсе, не забывай!

Я всё верно сказал. Я пишу на плюсах, а тупые фрики — на дельфях

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

M> M>> Я про то, что на ней сейчас пишут только фрики и умственные инвалиды

M> R>Марти, ты снова все напутал. Ты пишешь на сисиплюсе, не забывай!

M> Я всё верно сказал. Я пишу на плюсах, а тупые фрики — на дельфях

Тьфу на тебя!

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

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

Аё>Почему вообще переписал на внешний язык? node работает не так уж плохо. Игры с компиляцией C++ и Go в WASM и потом замеры попугаев в сравнении с тупо жаваскриптом приводят к удивительным результатам, типа было быстрее, потом в хроме что-то подшаманили- и стало небыстрее.

Аё>Скорей всего, какая-то политика и никакого отношения к рациональности не имеет.

В C# есть опция .Net AOT. По сути это компиляция в C++
WASM это отдельная тема для Blazor в основном.
Хотя есть https://github.com/dotnet/dotnet-wasi-sdk
https://devblogs.microsoft.com/dotnet/extending-web-assembly-to-the-cloud/

Нужно это не только для скорости, но и для обфускации

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

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

FR>>>Там же упор на то что и в TypeScript и в Go типизация структурная, переписать с нее на обычную номинативную может быть очень трудоемко.

Pzz>>Это где это в Go структурная типизация?

N>Когда пишешь, что должен уметь интерфейс, любая структура с соответствующими методами автоматически подходит под интерфейс, не надо это явно объявлять.

Это только про интерфейсы. А интерфейсы в гошке — это только про методы. Очень маленький подсет языка, что бы говорить о структурной типизации, как в этом вашем JS.

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

P>Портирование это очень быстро, относительно других подходов, и позволяет сохранить при этом все вырожденные кейсы коих гугол или близко к этому.
И тем не менее.
Получается, они только что повесили себе на шею ещё и задачу каждый коммит проносить сразу в две кодовые базы.
Ну, может, конечно, у них там за сценой стоит автоперекодировщик, который порождает Go код по коду на TS; тогда, наверное, дополнительных усилий надо не очень много (только разгребать тесткейзы, которые прошли в основной ветке и упали в ветке tsgo). Но всё же это резкое увеличение площади поверхности компилятора. Ведь забросить ветку tsc нельзя — куча стороннего кода уже сейчас завязана на то, что компилятор TS доступен как сервис в любом JS приложении.

bnk>Нифига, вот здесь он говорит что выбор вполне осознанный, было много вариантов

Да, выше по треду уже разобрали, что они "переписывали" в прямом смысле этого слова. Если б переписывали в смысле написания с нуля, то, вероятно, взяли бы более подходящий язык. Тот же Раст.

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

R>Вопрос: почему не на C#?

А почему не на TypeScript?

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

R>>Вопрос: почему не на C#?

C>А почему не на TypeScript?

Потому что компилятор typescript уже написан на typescript? Медленно. Новый вариант на Go в 10 раз быстрее.

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

bnk>Потому что компилятор typescript уже написан на typescript? Медленно. Новый вариант на Go в 10 раз быстрее.

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

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

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

Да, и вот как теперь верить интернетам?

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

Умный дом с AngelScript

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

bnk>>Потому что компилятор typescript уже написан на typescript? Медленно. Новый вариант на Go в 10 раз быстрее.
C>Какая неожиданность. А мне столько раз говорили, что жабаскриптовый рантайм вовсе не тормозной

Одно дело v8, другое компилятор на ts, т.е. tsc.

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

S>Одно дело v8, другое компилятор на ts, т.е. tsc.

А в чем разница?

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

S>>Одно дело v8, другое компилятор на ts, т.е. tsc.
C>А в чем разница?

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

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

S>Даже если разница в исполнителях не существенна, то необходимо учитывать сколько инвестировали в проект.
S>v8, кажется, появился гораздо раньше и работает в самом популярном браузере, т.е. гугол немало в него вложил ресурсов.
S>ts начался как побочный продукт энтузиастов внутри ms. Плюс особых требования к производительности компиляторов никогда не было,
S>плюс-минус десятки секунд особой роли не сыграют. В случае браузера и рендеринга это крайне существенно.

А какое отношение вот это все имеет к производительности собственно рантайма?

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

S>>Даже если разница в исполнителях не существенна, то необходимо учитывать сколько инвестировали в проект.
S>>v8, кажется, появился гораздо раньше и работает в самом популярном браузере, т.е. гугол немало в него вложил ресурсов.
S>>ts начался как побочный продукт энтузиастов внутри ms. Плюс особых требования к производительности компиляторов никогда не было,
S>>плюс-минус десятки секунд особой роли не сыграют. В случае браузера и рендеринга это крайне существенно.
C>А какое отношение вот это все имеет к производительности собственно рантайма?

Выше же ответил.

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

Аё>Почему вообще переписал на внешний язык? node работает не так уж плохо.

Их ответ простой — на ноде хрен сделаешь shared memory многопоточность. А на Го они поназапускали горутин, работающих с одними и теми же данными, и все в 10 раз ускорилось.

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

S>Выше же ответил.

Вычленить осмысленную информацию мне не удалось.

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

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

bnk>>>Потому что компилятор typescript уже написан на typescript? Медленно. Новый вариант на Go в 10 раз быстрее.
C>>Какая неожиданность. А мне столько раз говорили, что жабаскриптовый рантайм вовсе не тормозной

S>Одно дело v8, другое компилятор на ts, т.е. tsc.

Так tsc в итоге на node и работает. Тоже не понимаю, в чем отличие.

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

DM>Их ответ простой — на ноде хрен сделаешь shared memory многопоточность. А на Го они поназапускали горутин, работающих с одними и теми же данными, и все в 10 раз ускорилось.

https://www.npmjs.com/package/node-worker-threads-pool — многопоточность в ноде.

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

Аё>Здравствуйте, D. Mon, Вы писали:

DM>>Их ответ простой — на ноде хрен сделаешь shared memory многопоточность. А на Го они поназапускали горутин, работающих с одними и теми же данными, и все в 10 раз ускорилось.

Аё>https://www.npmjs.com/package/node-worker-threads-pool — многопоточность в ноде.

Насколько это эффективно работает в сравнении с go?

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

DM>>Их ответ простой — на ноде хрен сделаешь shared memory многопоточность. А на Го они поназапускали горутин, работающих с одними и теми же данными, и все в 10 раз ускорилось.

Аё>https://www.npmjs.com/package/node-worker-threads-pool — многопоточность в ноде.

Там шарить можно лишь примитивные массивы чисел. Обычные объекты, массивы и строки, которые и нужны компилятору, — фиг, надо туда-сюда сериализировать, будут одни тормоза вместо выигрыша.

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


Pzz>>Выглядит, как недо-JS...

M>Возможно. Только он весьма просто интегрируется в плюсовый или сишный проект, не уверен, что это легко можно сделать с JS

Пфф, `git clone https://github.com/bellard/quickjs; cd quickjs; make install`. Потом в своей программе #include <quickjs.h> и вперед.

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

S>>Одно дело v8, другое компилятор на ts, т.е. tsc.
A>Так tsc в итоге на node и работает. Тоже не понимаю, в чем отличие.

Каким образом он работает, он же вроде транслилирует в js, который в свою очередь выполняется node.js. Разве нет?
Похоже, что я напутал и это 2 независимых процесса. Пока, увы, с ts не сталкивался.

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

S>он же вроде транслилирует в js, который в свою очередь выполняется node.js. Разве нет?

Ну, если tsc написан на ts, значит его это тоже касается.

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

S>>он же вроде транслилирует в js, который в свою очередь выполняется node.js. Разве нет?
A>Ну, если tsc написан на ts, значит его это тоже касается.

Ну тогда вернемся к исходному вопросу про отличие:

S>Одно дело v8, другое компилятор на ts, т.е. tsc.

A>Так tsc в итоге на node и работает. Тоже не понимаю, в чем отличие.

С одной стороны есть runtime\интерпретатр, который оптимизирован (v8), и есть программа, которую он
выполняет (tsc), которая не слишком оптимизирована. Короче, интерпретатор -- хороший, программа -- плохая.

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

S>С одной стороны есть runtime\интерпретатр, который оптимизирован (v8), и есть программа, которую он
S>выполняет (tsc), которая не слишком оптимизирована. Короче, интерпретатор -- хороший, программа -- плохая.

То есть ты считаешь, что tsc плохо написан, поэтому медленно и работает? Тогда почему перенос tsc на go практически один в один увеличивает скорость работы на порядок?

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

S>С одной стороны есть runtime\интерпретатр, который оптимизирован (v8), и есть программа, которую он
S>выполняет (tsc), которая не слишком оптимизирована. Короче, интерпретатор -- хороший, программа -- плохая.

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

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

S>>С одной стороны есть runtime\интерпретатр, который оптимизирован (v8), и есть программа, которую он
S>>выполняет (tsc), которая не слишком оптимизирована. Короче, интерпретатор -- хороший, программа -- плохая.
A>То есть ты считаешь, что tsc плохо написан, поэтому медленно и работает? Тогда почему перенос tsc на go практически один в один увеличивает скорость работы на порядок?

Ну значит я не прав. Для подобного рода задач v8 не годится.

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

Ответ немного очевиден: с C# как раз всё так; он зрел, самодостаточен, бодр и здоров; соответственно целебный прикладываемый подорожник-Typescript, выращенный папой-Хейлсбергом сначала для исцеления JS, а потом и для Go, оба из которых (а) имеют явные проблемы с типизацией, и (б) были созданы не Хейлсбергом, для C# и нахой не нужон, ибо у C# (в) этих проблем нет, и (г) он создан Хейлсбергом.

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

Аё>https://www.npmjs.com/package/node-worker-threads-pool — многопоточность в ноде.

Это все неинтересно

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

z> соответственно целебный прикладываемый подорожник-Typescript, выращенный папой-Хейлсбергом сначала для исцеления JS, а потом и для Go, оба из которых (а) имеют явные проблемы с типизацией, и (б) были созданы не Хейлсбергом, для C# и нахой не нужон, ибо у C# (в) этих проблем нет, и (г) он создан Хейлсбергом.

Можно как-то мысль развернуть? А то не совсем понятно, какую дырку голанга этим подорожником залепили

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

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

Я, кстати, подумав вообще не могу понять, в чём ценность этой деятельности. Может, мы что-то неправильно просто понимаем?

Комлилятор TS — это транспиллер из TS в JS, сам написанный на TS. JS вроде, в современном JIT-овском исполнении не такая уж и медленная штука. По некоторым слухам сравнимая с Go (который пройгрывает голому Си раза в два).

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

От этого и сам компилятор бы ускорился, и прочие проекты, написанные на TS

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

Pzz> Я, кстати, подумав вообще не могу понять, в чём ценность этой деятельности. Может, мы что-то неправильно просто понимаем?

Тут, рядышком, уже разъяснили: https://rsdn.org/forum/flame.comp/8912976

Автор: D. Mon
Дата: 20.03.25

R>Можно как-то мысль развернуть? А то не совсем понятно, какую дырку голанга этим подорожником залепили
Неравитость системы типов.

PS. Зачем залеплять что-то у C#, если его и так делал Хейлсберг?
PPS. Впрочем, я не телепат, и всё высказанное выше — лишь предположения и спекуляции.