The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск серверной JavaScript-платформы Node.js 13.0

24.10.2019 09:45

Доступен релиз Node.js 13.0, платформы для выполнения сетевых приложений на языке JavaScript. Одновременно завершена стабилизация прошлой ветки Node.js 12.x, которая переведена в категорию выпусков с длительным сроком поддержки, обновления для которых выпускаются в течение 4 лет. Поддержка прошлой LTS-ветки Node.js 10.0 продлится до апреля 2021 года, а позапрошлой LTS-ветки 8.0 до января 2020 года.

Основные улучшения:

  • Движок V8 обновлён до версии 7.8, в которой задействованы новые методы оптимизации производительности, улучшена деструктуризация объектов, уменьшено потребление памяти и сокращено время подготовки к выполнению WebAssembly;
  • По умолчанию включена полная поддержка интернационализации и Unicode на базе библиотек ICU (International Components for Unicode), позволяющая разработчикам писать код, поддерживающий работу с разными языками и локалями. Модуль full-icu теперь установлен по умолчанию;
  • Стабилизирован API Workers Threads, позволяющий создавать многопоточные циклы обработки событий (event loop). Реализация основана на модуле worker_threads, позволяющем запускать JavaScript-код в несколько параллельных потоков. Стабильная поддержка API Workers Threads также бэкепортирована в LTS-ветку Node.js 12.x;
  • Повышены требования к платформам. Для сборки теперь требуется как минимум macOS 10.11 (требуется Xcode 10), AIX 7.2, Ubuntu 16.04, Debian 9, EL 7, Alpine 3.8, Windows 7/2008;
  • Улучшена поддержка Python 3. При наличии в системе Python 2 и Python 3, по-прежнему используется Python 2, но добавлена возможность сборки при наличии в системе только Python 3;
  • Удалена старая реализация HTTP-парсера ("--http-parser=legacy"). Удалены или переведены в разряд устаревших вызовы и свойства FSWatcher.prototype.start(), ChildProcess._channel, метод open() в объектах ReadStream и WriteStream, request.connection, response.connection, module.createRequireFromPath();
  • Следом вышло обновление 13.0.1, в котором по горячим следам устранено несколько ошибок. В том числе решена проблема с выводом в npm 6.12.0 предупреждения об использовании неподдерживаемой версии.

Напомним, что платформа Node.js может быть использована как для серверного сопровождения работы Web-приложений, так и для создания обычных клиентских и серверных сетевых программ. Для расширения функциональности приложений для Node.js подготовлена большая коллекция модулей, в которой можно найти модули с реализацией серверов и клиентов HTTP, SMTP, XMPP, DNS, FTP, IMAP, POP3, модули для интеграции с различными web-фреймворками, обработчики WebSocket и Ajax, коннекторы к СУБД (MySQL, PostgreSQL, SQLite, MongoDB), шаблонизаторы, CSS-движки, реализации криптоалгоритмов и систем авторизации (OAuth), XML-парсеры.

Для обеспечения обработки большого числа параллельных запросов Node.js задействует асинхронную модель запуска кода, основанную на обработке событий в неблокирующем режиме и определении callback-обработчиков. В качестве способов мультиплексирования соединений поддерживаются такие методы, как epoll, kqueue, /dev/poll и select. Для мультиплексирования соединений используется библиотека libuv, которая является надстройкой над libev в системах Unix и над IOCP в Windows. Для создания пула потоков (thread pool) задействована библиотека libeio, для выполнения DNS-запросов в неблокирующем режиме интегрирован c-ares. Все системные вызовы, вызывающие блокирование, выполняются внутри пула потоков и затем, как и обработчики сигналов, передают результат своей работы обратно через неименованный канал (pipe). Выполнение JavaScript-кода обеспечивается через задействование разработанного компанией Google движка V8 (дополнительно Microsoft развивает вариант Node.js с движком Chakra-Core).

