Play Framework 2.5 «Streamy»

Вопрос к джавистам, чего все носятся с этой скалой и аккой, когда есть прекрасный джавовый квазар?

джавовый квазар

Это слизанный эрланг со всеми его проблемами. Тысячи вроде бы легковесных (~бесплатных) потоков, который на реальном проекте отожрут всё начиная от RAM и заканчивая постоянным переключением контекстов на CPU. Это прошлый век.

Тысячи вроде бы легковесных (~бесплатных) потоков, который на реальном проекте отожрут всё начиная от RAM и заканчивая постоянным переключением контекстов на CPU

Странно, в эрланге такого не происходит.

Это прошлый век.

А что у нас современнее?

получить back-pressure

надо сказать что на Iteratee тоже back pressure есть. За исключением WSClient, в котором как раз back pressure появился вместе со стримами.

прекрасный джавовый квазар

quazar это ж адская магия, прекрасным он может показаться только любителям Spring Framework и прочих AOP извращений.

Akka Streams

Reactive Streams это несколько больше чем Akka Streams, тут скорее речь об использовании общего стандарта не связанного с конкретной реализацией.

Оно уже научилось работать из read-only /opt?

back-pressure

когда туда back compatibility завезут то?

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

Поддерживаю. У нас в России джависты очень любят Spring, и мне не понятно за что. И ничего «кроме» видеть не хотят. Типа «не интерпрайз» и всё тут. Нет понятных книжек по скале - значит, скала г.

Нетти 4 версии – это хорошо. Да и вообще, все хорошо в релизе, кроме того, что скала, с одной стороны, так и не смогла пробиться дальше маргинального меньшинства с его любовью к сложному и не очевидному, а с другой стороны – совсем не Хаскель.

Почему Twitter предпочитает Scala?

Упоротые хипстеры с кучей чужого бабла, вот и предпочитают то node.js, то scala, то еще какое-нибудь поделие.

Про скалу уже вижу вопросы на том же реддите, по типу «Scala is not dead, but...»

Не то чтобы любят, но две терти вакансий для джавистов имеют в своем списке требований спринг и hibernate.

джависты очень любят Spring, и мне не понятно за что

Мы точно про интерпрайз? Что ещё любить, jee?

тем что квазаром никто не пользуется наверное

Странно, в эрланге такого не происходит.

Там всё банально: если вдруг эти грин-треды не успевают освобождаться быстрее, чем занимаются, то постепенно растёт конкуренция за ядро CPU, когерентность CPU-кеша падает, всё подтормаживает. Однажды, пул CPU исчерпывается или тормоза становятся нестерпимыми. Всё усугубляет очень ленивые generation-gc эрланга.

А что у нас современнее?

Вот предлагается Fork-Join с тред-пулом размером cat /proc/cpuinfo | grep processor | wc -l. Все блокирующие задачи (JDBC например) или явно выносить в отдельный пул, или использовать, например, slick, где это и многое другое предусмотрено by-design. Это работает максимально эффективно и тупо удобнее для программиста, потому что последний почти никогда не работает напрямую с потоками, а только с задачами, и часто это делает неявно. Без всяких spawn() и прочего счастья.

Поддерживаю. У нас в России джависты очень любят Spring, и мне не понятно за что.

За IoC?

На чём они зарабатывают? Публикуются ли где финансовые показатели, очень интересно с этой точки зрения на фреймворкостроение посмотреть.

cat /proc/cpuinfo | grep processor | wc -l

nproc

спринг это не интерпрайз, а как раз хипстерство. Любят его за то, что он очень удобный. Да и альтернатив ему считай что нет (предложи альтернативу?)

Тот же Play / Grails.

У нас в России джависты очень любят Spring, и мне не понятно за что.

На планете земля java программисты любят Spring за то, что:
Spring - отличный IoC контейнер.
Spring DATA - удобный фремворк для доступа к данным.
Spring Cache - банальное декларативное управление кэшем.
Spring MVC - замечательный фремворк как для создания REST API, так и Web приложений.
Spring AOP - фремворк для тех, кто не смог осилить AspectJ(т.е тем, кому нормально, что декларативное управление транзакциями, безопастностью, логированием, кэшированием чуть-чуть менее эффективно с точки зреня скорости и потребления памяти, а также кому не режет глаза, от того, что, что бы вызвать свой собственный метод bean должен обращаться к себе же через ссылку на себя полученную из контейнера).
Spring Security - приличный Security фремворк.
Spring Boot - отличный фремворк использующий принцип
Convention over Configuration, позволяющий склеить все перечисленные за несколько минут и уходить домой с работы вовремя :-)
Spring Test - позволяет все это очень удобно тестировать (как интеграционными так и unit тестами).

