Вы самостоятельно выдвигаете тезисы, никак не связанные с моей статьёй и комментариями, приписываете мне, а затем мастерски их опровергаете. Пожалуй, не буду мешать.
К сожалению, работающее ПО может быть постоянно и стабильно работающим только в условии, если оно сферическое в вакууме — или в постоянных условиях эксплуатации.
Самый простой кейс — десктопное ПО. В этом случае проблем минимум — на него могут повлиять нестандартные настройки пользователя, обновления библиотек, ОС, драйверов и железа.
Чуть сложнее — ПО для мобильной платформы. Каждый новый апдейт Android и IOS ломает огромное количество приложений самыми причудливыми способами.
Простые сайты вроде веб магазинов или блогов — да, могут быть достаточно стабильными. Но если мы возьмём чуть более сложные приложения, в которых есть интеграции с поставщиками всего и вся — то да, здесь именно что "откуда невозмись выползают огромные жуки и ломают разного рода системы". И это я даже не говорю про фронтенд, где из зоопарка постоянно обновляемых браузеров и устройств в любой момент может вырваться вообще всё что угодно.
Так что на примере ПО мог бы написать всё то же самое, что и с кораблями, с кучей примеров — но будет скучно.
Не подумайте, что придираюсь, но, честно говоря, формулировка
все же знают, что части «npm» в Node.js написаны на «rust»
не сильно лучше. Потому что эти "части" это авторизация в регистри. Регистри это важный компонент экосистемы, но непосредственно к Node.JS не относится. Ну и кроме того, npm это не только регистри для Node.JS — но ещё и для огромного количества фронтовых пакетов...
Лично мне раст при этом нравится, но как-то чересчур сильно сову на глобус натягиваете — лопнет же. На сайте самого раста, кстати, формулировка абсолютно корректна.
Вместо этого натягивания, вы могли бы, например, написать про Deno. Это уже гораздо интереснее и масштабнее.
А я в первом комментарии написал, что там было на самом деле. Можете перечитать его. Такие ответы вызывают в целом сомнения в компетенции и адекватности автора.
Вот самое обидное — что у меня нет никакого предвзятого отношения к Дино или Райану, и нет желания доказать, что дино это плохо. Мне за это, как понимаете, денег никто не платит. Я реально хочу понять, что там нового и интересного. И в том числе отвечаю вам, чтобы понять это.
Ну ладно. Тогда то же предложение, что и выше — напишите свою статью, где понятно раскроете, в чём я не прав, и чем хорош дино. Там это гораздо удобнее делать, чем в комментариях или не дай бог в чате.
Ну так с импортом откуда попало будут множественные точки отказа, каждая из которых приведёт к невозможности сборки, что ещё хуже. Или я не понял вашу мысль.
Если мы говорим про внутренние репозитории, то компании точно так же пользуются внутренними приватными npm репозиториями. Вообще не вижу разницы.
А дино можно дебажить прямо в TS? Если да, то это круто, но не очень понимаю, в чём тут может быть разница. Хотя с первого взгляда вижу issue, что у дино даже в девтулз не работает дебаг. Ну и в той же issue обсуждают, что оно точно так же через source maps работать будет...
Не софтистика, просто пример решения "запихаем несколько разных бинарников в один, чтобы было проще". Навскидку в голову больше аналогичных примеров не приходит.
Не понял, чем вам поможет то что вы спрятали результат компиляции в другую папку. Какая разница, где он лежит? Насчёт "добавить JIT" — вы говорите странное, в V8 и так AOT+JIT. Ну и про "выведет скорость вычислений на уровень Java и Python" — это вы совсем странное говорите. Как бы нода уже быстрее или примерно на том же уровне, если мы не говорим про какие-то совсем специфичные вещи или мультитрединг.
Знаю SPF как Sun Protection Factor и как Sender Policy Framework. Не понял, что вы имели в виду.
А скачивание зависимостей с произвольных левых сайтов не считается? Или вы про случай когда всё это скопом кладётся в гит? Ну так никто не запрещает и node_modules в гит класть...
Да кто ж спорит. Но тот же тайпскрипт и в ноде так же работает.
Ну тогда уж надо сразу собирать в один бинарник nginx, deno и mysql, что уж там. Но кстати это уже было. Denver что ли называлось.
Так я и не писал, что это какой-то минус, вы это сами придумали.
Прошу прощения, я слишком стар, чтобы идти за истиной на дуэль в чате. Однако готов признать свой позор и покаяться, если вы сможете написать статью, которая выразит ваше мнение таким образом, чтобы было понятно, почему стоит использовать Deno. Собственно за этим я свою статью и писал.
Насчёт грепа — скорость грепа особо не волнует, пока она приемлима. Он не создаёт нагрузку на продакшн сервера, знаете ли.
Пример с openssl более релевантен, хотя там тоже могут быть свои подводные камни вроде безопасности и совместимости — не готов про это говорить, тема сложная. Но рад если всё так.
Ну и просто хочу напоминить, что холиварю не по поводу Rust vs C++, а по поводу преимуществ Deno над Node. В конце концов, если Tokio окажется быстрее, чем libuv, или будет более быстрый любой другой компонент — его заберут в Node. Например, там недавно поменяли http parser, получив заметный прирост скорости. Правда, поломав при этом обратную совместимость, по этому поводу сейчас идёт срач, в котором даже я отметился.
Кстати, сравнение ивент лупов — отличная идея для поста. Напишете — сразу готов поставить плюсов, вне зависимости от результата. А пока есть только мало связанные бенчмарки. В том числе бенчмарк, который говорит, что Deno пока медленнее.
Про это Райан ничего не говорил, не уверен, что он на это рассчитывал.
Согласен с тем, что есть проблема в том, что исходники могут не совпадать с тем, что положено в регистри. Хотя вроде как сейчас npm за этим хоть как-то приглядывает — и я надеюсь, что в будущем будет делать это более внимательно — например, будет сам выполнять prepublish из указанного репозитория.
Ну и проблема подмены кода таким импортом тоже не решается — ничего не мешает автору менять содержимое репозитория по 3 раза на дню, подкладывая туда эксплойты. Даже в якобы фиксированной версии. В ноде для этого хотя бы проверка хешей есть, а дино никогда не узнает, что его обманули.
Мне кажется, всё прозаичнее — Райан фактически продал ноду в Joyent, а сейчас хочет повторить успех, и продать снова или себя или движок, пользуясь культом личности себя.
Вы самостоятельно выдвигаете тезисы, никак не связанные с моей статьёй и комментариями, приписываете мне, а затем мастерски их опровергаете. Пожалуй, не буду мешать.
К сожалению, работающее ПО может быть постоянно и стабильно работающим только в условии, если оно сферическое в вакууме — или в постоянных условиях эксплуатации.
Самый простой кейс — десктопное ПО. В этом случае проблем минимум — на него могут повлиять нестандартные настройки пользователя, обновления библиотек, ОС, драйверов и железа.
Чуть сложнее — ПО для мобильной платформы. Каждый новый апдейт Android и IOS ломает огромное количество приложений самыми причудливыми способами.
Простые сайты вроде веб магазинов или блогов — да, могут быть достаточно стабильными. Но если мы возьмём чуть более сложные приложения, в которых есть интеграции с поставщиками всего и вся — то да, здесь именно что "откуда невозмись выползают огромные жуки и ломают разного рода системы". И это я даже не говорю про фронтенд, где из зоопарка постоянно обновляемых браузеров и устройств в любой момент может вырваться вообще всё что угодно.
Так что на примере ПО мог бы написать всё то же самое, что и с кораблями, с кучей примеров — но будет скучно.
Да, в эту сторону тоже бывает. В особенности если корабль бюджетный.
Кроме корабля, это так же валюта из мира писательницы Джоан Роулинг. Но да, неудачно совместил контексты, поменяю.
Присоединяюсь, tmfeed читать гораздо удобнее было, а править ссылку каждый раз после открытия статьи через m.habr.com — неудобно.
Не подумайте, что придираюсь, но, честно говоря, формулировка
не сильно лучше. Потому что эти "части" это авторизация в регистри. Регистри это важный компонент экосистемы, но непосредственно к Node.JS не относится. Ну и кроме того, npm это не только регистри для Node.JS — но ещё и для огромного количества фронтовых пакетов...
Лично мне раст при этом нравится, но как-то чересчур сильно сову на глобус натягиваете — лопнет же. На сайте самого раста, кстати, формулировка абсолютно корректна.
Вместо этого натягивания, вы могли бы, например, написать про Deno. Это уже гораздо интереснее и масштабнее.
А я в первом комментарии написал, что там было на самом деле. Можете перечитать его. Такие ответы вызывают в целом сомнения в компетенции и адекватности автора.
А вы пробовали дальше заголовка читать?
Ну вот, например.
Насколько я знаю, на расте там только сервис авторизации переписывали.
Видимо, подмена понятий во всех пяти пунктах...
Вот самое обидное — что у меня нет никакого предвзятого отношения к Дино или Райану, и нет желания доказать, что дино это плохо. Мне за это, как понимаете, денег никто не платит. Я реально хочу понять, что там нового и интересного. И в том числе отвечаю вам, чтобы понять это.
Ну ладно. Тогда то же предложение, что и выше — напишите свою статью, где понятно раскроете, в чём я не прав, и чем хорош дино. Там это гораздо удобнее делать, чем в комментариях или не дай бог в чате.
Прошу прощения, я слишком стар, чтобы идти за истиной на дуэль в чате. Однако готов признать свой позор и покаяться, если вы сможете написать статью, которая выразит ваше мнение таким образом, чтобы было понятно, почему стоит использовать Deno. Собственно за этим я свою статью и писал.
Там если покопаться в переписке в issues и в релизах, то видно, что они сейчас только уязвимости закрывают — кроме этого никакой работы не идёт.
На и в node-chakracore то же самое видно.
Гмм, и то правда, вроде месяц назад добавили. Ну можно поздравить ребят — они заново изобрели лок файлы....
От ркн загрузка по урлам и из репозитория тоже не поможет. Благо решается это легко — проходили.
Вы игнорируете 90% того, что я пишу, и спорите с вырванными из контекста кусками. На этом, пожалуй, закончу.
Насчёт грепа — скорость грепа особо не волнует, пока она приемлима. Он не создаёт нагрузку на продакшн сервера, знаете ли.
Пример с openssl более релевантен, хотя там тоже могут быть свои подводные камни вроде безопасности и совместимости — не готов про это говорить, тема сложная. Но рад если всё так.
Ну и просто хочу напоминить, что холиварю не по поводу Rust vs C++, а по поводу преимуществ Deno над Node. В конце концов, если Tokio окажется быстрее, чем libuv, или будет более быстрый любой другой компонент — его заберут в Node. Например, там недавно поменяли http parser, получив заметный прирост скорости. Правда, поломав при этом обратную совместимость, по этому поводу сейчас идёт срач, в котором даже я отметился.
Кстати, сравнение ивент лупов — отличная идея для поста. Напишете — сразу готов поставить плюсов, вне зависимости от результата. А пока есть только мало связанные бенчмарки. В том числе бенчмарк, который говорит, что Deno пока медленнее.
Про это Райан ничего не говорил, не уверен, что он на это рассчитывал.
Согласен с тем, что есть проблема в том, что исходники могут не совпадать с тем, что положено в регистри. Хотя вроде как сейчас npm за этим хоть как-то приглядывает — и я надеюсь, что в будущем будет делать это более внимательно — например, будет сам выполнять prepublish из указанного репозитория.
Ну и проблема подмены кода таким импортом тоже не решается — ничего не мешает автору менять содержимое репозитория по 3 раза на дню, подкладывая туда эксплойты. Даже в якобы фиксированной версии. В ноде для этого хотя бы проверка хешей есть, а дино никогда не узнает, что его обманули.
Мне кажется, всё прозаичнее — Райан фактически продал ноду в Joyent, а сейчас хочет повторить успех, и продать снова или себя или движок, пользуясь культом личности себя.