По своей сути Node.js похож на фреймворки Perl AnyEvent, Ruby Event Machine, Python Twisted и реализацию событий в Tcl, но цикл обработки событий (event loop) в Node.js скрыт от разработчика и напоминает обработку событий в web-приложении, работающем в браузере. При написании приложений для node.js необходимо учитывать специфику событийно-ориентированного программирования, например, вместо выполнения "var result = db.query("select..");" с ожиданием завершения работы и последующей обработкой результатов, в Node.js использует принцип асинхронного выполнения, т.е. код трансформируется в "db.query("select..", function (result) {обработка результата});", при котором управление мгновенно перейдёт к дальнейшему коду, а результат запроса будет обработан по мере поступления данных. .

  1. Главная ссылка к новости (https://medium.com/@nodejs/nod...)
  2. OpenNews: Выпуск серверной JavaScript-платформы Node.js 12.0
  3. OpenNews: Бэкдор в зависимости к event-stream, популярной библиотеке для Node.js
  4. OpenNews: Выпуск сервера приложений NGINX Unit 1.5 с поддержкой Node.js
  5. OpenNews: Выпуск серверной JavaScript-платформы Node.js 11.0
  6. OpenNews: Выпуск серверной JavaScript-платформы Node.js 10 и пакетного менеджера NPM 6
Лицензия: CC-BY
Тип: Программы
Ключевые слова: node.js, javascript
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (84) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:55, 24/10/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    > Ни одна функция в Node.js не должна напрямую выполнять операции ввода/вывода - для получения данных с диска, от другого процесса или из сети требуется установка callback-обработчика.

    Не актуально, вместо callback можно использовать асинхронные генераторы (async/await) почти во всех встроенных API.

     
     
  • 2.9, Аноним (9), 11:09, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Фанаты скобочек негодуют.
     
     
  • 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, и оно подобно языку в языке -- на местах соединения синхронного кода с асинхронным больно
     
     
  • 6.74, Аноним (74), 00:08, 25/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Скомпилируй babel-ом и увидишь, как примерно это работает.
     
  • 4.34, Аноним (9), 13:01, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нет уж промисы это больший уровень абстракции.
     

  • 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 +/
    Ой щас тру стори начнутся типа: Да у меня нода всю память сожрала просто так, весь процессор оккупировала, чёрную дыру в полу открыла. Да и вабще, ваш виндас говно
     
  • 6.35, Аноним (9), 13:03, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не буду показывать пальцем, но как-нибудь попробуй заюзать библиотеку jsdom https://www.npmjs.com/package/jsdom и ты узнаешь что можно съесть и больше.
     
     
  • 7.59, Аноним (59), 16:30, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если ты ее юзал для парсинга сайтов в цикле, то там очень просто сделать утечку памяти, так как jsdom сам не убивает таймеры и они мешают gc уничтожить window. Когда контекст тебе уже не нужен надо вызывать явно window.close()
     
     
  • 8.79, Аноним (79), 12:07, 25/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Звучит правдоподобно ... текст свёрнут, показать
     
  • 4.23, Аноним (23), 11:49, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что петон уже есть у пользователей искаропки во всех дистрибутивах, и зачем тащить ноду для маленького скриптика действительно непонятно.
     
     
  • 5.31, Anonimous (?), 12:20, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У питона, по сравненю с нодой, в плане удобства разработки никаких преимуществ нету. Если человек знает хорошо ноду и фигово знает питон, то уж лучше он добавит в зависимости ноду, чем напишет кривой говнокод на питоне. Зато сэкономит 20Мб на диске.
     
     
  • 6.65, исчо_адын_гентунегуже_в_прошлом (?), 20:01, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    зависимость - это типа
    nmp install my_super_rootkit_from_chinese_hacker?
     
     
  • 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
     
     
  • 8.81, исчо_адын_гентунегуже_в_прошлом (?), 16:17, 25/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    я хз, у мну apt-get yum install и salt state apply ПыСы - а че, подписи п... текст свёрнут, показать
     
  • 8.86, Аноним (86), 21:10, 28/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    conan install my_super_rootkit_from_chinese_hacker ... текст свёрнут, показать
     
  • 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 петона, когда нода втрое меньше.

     
     
  • 6.78, whiplash (?), 08:56, 25/10/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    и втрое быстрее, кстати
     
     
  • 7.85, Брат Анон (?), 13:16, 28/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И всё-равно также дико тормозит и глючит.
     
  • 5.82, Аноним (82), 19:35, 26/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Есть quickjs, гораздо меньше.
     

  • 1.6, Аноним (6), 10:42, 24/10/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пока не сделают async_hooks stable пользоваться нельзя
     
     
  • 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 работает в майн потоке. Если обработчик написан криво, то любой первый запрос свалит ноду, неважно сколько в очереди стоит запросов на обработку.
     
     
  • 7.73, Инкогнито (?), 23:36, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы там у себя в "Единая Россия" все такие?
     
  • 3.19, Аноним (6), 11:38, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот в этом докладе вроде про это говориться https://www.youtube.com/watch?v=STyocIjskBE
     
     
  • 4.22, Аноним (6), 11:48, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Update https://www.youtube.com/watch?v=Lrs6puJ4G2Q
     
     
  • 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 +/
    >Твою поток мыслей не читал, ничего умного ты написать не мог

    не читал, но осуждаю!

     
     
  • 8.43, Аноним (9), 13:38, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Почитал и осуждаешь ... текст свёрнут, показать
     
     
  • 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 это более общий ивент, который может возникнуть если кинуть ошибку и не обработать её в любом месте - например, при обработке данных внутри своего класса стрима.

     
     
  • 7.55, Аноним (55), 15:54, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не читал, но думаю что ты его осуждаешь.
     

  • 1.10, Аноним (10), 11:11, 24/10/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А питон то ей зачем нужен?
     
     
  • 2.12, Anonimous (?), 11:13, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Для сборки на этапе компиляции.
     
  • 2.36, Аноним (36), 13:20, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Иногда при сборке дополнений на C/C++ зачем то использует инфраструктуру Python для компиляции. Видимо не хотят свою собсвтенную использовать, а вообще выглдит действительно странно.
     
     
  • 3.42, Аноним (9), 13:36, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Неосиляторы баша, батчскрипта.
     
     
  • 4.53, имя_ (?), 15:47, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    костылеподелия (по сравнению с современными полноценными скриптовыми языками, конечно)
     
  • 3.75, Аноним (75), 01:03, 25/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > не хотят свою собсвтенную использовать

    Еще одну систему сборки? Нет, спасибо.

    gyp остался по историческим причинам, потому что google через него собирал v8.

     
  • 2.47, Анонимос (?), 14:15, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для gyp
     

  • 1.16, Аноним (-), 11:24, 24/10/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Для Си тоже написаны сетевые либы, которые могут все то же, только, на минуточку, в десятки раз быстрее и в десятки раз меньше потребляют памяти, полностью протестированы, стабильны, и не от  Васяна. Мышки, одумайтесь, зачем вам жрать кактус?  
     
     
  • 2.17, Anonimous (?), 11:27, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    И много ты завершенных серверных приложений на чистых сях за свою жизнь написал?
     
     
  • 3.24, Аноним (-), 11:51, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А ты, много ли ты кактусов сожрал? Много, да? Гордись собой!
     
     
  • 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++ когда слова бекенд еще не было в тренде.
     
     
  • 8.58, Аноним (15), 16:01, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще-то был ... текст свёрнут, показать
     
  • 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 парсер довольно костыльный и неоптимальный. Скажем спасибо Феде, что переписал это говно.
     
     
  • 6.84, Аноним (84), 20:19, 26/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Жаль, Федя все меньше уделяет время разработке самой Ноды.
     
  • 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 +/
    > Поедание кактуса обмазанного калом

    Старый добрый опеннет и его эксперты...

     
     
  • 4.56, Аноним (15), 15:57, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    *Греф ставит лайк вашему комментарию*
     
  • 3.38, Аноним (36), 13:26, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > говорят, что в ноде можно писать на С

    Можно. Пишу. Кстати хорошо бы разобраться с libeio для переиспользования их потоков, а то пока своими пользуюсь.

     
  • 3.68, qwerty123 (??), 22:55, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А когда ты бэк пишешь на си, как это называется?

    разработка это называется.

    1 на С писать дольше. в среднем раза в два.
    2 пользуют библиотеки, иногда свои (у меня всякие очереди-сеты-вектора юзаются с вариациями лет 10-15)
    3 в общем работает быстрее раза в два-пять быстрее чем на ноде
    при очень компактном бинарном коде.

    лучше писать в псевдо-объектном стиле - структура, всегда конструктор-аллокатор, методы, всегда деструктор.

    для нано-микросервисов самое то.
    особенно для всяких брокеров к оборудованию, для которых писать прослойку к интерпретатору еще дольше.
    и/или там где асинхронное поведение нежелательно.

    но одно второго не отменяет.

     
  • 2.40, Аноним (9), 13:34, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ага вон такие же одноклеточные иксперты реализовали хайлоад на С++ с событийным движком с очередью с приоритетом на простом связном списке. И у них странным образом все тормозит.

    https://www.opennet.ru/openforum/vsluhforumID3/118724.html#11

     
     
  • 3.70, qwerty123 (??), 23:04, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Ага вон такие же одноклеточные иксперты реализовали хайлоад

    сдуру можно все сломать.

    но вообще-то как микросервис аля реактор модель и пачкой нитей, все в районе libc & pthread, в три страницы кода, чудесным образом разруливает 10K на ARM.
    потеет, машет вентилятором, но разруливает.

    привести пример не просите, не дам.

     
     
  • 4.80, Аноним (79), 12:09, 25/10/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хипстеры пока еще не дотянулись до ARM'ов поэтому вполне вероятно там все гораздо лучше.
     
  • 2.50, НяшМяш (ok), 14:35, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json&l=zii
    (не смотреть на es4x - это кастомная борода на JVM, которая умеет в том числе и JS)

    От 2 до 5 раз - это у тебя в десятки? Почему сразу не на пару порядков?

     

  • 1.57, Аноним (57), 16:00, 24/10/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Опять не осилили. Отодвинули светлое будущее еще на год вперёд

    ECMAScript Modules#
    Stability: 1 - Experimental

    Хотя обещали https://2ality.com/2019/04/nodejs-esm-impl.html#using-es-modules-on-node.js

     
     
  • 2.60, Аноним (59), 16:50, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Просто никому не интересно это стало, так как пришла мода писать на тайпскрипте, а там оно уже есть.
     
     
  • 3.69, Аноним (69), 23:00, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тьюринг-полноту из системы типов тайпскрипта уже убрали?
     
  • 2.63, Анон Анонов (?), 19:26, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Прежде чем писать "неосилили", сначала все детали почитайте. У ноды огромная экосистема модулей. Было довольно сложно подружить commonjs модули и ES модули. Но решение, кстати, есть. И в 13 и 14 ноде ES модули модули, возможно стабилизируются.
     
     
  • 3.66, Аноним (66), 21:26, 24/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Хватит это терпеть
     

  • 1.72, vitalif (ok), 23:27, 24/10/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не совсем в тему, но меня тут порадовало:

    https://github.com/axboe/liburing/blob/master/examples/ucontext-cp.c

    async/await с io_uring на C! :)

     
  • 1.83, Аноним (82), 19:37, 26/10/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Стоит учить сабж полному нубу в программировании?
     
     
  • 2.87, rex (??), 23:41, 28/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    можно и с нодой покапаться и с еще чем-то, хуже то от этого не должно стать.
    тут вопрос, что в результате спрограммировать хочется.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру