Команда TypeScript объявила о переходе на Go

Какую-то чушь несёт. Как ему не стыдно. Наверное гугл ему откат занесли. Других версий я не вижу.

Это норма. В смысле то что вы не можете осознать решение системного архитектора - это норма. Поэтому им и платят такие деньги - потому что они могут то что не могут программисты. До понимания нужно буквально дорасти. Я не пытаюсь вас сейчас как-то принизить или обидеть, текст не передает интонацию. Под дорасти я имею ввиду опыт в десятках лет в обоих языках. Он сказал что его любимый язык С++, но в данном случае лучше подходит Go, то самое «каждой задаче свой инструмент». Это не значит что Go лучше С++.

Любому архитектору понятно что если стоит задача ПЕРЕНЕСТИ логику максимально близко к оригиналу, а не ПЕРЕПИСАТЬ ВСЕ с НУЛЯ, то Go действительно лучший выбор для переноса логики из ts. Но понимания мало, нужны тесты, он их провел и убедился что таки да.

В Go те же примитивы работы со структурами данных, поддержка json, поддержка вложенных массивов из коробки и тд. Те буквально есть вся база на которой ts программист может сходу пользоваться и не выдумывать велосипед заново.

Еще раз, задача не пересоздать велосипед, а поменять текущему велосипеду колеса.

Не боИсь! Для неразумных разжевали на opennet. Заодно запинали и шарпистов ))

Для неразумных разжевали на opennet

Я прекратил там читать комменты после того как Андерса Хейлсберга записали в зумеры.

Насколько пересекаюсь с жабоскриптерами там у них серьёзное такое разделение, особенно во фронтенде, на сторонников тайпскрипта и ООП без сторонних фрэймворков, вроде как на тайпскрипте они и так могут реализовать реактивную парадигму, и сторонников всяких вью/реактов и ванильный жабоскрипт - типа реактивная парадигма лучше дружит с функциональной, нежели с ООП.

Что-то у вас всё в кучу перемешано.

Реактивная парадигма ортогональна ООП / функциональному подходу. Ничего не мешает делать реактивные приложения в обеих парадигмах. Библиотеки поддержки реактивности есть реализованные в ФП-стиле (jotai, cellx) и ООП-стиле (Mobx, ReCA). Статическая типизация TS тоже не привносит ООП в экосистему, потому что ООП уже реализован в JS.

«Мой дядя не сошел с ума, он только ослеп».

Он гофер

Он гофер

Не надо на меня наговаривать, я php макака.

Вообще, конечно, сижу с лицом лягушки. И тут и на опеннете «рряя rust/C# лучше, да что этот Андерс Хейлсберг вообще понимает». Тем временем Андерс Хейлсберг - системный архитектор в MS, создатель языков С# и TypeScript (и Delphi, но к делу не относится).

А еще он хаскелист, так, на минуточку.

А еще он хаскелист, так, на минуточку.

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

Тем временем Андерс Хейлсберг - системный архитектор в MS, создатель языков С# и TypeScript (и Delphi, но к делу не относится).

Turbo Pascal еще.

Что-то у вас всё в кучу перемешано.

Это не у меня, я вообще уже не лезу во фронт лет 5-6 как, ну разве что подправить что-нибудь чутка. Это из одного проекта, где две фронтовые команды, одна пилит сайт и всё остальное b2c, а вторая всё что b2b и всякие «одминки», это приблизительная выжимка их срачей ooп vs функциональщина, javascript vs typescript и у кого пипирка длиннее.

Но если компилятор ts→js удобнее писать на go, то может и прикладной код удобнее писать на go? А компилятор go→js уже давно имеетcя.

P.S. Сначала хелловорлд, дёргающий три апишечки выкачивает пол гига node_modules, а потом жалуются, что эти гигабайты мусорной хрени быстро обрабатывать не получается. Ну что за люди?

Во-первых не понятно, чем им node.js не угодил. Почему не смогли реализовать на нём с той же скоростью?

В смысле почему они не оставили компилятор на жаваскрипте, ведь он всего в 2* раза медленее го?

(* от 2 до 10 раз в зависимости от эластичности совы)

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

Всё равно неубедительно. Они разве не могли постараться использовать Rust? Было бы больше пользы в долгосрочной перспективе, ведь раст полезнее всех остальных языков. Все остальные люди спокойно переписывают софт на раст, изучают его и находят множество достоинств, то есть причины не писать на расте стремительно сводятся нулю и все люди должны выбирать этот язык. /s

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

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

Забавно получается, что TypeScript настолько тормозной, что даже компилятор его самого на нём решили написать на другом языка. Притом что у Go довольно простой компилятор без продвинутых оптимизаций, а у рантаймов JavaScript очень продвинутые оптимизации JIT.

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

