Какая предметная область?

Ну сделали норм документоориен базу, круто же. Я не знаю что они там обещали, но результат вполне годный

а как же couchdb

он масштабируется?

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

Я два каких-то туториала делал. в общем показалось к действительно как oData с нормальным синтаксисом. Плюсы - удобно ретривать ровно то, что тебе нужно. Минусы - если тебе нужны нетривиальные операции модификации, это всё равно будет голый REST, который будет описан как что-то с трудом связанное с чтением тех же данных

он масштабируется?

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

вот саксесс стори https://www.couchbase.com/nosql-resources/presentations/viber-replaces-mongodb-with-couchbase.html

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

Результат получили спустя несколько лет и 300 лямов денег. А обещали все это сразу... Но нешмогли и продолжали всех обманывать

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

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

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

красава, как перешел на джаву, сразу прозрел

ну вот вранье, тыкал я в этот каучбеиз))))

Scala потом Java... потом что PHP?)

Давайте я тоже историю вброшу. В общем, вынудила меня судьбинушка переписать один сервис скаловый (с акка шардинг, перстинт акторы, вью лееры, кафка с схема регистры) ПРОЩЕ. потому что текущий написан бизнес-неправильно, и его проще заново написать чем рефакторить. И под это дело взяли джаву, спринг бут (+ в перспективе спринг кластер), какой-то cqrs фреймворк и еще какие-то джава Рх стримы. И, несмотря на то, что это не скейлится, подход держит до 2000к сообщений в секунду на маке, и пишется легко и удовольствие почти как на скале

ну может раст допилят через пару лет.

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

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

Серьезно? Ты сравниваешь кластер не а скале и один сервис на джаве? И после этого говоришь что кластер сложнее поэтому скала не нужна? А ты неплох))

Так наоборот же там уже есть примитивы из коробки которые в инном случае пришлось бы пимать самому. Единственное что требует Акка это инного мышления - событийно распределенного

Я уточню. Для рапид девелопмента микросервисов, акка кластер отнимает слишком много времени. В то время, как джава спринг или плей/акка + стримы обеспечивют терпимую наггрузку и легко поддерживаются.

одни любят apply/unapply  по вене ставить, другие имплиситы, третить еще что-то

Ты себя только закапываешь этим утверждением))

Ну я, конечно, изрядно набрасываю. С другой стороны, есть вот коммент Ulf Wiger: http://pchiusano.blogspot.ae/2010/01/actors-are-not-good-concurrency-model.html Где он говорит типа что модель акторов оче хороша для разработки и микросервисов и то, что акторы не типизированы - так и задуманы. типа можно быстрей адаптироваться к изменениям бизне-требования. И чо-то это вообще нефига не так для акки. Хер там чо изменишь за один вечер.

Конечно же нужны правила для единого стиля кода в команде, может не хватает грамотного Архитектора или Тимлида владеющего технологией

http://www.sergeymoskalenko.ru/

=( никто не оценил мои гайдлайны для скалы

Я вижу на живом примере, на своем, что тяжеловато в акку что-то впиливать. Быстрей эти микросервисы переписывать как стейтлес сервисы. Отсюда делвю вывод, что в акке что-то фундмаентально не так. Да, хорошо на ней писать монолит. Или когда у вас уже есть пользователи и большие нагрузки. НО для большинстьва бизнес-задач все что угодно кроме акки норм.

Наоборот же, очень удобно добавлять акторы и присоединять их к системе, не меняя соседний код. Можешь примеры привести на досуге, а то не совсем понятно о чем ты говоришь

в акторах сложно отслеживать связи

=( никто не оценил мои гайдлайны для скалы

ну если ты один кодишь, то эт хорошая идея)

альтернативы нужно предлагать конечно исходя из задач

И РУТИНЫ