Буду благодарен, если кто-то изложит, как он решает все эти задачи без Spring и главное зачем он так делает?!

Grails и Play это вообще не джава, сравнивать с ними некорректно.

Grails не юзал, а у Play по крайней мере никакая, оно предназначено чтобы быть центром мироздания, вокруг которого все вертится. Но в реальном мире все вертится скорей вокруг 48 варок, размазанных по кластеру из вилдфлаев и ораклов, вебня на которых написана на каком-нибудь Struts или Wicket, и свой любимый фреймворк можно продавить только в каком-то очень ограниченном виде дабы не порушить готовые решения.

Например, как ты к Wicket приклеишь Play? Я пытался разрулить этот вопрос, и похоже что НИКАК. А вот Spring я смог влить в Wicket довольно органично - н-р можно заменить дырявую авторизацию Wicket на Spring Security, можно ловить аякс не через викетовский шизофреничный форк jquery «wicket ajax» а прямо SpringMVCшными контроллерами или заAOPленным DWR и потом стыковать логику SpringMVCшных контроллеров со Wicket'овскими пейджами и панелями с помощью спринговских же бинов, итп.

Spring это огромная экосистема притертых друг к другу проектов. Которые сделаны с пониманием необходимости использования ядра в виде dependency injection, AOP, итп. И ядро это удобно оформлено, что припиливаемо почти везде.

Spring припиливаем для приложений, созданных до спринга, и даже вне ядра. Например, Spring Boot можно развернуть как самостоятельный сервер, а можно задеплоить как WAR для ынтерпрайзного сервера. Что очень важно для заказчиков, которые без использования ынтерпрайзного сервера пошлют тебя нафиг сразу.

Или например, всего где-то за неделю я припилил Spring Cloud Netflix к чем-то написанному 10 лет назад.

Spring довольно стабилен и в качестве кора, и в качестве побочных проектов. Например, когда я бэкпортировал куски нового Spring Data на форк его же 1.5-летней давности, там внтури поменялось много чего, но интерфейсы выдержаны отлично, надо было поменять всего пару строчек. То есть люди может и херню иногда пишут (мне не нравится Spring Data), но пишут вдумчиво и аккуратно.

Возможно, все это достижимо в Play и Grails, и ты это умеешь, и вот здесь хотелось бы послушать твое профессиональное мнение как это правильно делать.

А ЛОРчик кстати на каких фреймворках писан? Play или Spring есть? Или всё по старинке на голых сервлетах?

А ЛОРчик кстати на каких фреймворках писан? Play или Spring есть? Или всё по старинке на голых сервлетах?

Чувак, не тупи >_< www.linux.org.ru/about -> https://github.com/maxcom/lorsource

Буду благодарен, если кто-то изложит, как он решает все эти задачи без Spring и главное зачем он так делает?!

Не мое, но я согласен с оратором: https://www.youtube.com/watch?v=TSAlj04_tkA и https://www.youtube.com/watch?v=cPXTozVjSHo + http://www.slideshare.net/antonkeks/simplicity-8971441

Spring Data - ужасен. Чуть в сторону от того, как предполагается его использовать (например, нужны кастомные запросы) и все: сложность возрастает на порядки в условиях отсутствия какой-либо документации.

Логирование с одной г пишется, а не с двумя.

«Квазар» и т.п. хорошо бы работал на нормальных процессорах с дешевым переключением контекстов. А «Плей» это решение для реальной жизни, где AMD64 везде.

По скале давно уже есть книжки на любую аудиторию, включая студентов техникумов и бакалавреатов вузов.

Я уже давно не видел JVM, в которой крутилось бы более одного приложения. Чаще наоборот, одно приложение разрублено на компоненты каждый из которых крутится в своей JVM. Для запуска - обычный init скрипт, и пофигу что там внутри. Чаще всего это не контейнер + war, а какой-нибудь embedded контейнер с приложением в «одном флаконе» (обычно jetty, но мне попадался и grizzly, и tomcat в этой роли), либо креатифф на netty, либо play, либо spray/akka-http.

