На чем писать бекенд?

Юрий Ярош: ничего не имею против typesafe, сам в него последнее время влюблен, но все таки мне кажется, что Вы не правы. Play2 на scala еще не достиг уровня django\ror хоть и идет к этому семимильными шагами. В плане поддержки - код на Play2 по сути состоит из кучи лямбд (если мы о реактивных приложениях), которые в плане поддержки тоже не очень легки. Да, это все можно организовать в более красивый код, но требует значительно больше усилий, чем на django\ror. Ну и про накладные расходы - разница настолько незначительная при реализации сокет сервера на gevent (по сути повторяет логику akka), к примеру, что говорить об этом не стоит (все равно все упрется в операции записи\чтения). А так как вопрос был "Подскажите что будет менее затратным по времени и по порогу вхождения", то play2 сливает моментально django\ror, которые в свою очередь сливают разным пхпшным фреймворкам, на которых можно написать первые "суперсайты" уже после первой статьи "как написать вконтактик за 21 день"

kazmiruk
Берём jMeter или Яндекс.Танк, и меряем что где и кого сливает.
По производительности что CPython что Ruby ужасно слоупочны, просто вам видимо не приходилось гонять нагрузочные тесты.

Не знаю мне в Play2 особо всякие методы для Future/Promise типа .forEach() .map() и т.п. не часто были нужны, да и пишу я в основном под Play на Java, больше 2-3 вложенных promise обычно не встречалось. А поддержка сводится к приёмочному, нагрузочному и модульному тестированию, иногда фазингу... она не особо отличается от поддержки проектов на node.js. Это скорее вы просто не привыкли к особенностям тестирования модели актёров.

gevent не повторяет Akka, у неё совсем другая модель передачи сообщений между актёрами, и она скорее похожа на OTP с erlang'a.

В RoR есть нормальный scaffolding, который ведёт к довольно странным костылям, на этом его преимущества заканчиваются. У Django тоже достаточно хорошо развито сообщество, но опять же не ясно как будут обстоять дела с долгосрочной поддержкой.

Накладные расходы на коммуникацию даже между TCP и UNIX сокету - 30 к 1.
Про разницу между монолитной и межпроцессной коммуникацией история вообще умалчивает.
Будете гонять больше 100Мбит трафика на ноду - поймёте о чём я вообще говорю.

Реализуйте реактивный RESTful SOA с CQRS-ES и ААА сервисами - совсем по другому будете смотреть на большинство прикладных задач.

Юрий Ярош: интересно что у Вас за задачи такие, что основные расходы это код на ЯП и подключение к сокету. У меня все проекты упирались в базу. И если перестать гонять нагрузочные тесты на синтетике, то резко значения выравниваются. Ну и я говорил, что сливают не по скорости работы, а по скорости разработки. Долгосрочная поддержка зависит от архитектуры, тестов, качества, что никак не зависит от фреймворка (за некоторым исключением). По поводу OTP - там вообще Behavior-like подход, который ни на akka, ни на gevent не похож. Ну и опять же Вы отвечаете не на вопрос автора, а просто решили устроить холиварчик про "typesafe круче всех"

kazmiruk С сокетами накладные расходы на сериализацию/десериализацию и проброс через TCP, избыточный контроль ошибок и т.п. Для больших объёмов трафика это очень критично. БД не является узким местом, так как обычно всё кэшируется в offheap кэш. OTP - это FSM подход, который как раз таки в Akka и реализован в Typed/Untyped актёрах и STM / FSM. Typesafe не круче всех, в нём тоже есть куча оверхедов. Даже по сравнению с Xitrum'ом он во многом ему проигрывает.

Юрий Ярош: А что скажете о Spring MVC и его REST или об использовании JAX для REST ? Я планирую начать изучение Java поэтому интересно узнать какие сейчас тенденции в вебе на Java.

asd111: Я вообще не люблю сервлеты - слишком ужасные оверхеды. Если запускать сервлет под Netty - можно получить очень большой прирост производительности по сравнению с jBoss или WebSphere... А так как Spring в целом J2EE ориентированый он мне не оч нравится. По поводу JAX-RS на Jersey или Spring Data могу сказать одно - это не DDD. Мне нравится DDD подход так как он способствует построению SOA - берём модельку БД и по её схеме получаем доступ через специальный абстрагированный DataMapper, в итоге один достаточно большой сервис - на любое количество таблиц, который принимает правила авторизации и валидации, хотя часть правил валидации можно генерировать по схеме БД. Также этот сервис предоставляет callback'и и интерфейсы для реализации учёта и аутентификации. Потом можно отправлять JSON-WSP или JSON-Schema в браузер, для автоматического построения формочек и автоматического построения браузерной валидации в богатом фронтэнде ... А так по "классике" у нас получается "одна табличка - один CRUD контроллер", которые потом при большой БД в 50-60 табличек ещё потом как-то нужно поддерживать, и не факт что выползут побочные эффекты или опечатки от вагонов копипасты.

Этот подход сформировался у меня в процессе работы с реактивными приложениями и был реализован в рамках нескольких больших проектов. Очень хорошо зарекомендовал себя при работе с очень большими схемами БД - порядка 80-100 табличек. Сейчас хочу опубликовать под OpenSource для РНР / Java / Golang / Python и отдельно написать статейку на хабр "RESTful Services - you're doing it wrong".

Юрий Ярош: с нетерпением ждем и статьи, и публикации либ/примеров/сниппетов. Очень интересно глянуть и пощупать после Ваших слов.

Tyranron нужно писать статьи что бы американцы их на американский переводили, а не так как сейчас... один ширпотрёп да дилетантство повсюду - только и умеют что потреблять чужие продукты.

Это в models.py?

нет