Всё равно неубедительно.

Автор языка TypeScript и C# потестил С#, Go и Rust после чего пришел к вводу что перенести (не переписать с нуля, а перенести!) существующую TS логику проще всего будет на Go. TS смогут быстро перенести логику на новый язык и получить прирост в быстродейсвтии.

Цель именно перенести, а не переписать заново. В случае C# и Rust будет именно переписывание, а такой задачи не стоит, скорее наоборот, стоит задача получить прирост скорости в 10 раз малой кровью.

Если для вас это неубедительно, то на этом мои полномочия все.

Я извиняюсь, если ввёл в заблуждение

https://en.m.wikipedia.org/wiki/Tone_indicator

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

В самом js коде? Я думаю все низковисящие фрукты уже сорваны, раз они уже пошли на переписывание на другом ЯП. Вот, к примеру, в js нет структур, вместо них поголовно хеш-массивы, которые конечно же будут медленее.

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

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

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

Он не исполняется, это переводчик в JS.

То есть интерпретируемые языки быстрее компилируемых?

Откуда тогда 2-10 кратный прирост к производительности? Использовались плохие движки JS?

Если компилятор способен

тут ключевое слово - если. в динамической типизации все функции по сути обобщенные. и чтобы переделать тут в статическую типизацию, придется инстанцировать конкретные функции под конкретные наборы типов параметров. коих(наборов) может быть очень много. и сделать это при загрузке нельзя, поскольку типы актуальных параметров при вызове обобщенной функции выясняются только во время работы программы.

Вот, к примеру, в js нет структур, вместо них поголовно хеш-массивы, которые конечно же будут медленее.

V8 превращает типовые классы в обычные структуры, оптимизация ломается если добавлять динамически постоянно свойства, удалять, но если просто создавать классы как в С++ с определенным набором свойств, читать их, или записывать значения, то работа на низком уровне будет такая же как со структурами.

Тоже самое с числами, несмотря на то что в JS нету типа Integer, V8 все равно оптимизирует когда может, и возвращает его, если с числом работают как с целым.

То есть интерпретируемые языки быстрее компилируемых?

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

и чтобы переделать тут в статическую типизацию, придется инстанцировать конкретные функции под конкретные наборы типов параметров. коих(наборов) может быть очень много.

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

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

просто даже в с++ девиртуализация работает очень не всегда. и виртуальные методы там сплошь и рядом, именно ради выгоды от полиморфизьма.

но вот метод не ищется в словаре, - а или имеет адрес (для обычного метода) или индекс в таблице - для виртуального.

просто даже в с++ девиртуализация работает очень не всегда.

Иногда ее вообще невозможно на момент компиляции получить, в динамическом языке тоже самое. Но если можно то можно, или там есть какие то проблемы помимо разрешения проблемы остановки?

Он не исполняется, это переводчик в JS.

Поменяйте «TypeScript» на «JavaScript», в фразе, если вам так понятнее. Выходит что Go быстрее, чем JavaScript и любой язык, транслируемый в JavsScript.

Лучи поноса уже летят в твою сторону.

Лол, я сейчас понял, что это не просто Микрософт не стала использовать свои инструменты. Этот чувак Хейлсберг сам же сделал и Шарп, и Тайпскрипт. И не стал использовать свой же инструмент! Дюже потешно.

Есть, конешно, некоторые предположения, почему он так поступил:

❯ sudo dnf install dotnet-sdk-9.0
Updating and loading repositories:
Repositories loaded.
Package                                 Arch       Version                                 Repository               Size
Installing:
 dotnet-sdk-9.0                         x86_64     9.0.103-1.fc41                          updates             278.5 MiB
Installing dependencies:
 aspnetcore-runtime-9.0                 x86_64     9.0.2-1.fc41                            updates              22.3 MiB
 aspnetcore-targeting-pack-9.0          x86_64     9.0.2-1.fc41                            updates              14.6 MiB
 dotnet-apphost-pack-9.0                x86_64     9.0.2-1.fc41                            updates              11.1 MiB
 dotnet-host                            x86_64     9.0.2-1.fc41                            updates             302.5 KiB
 dotnet-hostfxr-9.0                     x86_64     9.0.2-1.fc41                            updates             318.2 KiB
 dotnet-runtime-9.0                     x86_64     9.0.2-1.fc41                            updates              70.5 MiB
 dotnet-targeting-pack-9.0              x86_64     9.0.2-1.fc41                            updates              36.9 MiB
 dotnet-templates-9.0                   x86_64     9.0.103-1.fc41                          updates               9.7 MiB
 netstandard-targeting-pack-2.1         x86_64     9.0.103-1.fc41                          updates              17.9 MiB