Буду благодарен, если кто-то изложит, как он решает все эти задачи без Spring и главное зачем он так делает?!

Во всем этом комплекте только один нормальный компонент — Spring MVC. В 5-ке к нему прикрутят Reactive Streams и их можно будет начать пользоваться и в новых приложениях.

Все остальное — микс магии и костылей вокруг этой магии, этим можно пользоваться только по приговору суда. И не понятно зачем.

А DI с помощью чего? Или без DI жить?

DI в спринге - яркий пример того как это делать не надо.

DI в спринге - яркий пример того как это делать не надо.

Почему? Что не так?

Не знаю, сама идея 10005000 потоков уже оказывается ущербна на реальных задачах. Если захочется запустить 5 параллельных задач в рамках одного запроса, затем объединить результат, отрендерить финальную страничку, то начинается велосипединг своего наколенного ForkJoin, он будет кривой и страшный. «Дешевое» переключение контекстов — тут по сути плата за владение геморроем.

У play'а есть косяки, которые выправляют. С 2.4 внедрена поддержка DI, пожиревшие компоненты выносят в отдельные проекты. Но это фреймворк для проектов завтрашнего дня со своими взглядами на то «как правильно», а как нет. Проекты будут писать и пишут сегодняшние хипстеры, так же как и зрелый проект на 48 war'ок под Oracle AS писали когда-то в своей юности сегодняшние бородатые апологеты. Если впихивать это всё в уже сформировавшийся зрелый проект, то придётся многое переписывать, в этом нет смысла.

А куда они туториалы нормальные дели?

Ага, доки у них напрочь упоротые. Очень мило, что разрабы фреймворка не могут свой сайт нормально сделать. Зато у них скала, акка, нетти и еще много модных баззвордов.

Проекты будут писать и пишут сегодняшние хипстеры, так же как и зрелый проект на 48 war'ок под Oracle AS писали когда-то в своей юности сегодняшние бородатые апологеты.

Микросервисы блеять!

autoscan, потроха objectfactory, вообще потроха его надо развидеть

работа с многопоточностью + мутабельность всего и вся

Микросервисы

Акка в помощь. Тут всё уже готово.

Про скалу уже вижу вопросы на том же реддите, по типу «Scala is not dead, but...»

Да все к этому и идет. Typesafe переименовались, сделали ребрендинг и сместили фокус со Scala на Java. А это значит такой мощной (какая была) поддержки Scala уже не будет.

Да и потом в Java8 и Java9 есть уже много всего того, за чем приходили разработчики на Scala. Поэтому роль Scala сейчас становится все более сомнительной. Ну и Scala слишком сложна, это факт. Попробуйте «прочитать» код в проекте на Scala так же легко, как читается Java код. А если там разработчик еще scalaz добавил, то это просто ад.

Акка в помощь. Тут всё уже готово.

48 war'ок под Oracle AS

Тут тоже.

> 48 war'ок под Oracle AS
Тут тоже.

И так будет всегда?

И так будет всегда?

А зачем велосипед изобретать?

Typesafe переименовались

Они сказали что никуда от Скалы не уходят и что Lagom это для монолитов на Джаве, а у Скалы и так все хорошо.

Ну и Scala слишком сложна, это факт.

У меня в команде есть человек, который кроме Java ничего не видел. И ничего, через пару дней тренировок с scala-labs и правельным code-review он коммитил вполне вменяемый рабочий код. Никто не заставляет сразу же все знать о сложных кусках Скалы, без них вполне можно обойтись.

Ну вот судя по этим словам

but never became mainstream

из новости на redmonk.

Несмотря на все вливания бабла в Scala со стороны Typesafe она так и не стала мейнстримом, и не станет уже вовсе кажется.

Я вот вообще не вижу причин использовать Scala сейчас. Раздувать из-за нее время сборки проекта, когда все что надо есть в Java8. Зачем ? Я понимаю когда все на нее побежали на Java6, но сейчас то...

Я понимаю когда все на нее побежали на Java6,

Побежали только жаждущие писать нечитабельные шифрограммы. Я не понимаю зачем использовать java если хочется перлоподобных извратов?

все что надо есть в Java8

костыли там есть, не более.