Nick Murzin: Вопрос с подвохом да? :) Естественно в качестве бекенда для SPA приложений. Бонусом такого решения идёт изоморфный код, который может составлять изрядную долю за счёт тех же MVC-моделей.
1) "Проблема" которую вы описали касается любого FastCGI решения. отлавливайте ошибки и не будет ничего падать. Ну и если уж упало, то не проблема - поднимет супервайзер. Но на практике у меня на производстве под нагрузкой процессу по полгода живут. И если бы не вырубали иногда на продолжительное время свет - жили бы ещё дольше.
В общем не пишите глупостей, пишите нормальный код.
Alastor: Вам надо вдумчиво изучить основы асинхронного подхода. Если вы ведёте разговор об асинхронных вызовах и при этом приводите пример кода с функцией возвращающей результат посредством return - вы в корне не понимаете то с чем пытаетесь работать.
В отличие от setTimeout, setInterval может как раз быть источником проблем, т.к. запустит код вне зависимости от того отработал ли предыдущий вызов или нет.
Itvanya: на счёт масштабируемости спорно, это вопрос архитектуры приложения а не языка. Второе и третье как раз только в плюс топик стартеру - вы сами сообщаете что NodeJS разработчик более высокооплачиваемый. Ну а четвёртое не аргумент ни в плюс ни в минус. Просто у вас так исторически сложилось что ваша команда пишет на Pithon. Вот и всё.
Itvanya: По какой причине отказались? У меня не мало примеров когда на ноду как раз уходили с пайтона. Но особенно бегут с PHP и рельс. По поводу частичности, оно понятно что нет крупных проектов с гомогенной языковой средой.
Расскажите это PayPal, Walmart... От куда берутся эти заключения про игрушечность ноды, про "только чатики писать"? Вы это сами придумываете или советские газеты по утрам читаете? У меня автоматизация целого завода оконных изделий с кучей цехов и участков в них на ноде автоматизировано. Если вы не используете эту молодую технологию, то так и напишите, не использовал но сомневаюсь. Но бредятину пожалуйста не надо придумывать.
