>Просто вбей в гугл "python vs node.js performance" и сам убедишься.
Да смотреля эти тесты, если ты погуглишль тесты по Java, то будешь уверен что она быстрее плюсов или по крайней мере почти такая же быстрая как плюсы. Но практика показывает, что это не так, а с потреблением оперативки дак вообще ад.
Специально подобранными тестами можно доказать все, что угодно.
В тестах сраниваются всякие hello world, это мягко говоря далеко от реальности.
Я пишу проекты на том и другом. У нас каждый проект проходит нагрузочое тестировние, так что я себе прекрасно представляют производительность этих языков.
>Одна инструкция yield не делает язык асинхронным. Async и await в C# - это, считай, синтаксический сахар для событий.
Не yield, а yield from. Это разные вещи.
yield это вообще не про асинхронность, но в торнаде придумали как эту штуки использовать для написания асинхронного кода, получилось гораздо удобнее промисов.
Ты еще скажи что функции это синтаксический сахар для джампов и пушей/повов аргументов в/из стека.
Дак любые языки это синтаксический сахар над машинными кодами. Меня всегда убивает аргумент, что это сахар, а значит не нужно.
>И что за библиотеки к экспрессу ты писал?
Например csrf, в npm есть подобные модули, но они кривые.
> ведь умные дядьки почему-то отдают предпочтение именно ноде, причем с каждым днем таких дядек все больше.
Ну во-первых я бы не стал преувеличивтаь популярность ноды. Популярна она лишь для сборки верстки. А во-второых популярность это не признак качества. Самый популярный язык для веб-приложений до сих пор PHP, в том числе и для серьзеных больших проектов.
>Производительность у ноды хороша.
Производительность достатачная для решения ряда задачь и все. Но утверждать что JS имеет производительность превосходящую python и тем более сравнимую с плюсами это не серьезно.
> И я не понимаю, почему ты упорно пытаешься выставлять ноду как плохую реализацию асинхронного подхода,
В JS нет языковых констркукий позволяющих писать понятный простой аиснхронный код. Поэтому странно утверждать что JS хорош для написания асинхронного кода. Вовсе нет. Везде получается лапша из колбэков, асинков и промисов. Да если из трех мест забрать дынные, склеить и отдать на клиент, то тут еще не совсем лапша, т.к. просто мало кода и логики. Но это и не полноценный бакенд, а промежуточное звено или бакенд для простой задачи. С самими промисами до ES6 вообще бардак, т.к. везде используются разные.
Прочитай про yield from и asyncio в питоне3 или документацию по Торнаде, или или async/await в C#? тогда возможно поймейшь о чем я говорю. В Go кажется тоже были какие-то хорошие штуки для асинхронщины, но сам Go менее удобен, т.к. более низкоуровневый чем JS. Но вот производительность у Go хорошоая, в отличе от JS.
> JS всегда был и будет языком, на котором все делается асинхронно и делается, как показывает практика, неплохо.
Никто не пишет языки компилируемые в python или ruby, потому что эти языки достаточно удобные, а с JS никто не хочет иметь дело, я лично понимаю почему. Поэтому появились CoffeeScript, .и еще 100500 разных -script, которые компилятся в JS. Это явный показатель, что язык как миниму довольно беден. ES6 это хорошо, но пересядут ли люди с CoffeScript на JS, думаю это будет показателем.
>Хотя, например, для фронтенд разработки на текущий момент инфраструктура ноды, пожалуй, самая богатая.
Ну да, на ноде есть такие штуки как grunt/gulp, но это инструменты для сбора верстки, это не имеет отношения к серверному программированию.
Тимофей: Моя мысль не в том что асинхронность это плохой инструмент, а в том что для решения аcинхронных задач, которые как-то решает нода, есть более подходящие инструменты. А для решения синхронных задач, тем более есть более подходящие инструменты. Я вижу одни только недостатки потому, что сравниваю с инфраструктурой Python, на мой взгляд он гораздо больше подходил для решения задач, которые пытается решать нода. Производительность для CPU bound задач у python лучше , т.к. куча библиотек для питона написана на сях. Производительность для IO bound задачь, такая же как в ноде. Поддержка асинхронности в python3 есть на уровне языка, а в python2, есть очень хорошие решние например в Торнаде, которое позоляет спрямлять лапшку колбэков, опять же за счет констуркции языка yield (хотя она изначально не связана с асинхронностью). Выбор готовых библиотек и фреймворков опять же в python гораздо больше. Если бы я сранивал node.js с Java, то наверное увидел бы у ноды какие-то плюсы, т.к. на JS писать все-таки проще чем на Java, хотя производительность тут опять же проигрывает. Но мой опыт это Python и я сравниваю все с ним, а перед питоном у ноды я никаких преимуществ не вижу. К популярному express.js, я уже написал пару библиотек для себя, потому, что нормальных готовых решений нет, хотя в любых полноценных фрейморках такие простые штуки есть из коробки.
Дмитрий Авилов: Асинхронное программирование идеально для специфических задач веб-разработки, типа написания чатиков, но для 95% задача, больше подходит синхронное. Для написания интернет магазина, никакая асинхронщина не нужна, более того она будет мешать. JS не быстрый, не знаю откуда вы это взяли. Он достаточно медленный, производительность сравнима с другими интерпритируемыми языками.
elser: Гигабайтные файлы это не редкость, это выгрузка для Яндекс.Маркета например у крупных магазинов файлы замниают несколько гигов, даже по одной категории товаров. Не знаю откуда у вас такое впечатление, я говорю о тех вещах с чем сталкиваюсь. У меня куча проектов у которых требования к производительности 1000 rps с 4-8 процессоров. Только это не заслуга ноды, нода с этим не справляется. Приходится все кешировать. А закешированные результаты можно хоть на PHP отдавать с такой производительностью. Шаблонизация выполняется медленно, xml парсинг выполняется медленно, все что требует участия процессора выполняется медленно. От вас интересно услышать откуда у вас такие фантастические данные о производительности js?
Тимофей: микрофреймоврки это отдельная тема для холиваров, в том же питоне их полно flask, wergzeug, bottle.py, falcon и еще 100500. У них есть сторонники, с похожими на ваши аргументами. Лично я не сторонник микрофреймворков, можно и совсем тогда без фреймворков писать, будет еще "гибче" и "быстрее" а велоспипедов еще больше. Это похже на аргументы людей которые не используют стандартные библиотеки, а пишут свои функции. Написать микрофреймоврк времени много не надо, поэтому в питоне их такое огромное количество. А вот отсутствие полноценных фреймворков говорит о незрелости платформы node.js, хотя конечно лет через 5 я думаю они появятся. Ну и с npm есть свои приколы, когда зависимости подгуржаются внутрь зависимостей. В теории тут есть поределенные плюсы, но на практике получается какая-то раздутая жесть с зависимостями, вплоть до того как у нас на диске постоянно заканчиваются иноды.
elser: Про скорость работы это даже не смешно. Посмотрите скорость xml-парсеров написанных на чистом js, не сишные модули для ноды, а парсры написанные на js, сравните скорость работы, попробуйте распарсить файлик в 5ГБ. Скорость JS несмотря на любые заявления сраванима с другими интерпритируемыми языками, это минимум в 10-30 раз медленней чем плюсы, ну и до явы тоже очень далеко. Может быть он компилируется в байткод быстрее, но нас же не это интересует, а скорость исполнения.
>Никаких костылей в языке нет
Я конечно понимаю, что задокументированный баг является фичей, но язык магко говроря плохо продуманный. Не даром большинство старается не писать на голом js, а используют какой-нибудь coffee script. Компилировать интерпритируемый язык, это тоже сомнительная фича.
То что есть хорошие библиотеки на все случи жизни, это мягко говоря преувеличение. Зачастую после поисков приходится писать самому, т.к. подходящих нет.
Sails, ну я смотрел не него, сам не пробовал. Общался с парнями которые писали на нем проект, они долго плевались, матерились, сказали что он очень-очень сырой и лучше бы они писали на express. Про метеор сказать не могу, но во всяком случае это не аналог Django или Rails, кажется это спецефическая штука для определенных задач. Если у тебя другой опыт, расскажи.
express - это микрофреймворк, микрофреймоврк это как чемодан в котором одна отвертка, иногда этого достаточно, но в целом никаких возможностей он не предоставляет и приходится постоянно писать велосипеды.
> "всякие async и promise" разрешают ситуацию достаточно изящно, чтобы асинхронный код хорошо писался и читался.
это только в простых ситуациях, а если в появляется какая-то логика, то уже не спасают
> Но, во-первых, это цена, которую вы платите за возможность поделать что-то полезное, пока выполняется запрос к БД,
Во первых для многих проектов смысла писать асинхронно нет вообще. Синхронный код проще и надежней. А во-вторых нода не единстыенный способ писать асинхронный код. Есть языки в которых есть поддержка асинхронности на уровне языка, или какие-то языковые конструкции не предназначенные напрямую для асинхронности, но упрощающие написание такого кода. Там асинхронный код читать и писать проще, например Python.
Как в выше в комментах писали, на ноде редко пишут проект полностью, как правило это просто прослойка между бакендом и версткой. Во многих случаях ненужная. Я лично знаю такие весьма странные примеры когда в компании повялется любовь к ноде. Если реньше простой проект делелся силой двух разработчиков - бакенд и фронтэнд, то теперь нужно привлекать третьего человка который делает прослойку на node.js. Т.е. аналогичные проекты теперь делаются в полтора раза дороже. Весьма странный подход, но выбор языка это видимо вопрос моды/веры (нужное подчеркнуть), а не взвешенного подхода.
Вобщем xmlpipe2 нормально работает со стороны сфинкса, но тут сильно зависит от того на чем вы бутете релизовывать и какое количество документов вам надо индексировать. У меня ежедневно индексируются 6 миллионов книг, правда, в индекс отправляется только частить информации (название, автор). Реализовано на С++, работает за пару минут.
ну либо самому писать логику индексации и формировать запросы для поиск в монструозном json, реализовывать кастомную команду для реиндексации о обабатывать сигналы типа post_save, писать мапинги для всех моделей и т.п., либо просто подключил библиотеку и указал какие поля индексировать.
