Доступен релиз Node.js 13.0.0, платформы для выполнения сетевых приложений на языке JavaScript. Одновременно завершена стабилизация прошлой ветки Node.js 12.x, которая переведена в категорию выпусков с длительным сроком поддержки, обновления для которых выпускаются в течение 4 лет. Поддержка прошлой LTS-ветки Node.js 10.0 продлится до апреля 2021 года, а позапрошлой LTS-ветки 8.0 до января 2020 года...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51741
> Ни одна функция в Node.js не должна напрямую выполнять операции ввода/вывода - для получения данных с диска, от другого процесса или из сети требуется установка callback-обработчика.Не актуально, вместо callback можно использовать асинхронные генераторы (async/await) почти во всех встроенных API.
Фанаты скобочек негодуют.
Нет, просто промисы - стандартизированная обертка над колбеками. А асинки - синтаксический сахар над промисами.Внутри все равно все работает через те же коллбеки.
> А асинки - синтаксический сахар над промисамиasync/await это генераторы (*/yield), возвращающие промисы. А не сахар над промисами.
Во, а можете статью скинуть, как именно оно там устроено. Если с промисами всё понятно, то async/await в JS я ещё не тыкал. Тыкал в python, и оно подобно языку в языке -- на местах соединения синхронного кода с асинхронным больно
Скомпилируй babel-ом и увидишь, как примерно это работает.
Нет уж промисы это больший уровень абстракции.
Ссылка на Ruby Event Machine перекидывает на какую-то отельную хрень...
>серверной JavaScript-платформыЧёт у меня все браузеры и куча игрушек тянут её, первые наверно для этих куцых хромовых аддонов, а вторые как интерпретатор жс. Где тут сервера не понятно.
Где тут сеть тоже не понятно, всё оффлайн и на локалхосте.
Ну, ты же не жалуешься, что питон тащат с собой все кому не лень, а на нем тоже сервера пишут.Современная нода – просто еще один удобный универсальный интерпретатор скриптового языка с большим количеством готовых модулей. Почему бы ее не использовать для небольших скриптов?
Потому что вычислительные ресурсы не бесконечны. Так можно скрипты и нейронной сетью выполнять на видеокартах только старше 1080. Зато код маленький.
У тебя есть пример, когда нода, работающая локально как скриптовый язык беспричинно выжирала гигабайты памяти?
Ой щас тру стори начнутся типа: Да у меня нода всю память сожрала просто так, весь процессор оккупировала, чёрную дыру в полу открыла. Да и вабще, ваш виндас говно
Не буду показывать пальцем, но как-нибудь попробуй заюзать библиотеку jsdom https://www.npmjs.com/package/jsdom и ты узнаешь что можно съесть и больше.
Если ты ее юзал для парсинга сайтов в цикле, то там очень просто сделать утечку памяти, так как jsdom сам не убивает таймеры и они мешают gc уничтожить window. Когда контекст тебе уже не нужен надо вызывать явно window.close()
Звучит правдоподобно.
Потому что петон уже есть у пользователей искаропки во всех дистрибутивах, и зачем тащить ноду для маленького скриптика действительно непонятно.
У питона, по сравненю с нодой, в плане удобства разработки никаких преимуществ нету. Если человек знает хорошо ноду и фигово знает питон, то уж лучше он добавит в зависимости ноду, чем напишет кривой говнокод на питоне. Зато сэкономит 20Мб на диске.
зависимость - это типа
nmp install my_super_rootkit_from_chinese_hacker?
Да, как и, например:
pip install my_super_rootkit_from_chinese_hacker
go get my_super_rootkit_from_chinese_hacker
gem install my_super_rootkit_from_chinese_hacker
cargo install my_super_rootkit_from_chinese_hacker
git clone my_super_rootkit_from_chinese_hacker_on_c_plus_plus.git
я хз, у мну apt-get && yum install и salt '*' state.applyПыСы - а че, подписи пакетов и защиту от SJW уже завезли ? :))
>git clone my_super_rootkit_from_chinese_hacker_on_c_plus_plus.gitconan install my_super_rootkit_from_chinese_hacker
>Потому что петон уже есть у пользователей искаропки во всех дистрибутивах, и зачем тащить ноду для маленького скриптика действительно непонятно.# pkg info python37 | grep size
Flat size : 110MiB# pkg info node | grep size
Flat size : 34.7MiB
мне тоже непонятно, зачем тащить 110Mb петона, когда нода втрое меньше.
и втрое быстрее, кстати
И всё-равно также дико тормозит и глючит.
Есть quickjs, гораздо меньше.
Пока не сделают async_hooks stable пользоваться нельзя
Он нам и нафиг не нужон этот ваш async_hooks. Деды без него жили и нам завещали.В JS и так полно всяких костылей/хуков, которые все только замедляют и усложняют: геттеры/сеттеры, прокси, фризы и т.п. лабудень. Из адекватов никто ими не пользуется в продакшене, потому что, во-первых, код превращается в сплошную магию, не понятно, что откуда берется и в каком месте может навернуться, а во-вторых, производительность падает в разы.
Приведи хотя бы один пример, когда бы async_hooks можно было использовать в продакшене не для отладки.
Пример, в коде есть ошибка из-за которой node.js падает. Поскольку node.js грузит одно ядро то в случае 4-х ядерного проца и запущенного в кластере node.js злоумышленнику достаточно послать всего 4-ре запроса для осуществления DOS'а. В этом случае злоумышленнику не требуется вообще никаких заметных мощностей, он может валить сайт с любого компа, даже с компа своей бабушки.
Как легко найти такую ошибку? Никак. Только весь скрупулёзно код просматривать.Вот тут-то async-hooks и спасут.
Тут ты используешь это разово для отладки. Не все ли равно, стабильное ли это будет апи, если после нахождения проблемы ты все выпилишь?
Доклад посмотри, никто это выпиливать в продакшене не собирается.
async_hooks нужны для отладки внутренних асинхронных вызовов. Но вообще, для этого есть более удобные инструменты.По поводу пассажа про 4 ядра и 4 запроса это такой бред, что и комментировать не хочется. Учите как работает even loop и асинхронная обработка запросов.
Это тебе нужно подучить мат.часть. Человек всё верно написал, если один запрос будет валить процесс ноды то всего потребуется 4 запроса, чтобы завалить процессы ноды на всех 4-х ядрах.
Процессы ноды конечно подымутся по скрипту, но их опять же так просто и завалят.Ты ни как не сможешь определить какой конкретно ассинхроyный запрос валит ноду, без asynk hooks никак.
В тредпуле обрабатывается только чтение сокетов. Парсер http , как и js работает в майн потоке. Если обработчик написан криво, то любой первый запрос свалит ноду, неважно сколько в очереди стоит запросов на обработку.
Вы там у себя в "Единая Россия" все такие?
Вот в этом докладе вроде про это говориться https://www.youtube.com/watch?v=STyocIjskBE
Update https://www.youtube.com/watch?v=Lrs6puJ4G2Q
Я сокращенную версию посмотрел, 50 минутную нет.UnhandledException возникает, когда выкидываешь эксепшен внутри промисов. Везде и всегда написано, что этого делать нельзя. Если что-то может выкинуть исключение – оборачивай в try/catch и catch вызывай reject. асинки этих проблем лишены. Там все, если упрощенно, кодогенерацией обернется в try/catch и в случае исключения вызовется reject.
Чистые промисы лучше использовать по минимуму и с осторожностью.
По поводу же распутывания того, по какой причине был запущен тот или иной ассинхронный метод, является общей проблемой, а не чисто нодовской.
Обычно, это решается заведением некого "контекста" или маркера, который генерируется в самом начале, при получении запроса и сопровождает все цепочки ассинхронных вызовов. Например, можно его отображать во всех логах и потом, просто погрепав логи по этому маркеру, найти все асинхронные вызовы, которые были совершены.
Но это для оффлайновых разбирательств, почему у кого-то там что-то падает. При нормальном написании кода, у пользователя не должно быть пятиминутных таймаутов из-за того, что что-то там отвалилось.
Твою поток мыслей не читал, ничего умного ты написать не мог. Вот тебе коммент из под видео которое 50 минут - Раньше смотрел его и не понимал, думал - чудик какой-то, но сегодня столкнулся. Когда в ноде один процесс и много клиентов unhandledError НИКАК не может определить с какого клиента пришла ошибка. Благо сейчас проект где можно разделить на процессы для каждого клиента, но в будущем это конечно серьезный повод задуматься.
>Твою поток мыслей не читал, ничего умного ты написать не могне читал, но осуждаю!
Почитал и осуждаешь?
Именно. Прочитал первое предложение, а дальше понял, что и ты ничего умного написать не мог.
> UnhandledException возникает, когда выкидываешь эксепшен внутри промисов.Что? Если кинуть ексепшн внутри промиса, то во-первых, выпадет UnhandledRejection, а во-вторых, это случится только если ты не обработал ошибку внутри catch (или с помощью try-catch при использовании async-await). Внутри new Promise, или в then ты можешь свободно сделать throw Error и ничего тебе не будет, пока ты эту ошибку обрабатываешь далее. UnhandledException это более общий ивент, который может возникнуть если кинуть ошибку и не обработать её в любом месте - например, при обработке данных внутри своего класса стрима.
Не читал, но думаю что ты его осуждаешь.
А питон то ей зачем нужен?
Для сборки на этапе компиляции.
Иногда при сборке дополнений на C/C++ зачем то использует инфраструктуру Python для компиляции. Видимо не хотят свою собсвтенную использовать, а вообще выглдит действительно странно.
Неосиляторы баша, батчскрипта.
костылеподелия (по сравнению с современными полноценными скриптовыми языками, конечно)
> не хотят свою собсвтенную использоватьЕще одну систему сборки? Нет, спасибо.
gyp остался по историческим причинам, потому что google через него собирал v8.
Для gyp
Для Си тоже написаны сетевые либы, которые могут все то же, только, на минуточку, в десятки раз быстрее и в десятки раз меньше потребляют памяти, полностью протестированы, стабильны, и не от Васяна. Мышки, одумайтесь, зачем вам жрать кактус?
И много ты завершенных серверных приложений на чистых сях за свою жизнь написал?
А ты, много ли ты кактусов сожрал? Много, да? Гордись собой!
Вообще парень прав, но вот кто сегодня готов за такое платить?
ИСпользуют такие языки не потому что любят, а потому что студент пишущий на JavaScript это дешево и удобно, а программист на Си со знанием всех деталей стоит как половина машины в цесяц.А теперь потеме, я сожрал не менее трех кактусов и написал не меенее двух сетевых приложений на C++ и горд этим. Впечатление от JS кстати хорошее, но чего точно не зватает так это перформанс бенчмарков и прочих рюшечек в самом libuv что бы можно было сказать что все действительно честно работало, а то столкнулся с тем что простой парсинг HTTP в старых версиях сравнительно задерживал весь EventLoop.
Если кто то и пишет бек на С++ то это кто-то типа Яндекса. Где получается что от экономии на ресурсах можно вместо двух датацентров использовать один.
Вообще-то Яндекс активно использует Node.js в некоторых проектах.
Вообще-то их поисковый движек был на C++ когда слова бекенд еще не было в тренде.
Вообще-то был...
> простой парсинг HTTP в старых версиях сравнительно задерживал весь EventLoop.Вообще, есть такая штука, как threads pool
UV_THREADPOOL_SIZE=128 решает все проблемы с внутренним кодом самой ноды.
Старый http парсер довольно костыльный и неоптимальный. Скажем спасибо Феде, что переписал это говно.
Жаль, Федя все меньше уделяет время разработке самой Ноды.
Ага. А когда ты бэк пишешь на си, как это называется? Поедание кактуса обмазанного калом? Пофиг, что в коде на чистом си повсюду сплош и рядом будут анальные бэкдоры и течи, что код станет с трудом поддерживаемым, что простой скрипт будет занимать несколько рабочих дней (и это при методике "ху.., ..як и в продакшн, а с тестами, ревью и аппрувами можно вообще закрывать кантору"), но зато будет быстро (и то не факт). Люди просто так абстракции придумывают (кстати, этот ваш си - это абстракция ассемблера), так что давайте писать на бинарном коде. (Тсссс, говорят, что в ноде можно писать на С/C++).
Для этого есть всякие kore.io. В принципе, любой серьёзный продакшен, критичный до производительности, использует плюсы на бэке, а там и до сишечки не далеко. Есть ещё лайтовый вариант нанять жабакодеров налабать по-быстрому, а проблемы решать костылями по мере поступления. В вашем представлении серьёзный продекшен это видимо тысячи серверов с питоном и пхп, но это не так, у них тысячи серверов только потому что это более экономически целесообразно, чем перезапустить проект и потерять всё в процессе (да и не стоит таких требований, пусть даже это позводит выкинуть половину серверов).
В настоящее время для серьезного продакшена с производительностью тренд начинает понемногу поворачивается в сторону всяких растов и го. Просто на плюсах слишком дофига плюшек написано, много унаследованного софта. Инерция.
Вам пожарных, может, вызвать или сапёров? Не могу разобраться - у вас бомбит или подгорает.
> Поедание кактуса обмазанного каломСтарый добрый опеннет и его эксперты...
*Греф ставит лайк вашему комментарию*
> говорят, что в ноде можно писать на СМожно. Пишу. Кстати хорошо бы разобраться с libeio для переиспользования их потоков, а то пока своими пользуюсь.
> А когда ты бэк пишешь на си, как это называется?разработка это называется.
1 на С писать дольше. в среднем раза в два.
2 пользуют библиотеки, иногда свои (у меня всякие очереди-сеты-вектора юзаются с вариациями лет 10-15)
3 в общем работает быстрее раза в два-пять быстрее чем на ноде
при очень компактном бинарном коде.лучше писать в псевдо-объектном стиле - структура, всегда конструктор-аллокатор, методы, всегда деструктор.
для нано-микросервисов самое то.
особенно для всяких брокеров к оборудованию, для которых писать прослойку к интерпретатору еще дольше.
и/или там где асинхронное поведение нежелательно.но одно второго не отменяет.
Ага вон такие же одноклеточные иксперты реализовали хайлоад на С++ с событийным движком с очередью с приоритетом на простом связном списке. И у них странным образом все тормозит.https://www.opennet.ru/openforum/vsluhforumID3/118724.html#11
>Ага вон такие же одноклеточные иксперты реализовали хайлоадсдуру можно все сломать.
но вообще-то как микросервис аля реактор модель и пачкой нитей, все в районе libc & pthread, в три страницы кода, чудесным образом разруливает 10K на ARM.
потеет, машет вентилятором, но разруливает.привести пример не просите, не дам.
Хипстеры пока еще не дотянулись до ARM'ов поэтому вполне вероятно там все гораздо лучше.
https://www.techempower.com/benchmarks/#section=data-r18&hw=...
(не смотреть на es4x - это кастомная борода на JVM, которая умеет в том числе и JS)От 2 до 5 раз - это у тебя в десятки? Почему сразу не на пару порядков?
Опять не осилили. Отодвинули светлое будущее еще на год вперёдECMAScript Modules#
Stability: 1 - ExperimentalХотя обещали https://2ality.com/2019/04/nodejs-esm-impl.html#using-es-mod...
Просто никому не интересно это стало, так как пришла мода писать на тайпскрипте, а там оно уже есть.
Тьюринг-полноту из системы типов тайпскрипта уже убрали?
Прежде чем писать "неосилили", сначала все детали почитайте. У ноды огромная экосистема модулей. Было довольно сложно подружить commonjs модули и ES модули. Но решение, кстати, есть. И в 13 и 14 ноде ES модули модули, возможно стабилизируются.
Хватит это терпеть
Не совсем в тему, но меня тут порадовало:https://github.com/axboe/liburing/blob/master/examples/ucont...
async/await с io_uring на C! :)
Стоит учить сабж полному нубу в программировании?
можно и с нодой покапаться и с еще чем-то, хуже то от этого не должно стать.
тут вопрос, что в результате спрограммировать хочется.