Последней месяц мучает вопрос на чем лучше написать сервис: Ruby, Python или NodeJS. Суть сервиса в выдаче динамики (стандартный http сервер), а в свободное время (ночью) анализ полученной статистики и данных. Проще говоря, когда никого нет, демон начинает в фоновом режиме ворочать данные, а как только появилась активность, он замедлил ход и отдал пару ядер обратно. И из этого следует вопрос: какой язык позволит это сделать? (я понимаю, что все они. Какой более предпочтителен.).
Язык выбираю не на один проект и хотелось бы выбрать такое, который позволил бы писать не только блоги и лендинги (но и их тоже), но и серьезные сервисы, с большим объемом данных.
На данный момент оперирую:
JS - 2 года
PHP - 2 года
PERL - 0,5 года.
C++ - 1 год
Нодой балуюсь уже вторую неделю, все круто (После PHP так вообще сказка), но есть ощущение, что чего-то недодают.
P.S. в силу возраста и малого опыта работы могу тупить в понимании распределенности системы.
1) Ruby, Python - языки, нода - фреймворк.
2) Обычно я говорю, что ты можешь реалировать это всё хоть на brainfuck, но ты это знаешь. В этом случае выбирают то, что лучше знают (в твоём случае - JS) или то, что хотят знать
3) Ты можешь даже написать приложение на руби, админку на питоне, обработчик данных на js, если хочешь извращений. Но для обработки данных я бы пользовался питоном. Ну и, для простоты, приложение писал на нём.
sim3x: вопрос в следующем: что лучше всего справится с несложными расчетами входных данных (статистика действий от клиента) и что позволит написать на себе как веб сервис, так и демона который будет собственно анализировать данные. Сейчас на ноде я точно вижу как это сделать, но есть ощущение, что она может со временем перестать справляться с данными (и кластеры ей тут не помогут).
Python - привлекает своей консервативностью, которая бьет по рукам линейкой за лишний отступ.
Node.JS - скорее сейчас тащит на Вау эффекте, но и на своей простоте.
Ruby - честно сказать, только из-за рельс.
Я понимаю, что все эти языки справятся с моей задачей. Вопрос какой справится более качественно, без дополнительной боли с масштабируемостью.
Roman Kitaev: в рамках этого проекта, думаю, достаточно монги. За архитектуру ручаться не могу, так как это уже не объективно.
Сейчас пугает следующая ситуация: каждый кулик свое болото хвалит. А хотелось бы по существу видеть все дыры и косяки каждого из языков. Потому, как кого не спроси, их технология просто безупречна.
Лично я вижу следующие:
Node.JS - молод, и местами сам не понимает куда идти.
Python - (лично я не знаю, но они есть. Чувствую :) .)
Ruby - магия и местами излишний энтузиазм в добавлении шелухи в рельсы
HoHsi: Чтобы судить так категорично, нужно сначала малость узнать технологию. Потом заглянуть, хотя бы, в разработку этих языков и фреймворка. А руководствоваться чувствами, при этом, в поисках объективно лучшего - глупо.
Roman Kitaev: при этом, как бы не был глуп и холиварен мой вопрос. У этих технологий есть минусы, но о них либо умалчивают, либо прощают, оставляя их как "приятный осадок"
HoHsi: Ну так зайдите на github и почитайте раздел Issues. Я скажу вам точно: с вашим уровнем знаний вы не заметите объективных минусов в каждом конкретном языке. Все минусы (кроме багов, которые малодостижимы, опять же, при вашем уровне знаний) субъективны. Кому-то нравится, что Ruby неявно возвращает результат метода, другим Python за его очевидность. Все остальные субъективные минусы вытекают из оссобенностей языков.
HoHsi: у JS хорошо с асинхронщиной. Если нравятся питоньи отступы — берите CoffeeScript, он компилируется в JS. Из минусов, на мой взгляд — слабая динамическая типизация. И если динамическая типизация действительно дело вкуса, то слабая мне представляется объективным злом. Вы просто поскладывайте стоки с массивами, массивы со словарями и числа со строками в JS, поймёте, о чём я.
У Python строгая типизация, есть также аннотации типов (не проверяются во время исполнения, но наверняка есть статические анализаторы, учитывающие типы, надо поискать). Радует более-менее единообразность — у новичка не разбегаются глаза. Основной веб-фреймворк — Django (но есть и другие, например, асинхронный Tornado), есть единые правила написания кода (PEP8). Много библиотек, большая стандартная библиотека. Существует несколько реализаций, среди которых официальный а — CPython, компилятор в байт-код JVM — Jython, компилятор в нативный код — Cython, JIT-компилятор — PyPy. Из минусов — нет оптимизации хвостовой рекурсии (в JS, например, уже есть благодаря Babel), нормальных лямбд, всё очень медленно (V8 гораздо быстрее). Ну и нет таких возможностей с выбором синтаксиса, как в JS с его CoffeeScript, LiveScript, Babel, TypeScript, ClojureScript etc.
Смысла нет делать это одним сервисом. Это разные задачи, пишите два отдельных приложения, им даже не надо общаться друг с другом, достаточно просто читать и писать в одну и ту же БД. Сервис аналитики можно вообще рзаместить на отдельном серваке и даже у другого хостера.
Задача перераспределения ресурсов параллельна веб-морде. Вы можете разные инструменты для разных задач использовать. Python для данных подойдет хорошо.
Чтобы пользоваться данным инструментом, нужно хорошо понимать принцип его работы, а так же уметь анализировать его пригодность к реализации требований вашего будущего продукта.
ИМХО - если предполагается что базовый режим работы сервиса оперирует малыми размерами данных за "сеанс", то нода в целом подойдёт. Для сложных же вычислений (режим "ночь" - анализ банка полученных данных и т.п) - ПХП, ЦПП или что-то с поддержкой многопоточной модели для аналитики (ибо нодовский eventloop, без "хитрых приготовлений" не имеет смысла в данном случае).
Простите, вычисления PHP? Один раз уже извращался подобным методом, хостер запретил тогда запустить мне моего демона и пришлось костылить на PHP, это был не лучший мой программисткий опыт
tex0: начнем с того, что тяжелых операций и не предвидится, тут скорее не сложные матанные конструкции, а подсчет реливантности на score'ах. Что касается скорости, то V8, если я ни чего не путаю рвет RoR как стоячего, и близок к Python
Может скажу сейчас не очевидную вещь, но тяжёлые вычисления в "свободное время (ночью)" на Node тоже вполне можно производить. Просто не надо это делать в event loop`е координирующего процесса. За счёт более экономного использования памяти и скорости языка, такой подход будет лучше чем PHP, и уж точно не хуже Python.
Александр Прозоров: Я все-таки считаю, что любой долгоживущий процесс на PHP - извращение. Сама идея языка в том что-бы просто отдавать контент, а не писать на нем демонов и обработчики. Это как из трактора пытаться сделать спорт-кар (или наоборот), можно, но заставляет задуматься о потраченном времени и ориентации в жизни
HoHsi: "начнем с того, что тяжелых операций и не предвидится" - в таком случае ноду можно использовать я считаю.
"Что касается скорости, то V8" - если не умеючи работать с асинхронной моделью, никакой движок не поможет =)
В общем я вам свои мысли высказал, далее решайте сами, каким инструментом вам пользоваться. Удачи!)
Александр Прозоров: "Просто не надо это делать в event loop`е координирующего процесса."
Хорошо бы чтобы так было при работе с БД (выгребаю "большие" данные), и при этом "выгребающий" инструмент асинхронный.
Плюс ко всему, если нужно "выгребать" разносортные данные для дальнейшей их обработки (независимой друг от друга)... В общем всё зависит от конкретной ситуации.
Вы конечно правы - можно, но лично я тогда в этой ситуации не вижу смысла в использовании ноды) Я бы сделал это другим способом.
tex0: Если проект на Node, то нет смысла раздувать стек "другими способами". Тут весь вопрос в правильной архитектуре и квалификации разработчика. Node-разработчик, это не просто JS-разработчик который просто пишет для бекенда. Предполагается ещё понимание специфических для бекенда вещей, таких как потоки, процессы и асинхронное взаимодействие с ними.
Александр Прозоров: "Тут весь вопрос в правильной архитектуре и квалификации разработчика."
всё верно. Поэтому я и написал в своем main-ответе "без хитрых приготовлений".
"Предполагается ещё понимание специфических для бекенда вещей, таких как потоки, процессы и асинхронное взаимодействие с ними."
Собственно о том же разговор.
Но так случается, что какой-либо модуль(функционал) гораздо быстрее и проще реализовать на других инструментах и квалификация разработчика тут не при чем.
Так же не нужно бояться "раздутого стека" технологий. Главное грамотно подойти к делу. (на случай крупного проекта этого не избежать)
За одним минусом: сама по себе Django медленная. После нужно будет взять топор и напильник и отсечь лишнее. В любом случае, плюсы превешивают.
На том же flask времени на кодинг уходит побольше.
С-обрАзный синтаксис, статическая типизация, многопоточность (легковесные потоки), асинхронность, очень быстрый сборщик мусора, богатая стандартная библиотека, большое количество сторонних пакетов на самые разные темы и много всяких других "плюшек", включая наличие далеко не единственной полноценной бесплатной IDE (если кто-то использует).
Простой
