1.1, Аноним (1), 09:55, 24/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
> Ни одна функция в Node.js не должна напрямую выполнять операции ввода/вывода - для получения данных с диска, от другого процесса или из сети требуется установка callback-обработчика.
Не актуально, вместо callback можно использовать асинхронные генераторы (async/await) почти во всех встроенных API.
| |
|
|
3.14, Anonimous (?), 11:17, 24/10/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Нет, просто промисы - стандартизированная обертка над колбеками. А асинки - синтаксический сахар над промисами.
Внутри все равно все работает через те же коллбеки.
| |
|
4.33, Аноним (1), 12:35, 24/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А асинки - синтаксический сахар над промисами
async/await это генераторы (*/yield), возвращающие промисы. А не сахар над промисами.
| |
|
5.39, kai3341 (ok), 13:29, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Во, а можете статью скинуть, как именно оно там устроено. Если с промисами всё понятно, то async/await в JS я ещё не тыкал. Тыкал в python, и оно подобно языку в языке -- на местах соединения синхронного кода с асинхронным больно
| |
|
|
|
|
1.2, Виктор (??), 10:02, 24/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ссылка на Ruby Event Machine перекидывает на какую-то отельную хрень...
| |
1.3, Аноним (3), 10:22, 24/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>серверной JavaScript-платформы
Чёт у меня все браузеры и куча игрушек тянут её, первые наверно для этих куцых хромовых аддонов, а вторые как интерпретатор жс. Где тут сервера не понятно.
| |
|
2.4, Аноним (3), 10:23, 24/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Где тут сеть тоже не понятно, всё оффлайн и на локалхосте.
| |
|
3.7, Anonimous (?), 10:57, 24/10/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
Ну, ты же не жалуешься, что питон тащат с собой все кому не лень, а на нем тоже сервера пишут.
Современная нода – просто еще один удобный универсальный интерпретатор скриптового языка с большим количеством готовых модулей. Почему бы ее не использовать для небольших скриптов?
| |
|
4.11, Аноним (9), 11:12, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Потому что вычислительные ресурсы не бесконечны. Так можно скрипты и нейронной сетью выполнять на видеокартах только старше 1080. Зато код маленький.
| |
|
5.13, Anonimous (?), 11:15, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
У тебя есть пример, когда нода, работающая локально как скриптовый язык беспричинно выжирала гигабайты памяти?
| |
|
6.15, Аноним (15), 11:22, 24/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ой щас тру стори начнутся типа: Да у меня нода всю память сожрала просто так, весь процессор оккупировала, чёрную дыру в полу открыла. Да и вабще, ваш виндас говно
| |
|
7.59, Аноним (59), 16:30, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Если ты ее юзал для парсинга сайтов в цикле, то там очень просто сделать утечку памяти, так как jsdom сам не убивает таймеры и они мешают gc уничтожить window. Когда контекст тебе уже не нужен надо вызывать явно window.close()
| |
|
|
|
4.23, Аноним (23), 11:49, 24/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Потому что петон уже есть у пользователей искаропки во всех дистрибутивах, и зачем тащить ноду для маленького скриптика действительно непонятно.
| |
|
5.31, Anonimous (?), 12:20, 24/10/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
У питона, по сравненю с нодой, в плане удобства разработки никаких преимуществ нету. Если человек знает хорошо ноду и фигово знает питон, то уж лучше он добавит в зависимости ноду, чем напишет кривой говнокод на питоне. Зато сэкономит 20Мб на диске.
| |
|
|
7.76, Аноним (76), 07:33, 25/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да, как и, например:
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
| |
|
|
5.71, qwerty123 (??), 23:16, 24/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Потому что петон уже есть у пользователей искаропки во всех дистрибутивах, и зачем тащить ноду для маленького скриптика действительно непонятно.
# pkg info python37 | grep size
Flat size : 110MiB
# pkg info node | grep size
Flat size : 34.7MiB
мне тоже непонятно, зачем тащить 110Mb петона, когда нода втрое меньше.
| |
|
|
|
|
|
2.8, Anonimous (?), 11:08, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Он нам и нафиг не нужон этот ваш async_hooks. Деды без него жили и нам завещали.
В JS и так полно всяких костылей/хуков, которые все только замедляют и усложняют: геттеры/сеттеры, прокси, фризы и т.п. лабудень. Из адекватов никто ими не пользуется в продакшене, потому что, во-первых, код превращается в сплошную магию, не понятно, что откуда берется и в каком месте может навернуться, а во-вторых, производительность падает в разы.
Приведи хотя бы один пример, когда бы async_hooks можно было использовать в продакшене не для отладки.
| |
|
3.18, Аноним (6), 11:34, 24/10/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
Пример, в коде есть ошибка из-за которой node.js падает. Поскольку node.js грузит одно ядро то в случае 4-х ядерного проца и запущенного в кластере node.js злоумышленнику достаточно послать всего 4-ре запроса для осуществления DOS'а. В этом случае злоумышленнику не требуется вообще никаких заметных мощностей, он может валить сайт с любого компа, даже с компа своей бабушки.
Как легко найти такую ошибку? Никак. Только весь скрупулёзно код просматривать.
Вот тут-то async-hooks и спасут.
| |
|
4.20, Anonimous (?), 11:40, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Тут ты используешь это разово для отладки. Не все ли равно, стабильное ли это будет апи, если после нахождения проблемы ты все выпилишь?
| |
|
5.21, Аноним (6), 11:42, 24/10/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Доклад посмотри, никто это выпиливать в продакшене не собирается.
| |
|
4.61, Анон Анонов (?), 19:13, 24/10/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
async_hooks нужны для отладки внутренних асинхронных вызовов. Но вообще, для этого есть более удобные инструменты.
По поводу пассажа про 4 ядра и 4 запроса это такой бред, что и комментировать не хочется. Учите как работает even loop и асинхронная обработка запросов.
| |
|
5.64, Автор libuv (?), 19:56, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Это тебе нужно подучить мат.часть. Человек всё верно написал, если один запрос будет валить процесс ноды то всего потребуется 4 запроса, чтобы завалить процессы ноды на всех 4-х ядрах.
Процессы ноды конечно подымутся по скрипту, но их опять же так просто и завалят.
Ты ни как не сможешь определить какой конкретно ассинхроyный запрос валит ноду, без asynk hooks никак.
| |
|
6.67, Весельчак У (?), 21:41, 24/10/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
В тредпуле обрабатывается только чтение сокетов. Парсер http , как и js работает в майн потоке. Если обработчик написан криво, то любой первый запрос свалит ноду, неважно сколько в очереди стоит запросов на обработку.
| |
|
|
|
|
|
5.26, Anonimous (?), 12:04, 24/10/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Я сокращенную версию посмотрел, 50 минутную нет.
UnhandledException возникает, когда выкидываешь эксепшен внутри промисов. Везде и всегда написано, что этого делать нельзя. Если что-то может выкинуть исключение – оборачивай в try/catch и catch вызывай reject. асинки этих проблем лишены. Там все, если упрощенно, кодогенерацией обернется в try/catch и в случае исключения вызовется reject.
Чистые промисы лучше использовать по минимуму и с осторожностью.
По поводу же распутывания того, по какой причине был запущен тот или иной ассинхронный метод, является общей проблемой, а не чисто нодовской.
Обычно, это решается заведением некого "контекста" или маркера, который генерируется в самом начале, при получении запроса и сопровождает все цепочки ассинхронных вызовов. Например, можно его отображать во всех логах и потом, просто погрепав логи по этому маркеру, найти все асинхронные вызовы, которые были совершены.
Но это для оффлайновых разбирательств, почему у кого-то там что-то падает. При нормальном написании кода, у пользователя не должно быть пятиминутных таймаутов из-за того, что что-то там отвалилось.
| |
|
6.27, Аноним (6), 12:06, 24/10/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Твою поток мыслей не читал, ничего умного ты написать не мог. Вот тебе коммент из под видео которое 50 минут - Раньше смотрел его и не понимал, думал - чудик какой-то, но сегодня столкнулся. Когда в ноде один процесс и много клиентов unhandledError НИКАК не может определить с какого клиента пришла ошибка. Благо сейчас проект где можно разделить на процессы для каждого клиента, но в будущем это конечно серьезный повод задуматься.
| |
|
7.30, имя_ (?), 12:18, 24/10/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
>Твою поток мыслей не читал, ничего умного ты написать не мог
не читал, но осуждаю!
| |
|
|
9.46, имя_ (?), 13:45, 24/10/2019 [^] [^^] [^^^] [ответить] | –1 +/– | Именно Прочитал первое предложение, а дальше понял, что и ты ничего умного напи... текст свёрнут, показать | |
|
|
|
6.48, НяшМяш (ok), 14:26, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
> UnhandledException возникает, когда выкидываешь эксепшен внутри промисов.
Что? Если кинуть ексепшн внутри промиса, то во-первых, выпадет UnhandledRejection, а во-вторых, это случится только если ты не обработал ошибку внутри catch (или с помощью try-catch при использовании async-await). Внутри new Promise, или в then ты можешь свободно сделать throw Error и ничего тебе не будет, пока ты эту ошибку обрабатываешь далее. UnhandledException это более общий ивент, который может возникнуть если кинуть ошибку и не обработать её в любом месте - например, при обработке данных внутри своего класса стрима.
| |
|
|
|
|
|
|
2.36, Аноним (36), 13:20, 24/10/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Иногда при сборке дополнений на C/C++ зачем то использует инфраструктуру Python для компиляции. Видимо не хотят свою собсвтенную использовать, а вообще выглдит действительно странно.
| |
|
|
4.53, имя_ (?), 15:47, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
костылеподелия (по сравнению с современными полноценными скриптовыми языками, конечно)
| |
|
3.75, Аноним (75), 01:03, 25/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
> не хотят свою собсвтенную использовать
Еще одну систему сборки? Нет, спасибо.
gyp остался по историческим причинам, потому что google через него собирал v8.
| |
|
|
1.16, Аноним (-), 11:24, 24/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Для Си тоже написаны сетевые либы, которые могут все то же, только, на минуточку, в десятки раз быстрее и в десятки раз меньше потребляют памяти, полностью протестированы, стабильны, и не от Васяна. Мышки, одумайтесь, зачем вам жрать кактус?
| |
|
2.17, Anonimous (?), 11:27, 24/10/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
И много ты завершенных серверных приложений на чистых сях за свою жизнь написал?
| |
|
|
4.37, Аноним (36), 13:24, 24/10/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вообще парень прав, но вот кто сегодня готов за такое платить?
ИСпользуют такие языки не потому что любят, а потому что студент пишущий на JavaScript это дешево и удобно, а программист на Си со знанием всех деталей стоит как половина машины в цесяц.
А теперь потеме, я сожрал не менее трех кактусов и написал не меенее двух сетевых приложений на C++ и горд этим. Впечатление от JS кстати хорошее, но чего точно не зватает так это перформанс бенчмарков и прочих рюшечек в самом libuv что бы можно было сказать что все действительно честно работало, а то столкнулся с тем что простой парсинг HTTP в старых версиях сравнительно задерживал весь EventLoop.
| |
|
5.44, Аноним (9), 13:40, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Если кто то и пишет бек на С++ то это кто-то типа Яндекса. Где получается что от экономии на ресурсах можно вместо двух датацентров использовать один.
| |
|
6.51, Аноним (1), 14:57, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Вообще-то Яндекс активно использует Node.js в некоторых проектах.
| |
|
7.54, Аноним (55), 15:51, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Вообще-то их поисковый движек был на C++ когда слова бекенд еще не было в тренде.
| |
|
|
5.45, Аноним (45), 13:41, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
> простой парсинг HTTP в старых версиях сравнительно задерживал весь EventLoop.
Вообще, есть такая штука, как threads pool
| |
|
6.49, НяшМяш (ok), 14:28, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
UV_THREADPOOL_SIZE=128 решает все проблемы с внутренним кодом самой ноды.
| |
|
5.62, Анон Анонов (?), 19:17, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Старый http парсер довольно костыльный и неоптимальный. Скажем спасибо Феде, что переписал это говно.
| |
|
|
|
2.25, Аноним (15), 11:54, 24/10/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ага. А когда ты бэк пишешь на си, как это называется? Поедание кактуса обмазанного калом? Пофиг, что в коде на чистом си повсюду сплош и рядом будут анальные бэкдоры и течи, что код станет с трудом поддерживаемым, что простой скрипт будет занимать несколько рабочих дней (и это при методике "ху.., ..як и в продакшн, а с тестами, ревью и аппрувами можно вообще закрывать кантору"), но зато будет быстро (и то не факт). Люди просто так абстракции придумывают (кстати, этот ваш си - это абстракция ассемблера), так что давайте писать на бинарном коде. (Тсссс, говорят, что в ноде можно писать на С/C++).
| |
|
3.28, Аноним (3), 12:08, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Для этого есть всякие kore.io. В принципе, любой серьёзный продакшен, критичный до производительности, использует плюсы на бэке, а там и до сишечки не далеко. Есть ещё лайтовый вариант нанять жабакодеров налабать по-быстрому, а проблемы решать костылями по мере поступления. В вашем представлении серьёзный продекшен это видимо тысячи серверов с питоном и пхп, но это не так, у них тысячи серверов только потому что это более экономически целесообразно, чем перезапустить проект и потерять всё в процессе (да и не стоит таких требований, пусть даже это позводит выкинуть половину серверов).
| |
|
4.77, Аноним (77), 08:27, 25/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
В настоящее время для серьезного продакшена с производительностью тренд начинает понемногу поворачивается в сторону всяких растов и го. Просто на плюсах слишком дофига плюшек написано, много унаследованного софта. Инерция.
| |
|
3.29, InuYasha (?), 12:12, 24/10/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Вам пожарных, может, вызвать или сапёров? Не могу разобраться - у вас бомбит или подгорает.
| |
3.32, Нанобот (ok), 12:25, 24/10/2019 [^] [^^] [^^^] [ответить]
| +6 +/– |
> Поедание кактуса обмазанного калом
Старый добрый опеннет и его эксперты...
| |
3.38, Аноним (36), 13:26, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
> говорят, что в ноде можно писать на С
Можно. Пишу. Кстати хорошо бы разобраться с libeio для переиспользования их потоков, а то пока своими пользуюсь.
| |
3.68, qwerty123 (??), 22:55, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
> А когда ты бэк пишешь на си, как это называется?
разработка это называется.
1 на С писать дольше. в среднем раза в два.
2 пользуют библиотеки, иногда свои (у меня всякие очереди-сеты-вектора юзаются с вариациями лет 10-15)
3 в общем работает быстрее раза в два-пять быстрее чем на ноде
при очень компактном бинарном коде.
лучше писать в псевдо-объектном стиле - структура, всегда конструктор-аллокатор, методы, всегда деструктор.
для нано-микросервисов самое то.
особенно для всяких брокеров к оборудованию, для которых писать прослойку к интерпретатору еще дольше.
и/или там где асинхронное поведение нежелательно.
но одно второго не отменяет.
| |
|
|
3.70, qwerty123 (??), 23:04, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
>Ага вон такие же одноклеточные иксперты реализовали хайлоад
сдуру можно все сломать.
но вообще-то как микросервис аля реактор модель и пачкой нитей, все в районе libc & pthread, в три страницы кода, чудесным образом разруливает 10K на ARM.
потеет, машет вентилятором, но разруливает.
привести пример не просите, не дам.
| |
|
4.80, Аноним (79), 12:09, 25/10/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Хипстеры пока еще не дотянулись до ARM'ов поэтому вполне вероятно там все гораздо лучше.
| |
|
|
|
|
2.60, Аноним (59), 16:50, 24/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Просто никому не интересно это стало, так как пришла мода писать на тайпскрипте, а там оно уже есть.
| |
2.63, Анон Анонов (?), 19:26, 24/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Прежде чем писать "неосилили", сначала все детали почитайте. У ноды огромная экосистема модулей. Было довольно сложно подружить commonjs модули и ES модули. Но решение, кстати, есть. И в 13 и 14 ноде ES модули модули, возможно стабилизируются.
| |
|
|
2.87, rex (??), 23:41, 28/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
можно и с нодой покапаться и с еще чем-то, хуже то от этого не должно стать.
тут вопрос, что в результате спрограммировать хочется.
| |
|
|