Комментарии 148
Хранить исходный код импортируемых пакетов в репозитории проекта… На дворе точно 2019?
Ну видите ли,
никто не гарантирует, что вы скачаете … одно и то же
Рухнуть может всё что угодно. А критичные для проекта зависимости от этого не должны стать недоступными.
А ещё для эстетов есть ts-node.
Единственное, что действительно пугает — импорт зависимостей, но может мы чего-то не знаем пока?
Скорее влияние Go на Райана. Там это практиковалось изначально, но подвергалось критике по многим причинам, поэтому недавно перешли на концепцию модулей.
Про это Райан ничего не говорил, не уверен, что он на это рассчитывал.
Согласен с тем, что есть проблема в том, что исходники могут не совпадать с тем, что положено в регистри. Хотя вроде как сейчас npm за этим хоть как-то приглядывает — и я надеюсь, что в будущем будет делать это более внимательно — например, будет сам выполнять prepublish из указанного репозитория.
Ну и проблема подмены кода таким импортом тоже не решается — ничего не мешает автору менять содержимое репозитория по 3 раза на дню, подкладывая туда эксплойты. Даже в якобы фиксированной версии. В ноде для этого хотя бы проверка хешей есть, а дино никогда не узнает, что его обманули.
Гмм, и то правда, вроде месяц назад добавили. Ну можно поздравить ребят — они заново изобрели лок файлы....
Кстати, сообщество тоже пытается решить эту проблему. Например, буквально на днях вышла бета Pika Registry, который обязуется взять на себя build-step, чтобы сделать реестр пакетов более защищённым.
И оно начнет расти
Рост популярности Node можно объяснить отсутствием хороших альтернатив для серверного Javascript. Если нужно было писать на JS – брали Node. Сейчас эта ниша уже занята, и Deno придется отвоевывать кусок рынка, на что требуются большие усилия, более привлекательные ништяки. Текущие плюшки в виде Typescript недостатков пока не перевешивают.
С точки зрения энтерпрайза, наличие Rust и TypeScript дает хороший маркетинг.
Давайте еще ML прикрутим, неважно зачем, но маркетинга еще больше даст /s
Всё пойдёт так как того хочет Райан. Разработчики будут заливать код компонентов на личные веб сайты, создавать папки с версиями, и все будут качать пакеты оттуда. Гмм. Мне кажется, это решительный скачок в прошлое.
Мне это как-то это подозрительно напоминает Go, который так нравится Райану.
я правильно понял что они полностью отказались от v8 под капотом, и переписали JS движок на расте?
Мне кажется, что круто взлетит что то в стиле node.wasm. Тогда можно будет много языков юзать без боли и страдания.
Тут опять встает вопрос о том, а зачем городить что-то новое, если оно и сегодня работает в node.
Чтобы она работала в песочнице и не портила людям жизнь. https://medium.com/wasmer/running-webassembly-on-the-kernel-8e04761f1d8e
Так её и так уже можно в какой-нибудь Docker-контейнер запихать?
Статью почитайте. Не только вы получаете безопасность от прострела по памяти и чужим ресурсам, но с запуском прямо в кернеле вы получаете прирост производительности, в отличие от этих ваших докеров.
Околонулевой оверхед хуже 10% спидапа, не?
https://www.zdnet.com/article/doomsday-docker-security-hole-uncovered/
docker как мне кажется проще обходится, чем изоляция на уровне wasi.
Если вы уж дали сервису определённые права на доступ к системе, то песочница nodejs поможет примерно никак. Про shared-хостинги для node я как-то не слышал.
WASM получается кроссплатформенный. Например, libsass на плюсах можно собрать в один wasm бандл под все платформы и положить его в npm, вместо того чтобы собирать бинарник под каждую платформу.
У вас собранный бинарник сможет на любой платформе запуститься, или у вас есть потенциальная возможность его под любую платформу собрать?
Скорее всего в Go возможно второе, а с node.wasm – первое.
То, что пересборка не для вас является проблемой, не означает что это работает для всех. "Подавляющее большинство" как считали?
А вы сами придумайте реалистичный кейс, который потребует необходимости что-то запустить без пересборки и вот прям по-другому никак. Вопрос сам и отпадет. Я вот кроме проприетарного пакета, для которого нет исходников, ничего придумать не могу. Времена другие нынче, опен сорсные. У меня и очевидно большинства других в работе для всего есть исходники и возможность собрать так, как хочу я. Будь это C#, Go, Obj-C, swift.
Я уже приводил в пример libsass: https://github.com/sass/libsass
Сейчас для его использования в node нужна обертка node-sass, которая во время установки модуля лезет в интернет за готовым бинарником под платформу или собирает, если бинарника не нашлось.
А в ситуации с WASM можно было бы просто положить бандл в npm, и он будет работать и на Windows, и на Mac, и Linux.
Вспомнил об одном интересном движке для серверного JS https://www.nexusjs.com/
К сожалению последний коммит в январе был.
А вот интересно, у них там свой компилятор тайпскрипта? Язык же довольно динамично развивается. Или внутри по-прежнему JS?
Rust. Однако, есть нюанс — в лучшем случае он будет не медленнее реализации на С++.
А у вас есть подтверждение ваших слов, что ивент луп на расте будет медленнее? У меня есть опровержение ваших слов: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune
Actix на tokyo практически в два раза быстрее всех своих конкурентов.
У меня есть здравый смысл. А у вас есть бенчмарк по фреймворкам, который не имеет отношения к скорости ивент лупа.
И я не писал, что Rust реализация будет медленнее. Я писал, что в лучшем случае она будет не медленнее.
Я писал, что в лучшем случае она будет не медленнее.
И вы ошиблись.
Что вам говорит ваш здравый смысл? Что если раст "использует" сишный код, то он не может быть быстрее? Тогда как вы оправдаете результаты actix'а, который практически в два раза быстрее всех конкурентов?
Зачем мне оправдывать результаты бенчмарки фреймворка?
Это не имеет никакого отношения к ивент лупу.
Даже такой бенчмарк ближе к истине.
Вы предоставили бенч годичной давности, а я полугодичной.
Вы ищете желаемое, я показываю действительное.
Зато мой бенчмарк имеет хоть какое-то отношение к вопросу.
И я его не искал, а взял первый попавшийся. В данном случае у меня просто нет "желаемого".
Серьёзно — как на основании фреймворков можно сравнивать ивент лупы? Сравнение на основании длины бороды авторов было бы и то более релевантным.
И ещё пара вещей, которые мне кажутся весьма очевидными.
Вы код libuv или tokio видели?
Там просто недостаточно простора, чтобы rust успел себя показать.
И даже если случится алгоритмическое чудо, и растовый вариант станет быстрее, то огромное комьюнити быстро заберёт это чудо и в libuv, после чего скорость сравняется обратно.
Да, я тут подумал — наверное, вы решили, что я говорю, что tokio теоретически не может быть быстрее libuv. Если что — нет — я говорю о том, что этого не будет на практике, по крайней мере, пока у libuv достаточно большое сообщество.
Но на практике вебсервера на токио самые быстрые.
И на практике ripgrep быстрее grep в 10 раз, но никто не спешит втаскивать изменения в grep.
Там по сути 2-3 syscall, расшифровка через одинаковую для всех библиотеку tls/ssl, одно обращение к структуре типа список для маршрутизации и всё — что тут можно ускорить?..
Всё остальное время работает программа за сервером. А для раздачи статики примерно все ставят nginx или аналог, а не пишут свой костыль (независимо от языка).
через одинаковую для всех библиотеку tls/ssl
Почитайте https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html, там результаты интересных бенчей.
Вот понимаете, вся проблема в том, что вы считаете, что на расте пишут обертки для готовых сишных библиотек. На самом деле на расте много чего пишут, в том числе и rustls, который быстрее openssl. Пример вкусых результатов: rustls is 30-70% quicker to resume a client connection.
что тут можно ускорить?..
Вот и подумайте, что можно ускорить. Если уже существуют решения на чистом расте, которые выигрывают у олдовых реализаций, то вы получаете прирост в 2 раза, как и было показано actix'ом.
Насчёт грепа — скорость грепа особо не волнует, пока она приемлима. Он не создаёт нагрузку на продакшн сервера, знаете ли.
Пример с openssl более релевантен, хотя там тоже могут быть свои подводные камни вроде безопасности и совместимости — не готов про это говорить, тема сложная. Но рад если всё так.
Ну и просто хочу напоминить, что холиварю не по поводу Rust vs C++, а по поводу преимуществ Deno над Node. В конце концов, если Tokio окажется быстрее, чем libuv, или будет более быстрый любой другой компонент — его заберут в Node. Например, там недавно поменяли http parser, получив заметный прирост скорости. Правда, поломав при этом обратную совместимость, по этому поводу сейчас идёт срач, в котором даже я отметился.
Кстати, сравнение ивент лупов — отличная идея для поста. Напишете — сразу готов поставить плюсов, вне зависимости от результата. А пока есть только мало связанные бенчмарки. В том числе бенчмарк, который говорит, что Deno пока медленнее.
https://github.com/fukamachi/woo ускоряют довольно существенно. На уровне когда из tcp получают http
И я не писал, что Rust реализация будет медленнее. Я писал, что в лучшем случае она будет не медленнее.
Вы же понимаете, что это так вообще не работает? Вам нужно написать две крупные большие одинаковые программы на разных языках. У вас никогда не будет таких условий, что бы они соревновались в одинаковых условиях.
Поэтому выражение "программа на rust не будет быстрее С++" сильно похоже на софистику, так как вы никто не будет дословно переписывать написанное на С++ на Rust.
А так — автор все правильно сказал, растовая реализация будет такой же производительной как на С++, но никак не быстрее.
Почему не может быть быстрее? :) какие ваши аргументы кроме личного мнения?
Потому пока С++ будет не медленнее от Rust. Что будет потом — посмотрим.
И он рассматривал, как генерится асм для С++ и Rust, и объяснял что к чему, вот ссылка на момент доклада: где он рассказывает об этом.
На истину я не претендую, но ему доверяю.
Я бы не доверял столь поверхностному анализу. Например, есть разные соглашения вызова функций:
- за сохранени/восстановление регистров отвечает вызывающая функция.
- за сохранени/восстановление регистров отвечает вызываемая функция.
- часть регистров сохраняет/восстанавливает вызывающая функция, а часть вызываемая.
Нельзя вот так вот просто брать ассемберный код одной функции и сравнивать число инструкций, не разобравшись зачем они были добавлены.
Про сборщики мусора у него тоже какое-то очень поверхностное представление. Банально, он даже не понимает, что основная задача сборщика мусора, — это именно обнаружение недостижимой памяти с циклическими зависимостями. Без циклических зависимостей и обычный ARC замечательно справляется.
Меня всегда расстраивает, что в спорах подобного вида мы бенчим один и тот же бэкенд. Зачем так делать? Гораздо полезнее с практической точки зрения делать бенчи вида «rustc vs gcc (vs ещё что-нибудь — можно icc и aocc попробовать)». И смотреть результаты уже.
У нас с ним был диалог, в котором мы выяснили, что Антон написал не совсем аналогичный код. Можно написать и 1в1:
Опять же, если раст не может быть быстрее, почему actix обогнал всех в бенчах? Вы не чувствуете противоречие?
Rust добавляет больше инструкций чем С++
Так себе аргумент. Один промах мимо всех кешей — это примерно сотня инструкций. В то время как всякие проверки за выход из массива — это ноль инструкций (причем не примерно) в современных предсказателях ветвлений.
Но даже на одном и том же бэкенде мы можем получить разные результаты на казалось бы аналогичном коде за счёт того, что фронтенд прокидывает больше информации бэкенду, что позволяет ему лучше оптимизировать. Типичный пример: alias analysis, который в Rust намного легче сделать за счёт правил самого языка, что очень неплохо помогает в оптимизации. А вот C++ до сих пор (и это просто отвратительно) не имеет ничего подобного на уровне языка (не считая strict aliasing) — там нельзя ручками по стандарту разметить restrict.
Понятно, что от френтэнда зависит, какой IR он будет выдавать. Но изначальный пост был о числодробильных оптимизациях, где выхлоп IR не особо должен быть принципиален. Трюки и оптимизации раст и С++ должны получить одинаковые.
А так да, вполне пример, что скорее С++ получит меньше оптимизаций, чем раст, из-за своего С наследия.
Последний раз, когда я смотрел, разница между LLVM и GCC была пренебрежимо мала.
Пренебрежимо мала она может быть на ваших кодовых базах. На других это может быть далеко не так. Самое полное, что я видел — тесты похороникса. На некоторых тестах разница может быть довольно ощутимая (но он тестит довольное новые версии — как там на древноте обстоят дела мне неведомо).
Понятно, что от френтэнда зависит, какой IR он будет выдавать. Но изначальный пост был о числодробильных оптимизациях, где выхлоп IR не особо должен быть принципиален. Трюки и оптимизации раст и С++ должны получить одинаковые.
Это не совсем правда. На числодробление (а конкретно работу с памятью) алиасинг очень даже может повлиять. А ещё этот самый алисинг может мешать проведению других оптимизаций (тут мне сложно говорить со знанием дела, так как я не являюсь разработчиком GCC/LLVM и не разбираюсь в зависимостях между проходами компилятора сильно).
Но если мы говорим за пределами алиасинга, то скорее всего оптимизационные способности должны быть более-менее идентичны.
числодробильные оптимизации очень давно делают, используя специальную аппаратуру.
Например, блок SSE/AVX инструкций или что-нибудь типа CUDA.
Роль центрального процессора с его обобщенной системой команд не числа молотить, а логику проворачивать. А её сложнее писать, чем исполнять.
Не туда ответил.
получил я в поддержку проект в котором зависимость на удалённую github библиотеку. и всё эта особенность полностью парализует работу над проектом и его поддержку.
отсутствие npm как преимущество? это огромный недостаток!
Почему парализует-то?
Ну так, форкнуть надо было. А то и включить в свой репозиторий, через git-subtree.
а вы всегда для каждого проекта форкаете ВСЕ репозитории от которых они зависят? а зависимости зависимостей тоже форкаете? вам не кажется что такой подход существенно хуже чем использование npm, в котором эта и другие проблемы уже решены?
И форкаю, и даже пулреквесты постылаю. А вы пулреквесты без форканья делаете? Или только пользуетесь чужими трудами?
В любом случае, вы зря прицепились к самому слабому решению и проигнорировали нормальное.
а какое нормальное решение я проигнорировал?
Насколько я понял нужно послать по пулреквесту во ВСЕ зависимости. Тогда все зависимости будут форкнуты на предыдущем шаге и останется только обновить проект указав на форки. Вуаля...
Авторы пакетов которые мы так форкнем сами ничего не форкают. А значит нужно форкнуть ещё и все зависимости зависимостей. А потом и зависимости зависимостей зависимостей (:
Скажите честно вы так делаете? Вам не кажется что это забивание гвоздей микроскопом? У разработчиков давно есть инструменты которые решают проблему зависимостей без этого ручного геморроя — npm.
Там все два предложения написано. Не поленитесь, перечитайте.
ваше решение = исключить node_modules из .gitignore
но серьёзные дяди используют более серьёзное решение — локальное зеркало npm с необходимыми пакетами.
но автор Deno предлагает делать не так, он предлагает положиться на github. а этот сервис никогда не заявлял себя как реестр пакетов для сборки проектов. более того он вставляет палки в колёса тем кто пытается его так использовать — выставляя лимиты на количество скачиваний пакетов с одного IP. Фактически он предлагает отказаться от сервиса который создан для того что бы хостить пакеты, в пользу самопальных костылей на основе сервиса который противодействует что бы его использовали как хостер пакетов.
сразу оговорюсь, что я искренне надеюсь что этот сервис взлетит. Но он только-только появился (2019 год) и не имеет серьёзного проникновения в индустрию. говорить о нём всерьёз рано
Но Deno не предлагает github packages в качестве хостинга пакетов. он как и го, предлагает отказаться от хостинга пакетов в пользу хостеров репозиториев.
кстати, а гитхпакеты защищены от удаления репы? нашёл ответ сам
To avoid breaking projects that may depend on your packages, you cannot delete an entire public package or specific versions of a public package.
кстати github packages ничем не отличается от npm в плане защиты от расхождения между кодом репы и кодом пакета. так что это те же яйца только в профиль
если я правильно вас понял, вендорить — исключить node_modules из .gitignore
Как говорится Make it work, make it right, make it fast — нормальное решение выходит с третьего раза. Мне кажется подход Райна к разработке состоит в том, чтобы соединив вместе несколько хорошо зарекомендовавших себя технологий из разных областей, получить новое абсолютно бомбическое решение.
Первым была Node.js, собранная из того, что было: asyncio, libuv, V8, commonjs, streams. Много, что работает, но все сложно. Ацкий комбайн с кучей тех.долга. Как говориться — не пытайтесь повторить.
Dyno это попытка сделать удобный инструмент. Node.js сильно провязан с V8, отсюда проблемы с портированием на другие движки и обновлением рантайма. В Dyno весь такой низкоуровневый интим живёт в отдельном загончике — "ядре" — с которым остальной мир — "юзер спейс" — общается лишь протобуфами. Отсюда полный контроль над IO и вообще всем тем, что делает программа. По аналогии с браузерами, весь API четко специфицирован и доступен через общий объект Dyno. Адресация зависимостей декларируется с помощью URI как в XML, есть возможность контролировать мапинг на физические ресурсы. Встроенный бандлер для сборки приложения в исполняемый файл или модуль, как в go. Тайпскрипт, форматтер кода, куча отладочных флажков и данных — все как любят разработчики.
Lock file обеспечивает воспроизводимые сборки.
Расскажу вам несколько страшных историй про "воспроизводимость":
Для корпоративного скоупа был прописан приватный репозиторий, доступный только через корпоративный VPN. Но через корпоративный VPN недоступен публичный репозиторий. В результате работая удалённо невозможно поставить модули, так как оба репозитория не доступны одновременно.
В одной ветке был установлен один модуль, в другой — другой. Обе ветки смержили в мастер без конфликтов. Билд упал. Разработчику пришлось выкачивать к себе и обновлять лок-файл.
Добавили новую зависимость. Это вызвало каскадное обновление непредсказуемого набора непрямых зависимостей. В результате сборка сломалась. На выяснение что там с чем не совместимо потребовалось пол дня. Как итог — полный откат.
Переключаясь между ветками кто-то забыл выполнить обновление модулей, в результате чего был закоммичен лок файл от другой ветки. Билд упал.
В гробу я видал это "элегантное" решение.
2, 3 и 4 не являются спецификой локфайлов и всё то же самое могло произойти с любым другим файлом. Решение — проверять что код работает перед пушем.
Чисто для справки — в одном из моих проектов сейчас 10.000 транзитивных зависимостей. Так что я знаю, о чём говорю.
Относительно ваших кейсов:
NPM виноват в настройке вашего VPN? А чем бы вам помог другой менеджер пакетов? Так проблема хотя бы решается при помощи переключения, прокси регистри или локального кеша нужного пакета. А вот в случае с deno — я не уверен, что проблему вообще было бы возможно решить — возможно, приложение бы падало, ничего не установив… Ну а в лучшем случае точно так же пришлось бы переключаться.
Ну так стандартная проблема мерджа. С кодом случается ровно то же самое.
Обычно это проявляется гораздо быстрее — ты быстро понимаешь по юнит тестам, что именно упало, и быстро видишь по лок файлу, кто виноват. Опять же, здесь косяк авторов пакетов, которые не указали корректный скоуп зависимостей через semver.
Опять же это обычно сразу видно на код ревью — ты мгновенно замечаешь, что был закоммичен левый пекедж лок. Хотя нет. Даже раньше. Если пользуешься npm ci на билд сервере, то он сразу расскажет про расхождение package.json и package-lock.json.
Ну и главное. Я не говорю, что решение идеально. Просто всё познаётся в сравнении. И из всего того дерьма для управления зависимостями, с которым я работал последние 10 лет, npm — просто конфетка. А в данном посте я говорю даже не про это, а про сравнение npm с тем, что придумали в Deno.
Используйте локальное корпоративное зеркало npm, куда выкачиваются все зависимости из настоящего npm по необходимости.
Проблемы git merge не уникальны для npm lock file :)
Всё так. К сожалению, нет вменяемых способов подключить две разные версии одной либы сразу.
Проблемы git submodules не уникальны для npm lock file :)
6) Require без расширения и его неопределённость. Да, наверное, плохо. Но не настолько, чтобы об этом упоминать…
7) index.js как лишнее усложнение. Тоже слишком тривиальный и скучный пункт, чтобы его описывать.
Стоит заметить, что эти аспекты пофиксили в режиме ES-модулей. В них убрали автоподстановку расширения и index.js файлов. Нужно теперь указывать явный путь до файла с раширением:
https://nodejs.org/api/esm.html#esm_differences_between_es_modules_and_commonjs
P.S. ну и в принципе в этом списке нет таких пунктов, которые нельзя было бы пофиксить без переписывания всего с нуля
и так, начну сначала,
Однако я нигде так и не видел сколько-нибудь вдумчивого разбора этого проекта — почему-то все ограничиваются переводом документации...
Эта статья, так же как и твои доклад, является таким же переводом, в которые ты вложил свои додумки, реально, очень много ошибок,
Кстати, заметьте, я говорил, что Райан сожалеет о 10 вещах, а пунктов всего 7. Это не ошибка, я несколько раз пересматривал его доклад, и обзоры доклада.
Пересмотри ещё раз, и обрати внимание на пункты в package.json и index.js, особенно посмотри доклад, который был в бруклине.
В итоге я просто не вижу смысла в использовании Deno. Терпеть не могу позицию «не пробовал, но осуждаю» — но, пока что даже Райан говорит, что Deno ещё сырой — поэтому пробовать я его не стал.
Для написания статьи, ты хотя бы должен был его попробовать, ты просто написал некропост, который довольно не актуален, и как я понял ты даже не уходил с первой страницы документации, и даже умудрился ошибиться когда описывал внутренности deno, наверно твоя статья должна была вызвать хайп вокруг deno.
Понимаю что довольно много людей хотят высказать свое мнение вокруг deno, но все кто постил на хабр, к сожалению, дальше перевода доки не продвинулись.
Автор, жирный минус за статью.
Могу развеять твои сомнения и додумки в чатике, t.me/denoland
Прошу прощения, я слишком стар, чтобы идти за истиной на дуэль в чате. Однако готов признать свой позор и покаяться, если вы сможете написать статью, которая выразит ваше мнение таким образом, чтобы было понятно, почему стоит использовать Deno. Собственно за этим я свою статью и писал.
Мне не хочется именно вас просвящать по Deno, мне жаль что такие люди как вы формируют в дальнейшем мнение большинства. По моему такие персонажи называются инфоцыганами, но могу ошибаться.
Просветите других. Напишите статью, правда. Заодно десять пунктов укажете вместо семи. Искренне надеюсь в ближайшие дни увидеть статью от вас
ну а пока могу оставить ссылку на gist 9 месячной давности, в котором я собирал материалы
gist.github.com/irustm/fe60d7d91238ba3d30d5ddd7320309aa
Или хотя бы кратко в комментариях тут.
Аргументы автора против Дино звучат разумно. Я был бы рад ознакомиться с аргументами ЗА Дино, пусть и тезисно.
Все аргументы сводятся к тезису «Это неправильная нода, она делает неправильный мед».
Я смотрю с точки зрения enterprise. Как это в Java, Python, Golang, даже в PHP.
1. NPM — это SPF, это просто не проходит по SLA. С прямым импортом удобно делать свой репозиторий. Будет обертка, как composer в PHP.
2. NPM за периметром безопасности, исходящий трафик за фаервол открывать никто не будет. Без вариантов, никаких скачиваний пакетов со стороны при сборке.
3. TypeScript хорош. Никто не хочет писать на JS после Java или Golang, а на TS — вполне.
4. Никого не смущает связь парсера Java с Runtime — это самая популярная в мире платформа. Наоборот, такую связку проще поддерживать, меньше невоспроизводимых багов.
5. Кеширование результата компиляции в файлах или в памяти — детали реализации. Python и Java не страдают.
И так далее. Каждый тезис в этой статье — в пользу Deno.
- Знаю SPF как Sun Protection Factor и как Sender Policy Framework. Не понял, что вы имели в виду.
- А скачивание зависимостей с произвольных левых сайтов не считается? Или вы про случай когда всё это скопом кладётся в гит? Ну так никто не запрещает и node_modules в гит класть...
- Да кто ж спорит. Но тот же тайпскрипт и в ноде так же работает.
- Ну тогда уж надо сразу собирать в один бинарник nginx, deno и mysql, что уж там. Но кстати это уже было. Denver что ли называлось.
- Так я и не писал, что это какой-то минус, вы это сами придумали.
2. Не произвольные, а внутренние корпоративные репозитории.
3. Не так же — сложнее дебажить, нужен мапинг через карту.
4. софизм
5. скрывать результат компиляции хорошо тем, что результат можно будет оптимизировать в байткод, и добавить JIT, а это выведет скорость вычислений на уровень Java и Python
- Ну так с импортом откуда попало будут множественные точки отказа, каждая из которых приведёт к невозможности сборки, что ещё хуже. Или я не понял вашу мысль.
- Если мы говорим про внутренние репозитории, то компании точно так же пользуются внутренними приватными npm репозиториями. Вообще не вижу разницы.
- А дино можно дебажить прямо в TS? Если да, то это круто, но не очень понимаю, в чём тут может быть разница. Хотя с первого взгляда вижу issue, что у дино даже в девтулз не работает дебаг. Ну и в той же issue обсуждают, что оно точно так же через source maps работать будет...
- Не софтистика, просто пример решения "запихаем несколько разных бинарников в один, чтобы было проще". Навскидку в голову больше аналогичных примеров не приходит.
- Не понял, чем вам поможет то что вы спрятали результат компиляции в другую папку. Какая разница, где он лежит? Насчёт "добавить JIT" — вы говорите странное, в V8 и так AOT+JIT. Ну и про "выведет скорость вычислений на уровень Java и Python" — это вы совсем странное говорите. Как бы нода уже быстрее или примерно на том же уровне, если мы не говорим про какие-то совсем специфичные вещи или мультитрединг.
Видимо, подмена понятий во всех пяти пунктах...
Вот самое обидное — что у меня нет никакого предвзятого отношения к Дино или Райану, и нет желания доказать, что дино это плохо. Мне за это, как понимаете, денег никто не платит. Я реально хочу понять, что там нового и интересного. И в том числе отвечаю вам, чтобы понять это.
Ну ладно. Тогда то же предложение, что и выше — напишите свою статью, где понятно раскроете, в чём я не прав, и чем хорош дино. Там это гораздо удобнее делать, чем в комментариях или не дай бог в чате.
Попробую и я ответить
NPM — это SPF, это просто не проходит по SLA.
Аналогичная ситуация с Maven central, Rubygems, Pypi. Энтерпрайзы давно научились поднимать зеркала репозиториев и работать с ними. Прописать npm config set registry https://my.company.com/ гораздо проще, чем перехватывать вызовы к десяткам разных доменов.
TypeScript хорош.
Typescript можно и в Node запустить, это не является чем-то уникальным. Проблема в том, что в Deno он прибит гвоздями. Захотелось вам версию 3.7 с optional chaining, придется сидеть и ждать пока Deno соблаговолит обновиться.
Deno: время Node.JS уходит?