Transaction Summary:
 Installing:        10 packages

Total size of inbound packages is 126 MiB. Need to download 126 MiB.
After this operation, 462 MiB extra will be used (install 462 MiB, remove 0 B).
Is this ok [y/N]: 

Уж не знаю, нужно ли все это для работы дотнет приложений.

Расширенная версия: https://www.reddit.com/r/golang/comments/1j8shzb/comment/mh8khdw/

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

В самом js коде?

В проекте в целом. И в JS-коде и в node.js, если по-другому нельзя.

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

Это неправда. В JS есть структуры. Точней в V8 оптимизациях. https://v8.dev/docs/hidden-classes

.NET умеет компилировать программы с помощью AOT в обычные бинарники. Говорят, что там что-то не до конца готово, но можно и доготовить, даже если это так. То, что ты линканул это компилятор и прочее. 128 MiB так-то немного.

Почему в браузерах до сих пор не впилили нативный Тайпскрипт?

Давайте еще gcc впихнем чтобы можно было на Фортране и Ада сайты писать, а то у нас бровсеры недостаточно раздутые.

Штош. Нужна некоторая смелость, чтобы признать, что чужой инструмент подходит для некоторой задачи лучше.

Теперь в 10 раз быстрее

в 10 раз быстрее что именно? компиляция в JS?

Он сказал что его любимый язык С++

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

Спасибо, а полный транскрипт где-нибудь есть?

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

лучше пусть будет стабильный АПИ, но с венгерской нотацией, чем АПИ с синдромом дефицита внимания и смещение фокуса разработки с продукта на разрабов, чем специфичен опенсорс

не знаю, не искал специально. Случайно увидел.

Он перешел в команду разработки языка Typescript. Сейчас ведущий дизайнер языка C# - это Мэдс Торгерсен: (https://dotnetcore.show/episode-104-c-sharp-with-mads-torgersen/) : «I got hired by Microsoft 17 years ago to help work on C#. First, I worked with Anders Hejlsberg, who’s sort of the legendary creator and first lead designer of C#. And then when he and I had a little side project with others to do TypeScript, he stayed over there. And I got to take over as lead designer C#. So for the last, I don’t know, nearly a decade, that’s been my job at Microsoft to, to take care of the evolution of the C# programming language»

имхо это с WebAsm связано и прикручиванием (в процессе) языков со сборкой мусора - Go c мусоросбором и приэтом компилируемый + «гринлеты»

модель конкурентности в евентлупе с воркерами и прочей ассинхронщиной

и таки да Golang сейчас(в 2008) это буквально что Си в начале 70ых это

асм GCD(наибольший общий делитель) платформ исполнения - Мур перестал удваиватся поэтому многопоточность(конкурентность) стала общим местом

Это неправда. В JS есть структуры. Точней в V8 оптимизациях.

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

вообщет есть https://en.wikipedia.org/wiki/Asm.js

но имхо Архитектор! принял во внимание Wasm и ожидаемую эволюцию универсальной платформы (ща прикручивают(уже который год)динамические языки) - а Golang это отличный асм с встроенной конкурентностью - occam c транспьютерами не про текущую ситуацию :)

Дизассемблер показывает что это именно структура, где хватает одного mov [base+field], value

Выходит что Go быстрее, чем JavaScript и любой язык, транслируемый в JavsScript.

Как трансляция может быть быстрее оригинала? V8 скорее всего самая лучшая реализация, так что да, Go пока быстрее.

хватает одного mov [base+field], value *

* Но перед этим нужно сделать в рантайме все эти структурки, что по ссылке про V8

Это неважно, в С этим занимается компилятор на момент сборки. Невозможно произвести компиляцию интерпретируемого кода, не создавая данные описывающие структуры. Какие бы способы описания «структур» ты не делал, этого этапа не избежать.

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

Просто твой комментарий изначальный такой:

Вот, к примеру, в js нет структур, вместо них поголовно хеш-массивы, которые конечно же будут медленее.

Выглядит так, будто ты говоришь «в js нету структур, и он медленный, но в другом интерпретируемом языке это возможно»

Выглядит так, будто ты говоришь «в js нету структур, и он медленный, но в другом интерпретируемом языке это возможно»

Нет, там было про js vs go. Вот в ОП видео резонно сказали про то, что ЯП должен подходить под задачу. JS подходит для веба тем, что он интерпретируемый и его производительности достаточно. Но для штуки типа компилятора он неизбежно сольет даже гошечке, и ничего с этим не сделаешь, вот с сабжем тупо получили ускорение в 10 раз.