Play Framework после Django

Я совсем немного программировал на Django (один проект) и только присматривался (эксперименты и тесты) к Play. Как на мой вкус они в целом весьма идентичны. Плюсы Django в динамичности Питона, плюсы Play — в скорости Java.

Я бы ещё посоветовал посмотреть на Revel, фреймворк на Golang. Это почти тот Play (создавался под его влиянием), но заметно шустрее и легче. Плюсы и минусы — в Go vs Java :)

Мне Revel понравился много больше, чем Play. Но у последнего — JVM-инфраструктура, что обеспечивает более широкий выбор.

присоединяюсь к вопросу

пока такие мысли

в плее есть жаба. Т.е. можно притащить с собой сразу вообще всё что есть на JVM. Например, есть reactivemongo, но никто не запрещает тут же рядом заюзать JPA через Hibernate. Или, например, можно наплевать на все эти ресты-фигесты и хранить состояние, цена вопроса - пара строчек. Любой цырк по вашему желанию.

Еще есть идея, что можно написать тру-функциональную админку. В Джанге нужно админку жестоко копипастить себе и править. А с тру-функциональным подходом можно будет просто изобрести такой синтаксис, чтобы админку можно было бы напичкивать функциями, модифицирующими поведение - без копипаста. Еще не пробовал, да, но очень хочу.

Еще хочу вручную заимплементить JPA через reactivemongo. Фактов выполнимости миссии нету, но есть подозрение, что это будет гораздо удобней, чем в чем-либо другом.

Спасибо за ответ. Я смотрел Revel и Gorilla, хотя последний и не совсем фреймворк. Уже использую Go в нескольких проектах, но только для серверов, которые через API перемалывают данные. Удобно и быстро, но реализовать на Go хотя бы среднюю по сложности бизнес логику очень неудобно. Дело вкуса, конечно, но пока так. Потребление ресурсов, конечно, у Go в разы меньше, но по всем моим тестам производительности JVM не только не уступает, а часто превосходит Go.

Я когда Play! 1.x смотрел, то он никак не впечатлил. Но после того, как он стал Scala фреймворком, он стал намного интереснее. Так как писать на Java после Python и C# очень грустно(по крайней мере было), но Scala из того, что уже пробовал очень выразительный и современный язык. Именно из-за него и стал Play! ковырять.

Еще есть идея, что можно написать тру-функциональную админку. В Джанге нужно админку жестоко копипастить себе и править. А с тру-функциональным подходом можно будет просто изобрести такой синтаксис, чтобы админку можно было бы напичкивать функциями, модифицирующими поведение - без копипаста. Еще не пробовал, да, но очень хочу.

Тоже первым делом подумал про DSL для описания интерфейса редактирования моделей. Очень интересная тема.

В Джанге нужно админку жестоко копипастить себе и править.

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

Есть приличный опыт работы с Django, и интерес к Play! и Scala. Есть у кого опыт перехода или просто совместного использования этих фреймворков? Интересует сравнение удобства разработки приложений без учета самого языка.

если просто интересно изучать что-то новое, то почему бы и нет, профита по выхлопу производительности или написанию вы не получите конечно же, сам бложик на play сделал и успокоился (1й версии когда он еще был), киллер фич никаких нет, только старт более медленный.

а зачем? она же прекрасно расширяется

Просто кто-то не осилил наследование^Wдокументацию.

На первый взгляд Django и Play! весьма похожи. Но когда стал копать глубже, то стало видно, что это не так. Для меня сейчас основные преимущества Play! перед Django это полная асинхронность вокруг Akka, удобная работа с realtime функционалом(Web Sockets, EventSource и т.д.) и встроенный менеджер ассетов. Для Django тоже не проблема прикрутить реалтайм оповещения, но асинхронить тяжелее, чем может показаться из-за сторонних библиотек. А манкипатчить все - это создавать бомбу со случайно установленным таймером.

По сути мне хотелось мы услышать сравнение именно фреймворков по некоторым параметрам от людей, которые использовали и тот и другой.

Для меня сейчас основные преимущества Play! перед Django это полная асинхронность вокруг Akka

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

Для какого большинства задач она бесполезна? Типичное веб приложение: получение данных от пользователя, обработка запроса, обращение к базе, формирование результата, отправка ответа пользователю. Это не считая взаимодействия с внешними источниками. Если операции ввода вывода будут асинхронными, то это позволит сократить кол-во инстансов приложения за счет того, что вместо ожидания IO будет обрабатываться то, что уже есть.

Асинхронность это не многопоточность. Для Python есть gevent, tornado, twisted и т.д. Но Django с самого начала в отличии от того же торнадо не проектировался для асинхронной обработки запроса.

Та же Node.js стала популярна и показывает хорошую производительность благодаря асинхронной обработке запросов при этом выполняя все в один поток.

Скорость работы веб приложения мало зависит от языка и много от архитектуры(в том числе и методики обработки запросов).

где нужна асинхронность люди в рельсах/джанге/пхп делают функционал отдельном компонентом и выносят логику в отдельный сервис/сервер

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

К слову у Django на данный момент для меня больше плюсов. Она знакома вдоль и поперек, удобна и богата батарейками. Да и своих наработок уже вагон. Я сейчас сравниваю как раз с позиции Django разработчика. Но хочется развиваться в разных направлениях. Например после начала изучения Scala я и на Python стал смотреть по-новому.

погроммирую на жанго после фласка, матерюсь, ругаюсь, терплю

На мой взгляд, задача Джанги - дать возможность быстро-быстро-быстро клепать веб-приложения уровня информационных сайтов. Собственно, создатели джанги как раз из этого бизнеса. Поэтому, всё что мешает этой задаче - надо улучшить (или убить), всё что помогает - улучшать. Возможность в пару кликов сделать админку для сайта - это круто. Это вообще то, за что многие выбирают Джангу, уже зная ПХП.

А потом оп, и разочарование - вроде «автоматическая админка» и есть, но как применить ее - ХЗ.

Я вот сейчас пишу сайт на node.js для товарища за пиво, и жутко матерюсь - да, у меня получилась шикарная админка на вебсокетах, но я писал ее аж целых две недели по вечерам! Плюс понадобилось нефиговое знание матчасти типа HTTP, ajax, тех же вебсокетов. Разительно отличается от того, чтобы написать class MyAdminka extends BaseAdminka...

Еще интересно в твоей фразе деление на админа и пользователя. Например, я пишу форум а-ля ЛОР. Можно ли считать модератора пользователем? Если да, и мы хотим дать такому «пользователю» админку, то довольно скоро окажется, что мы хотим глубоко изменять стратегии поведения каждой кнопочки. Что поведет за собой копипаст ядра админки, т.к. (в отличие от говновордпресса) тысячами хуков там не заморачивались...

(upd: удалил один абзац - судя по документации джанги генераторов кода в современной джанге больше нет. ура!)

отдельную админку в едином стиле

стиль на админку джанги натянуть можно =)

зачем делать «отдельную» вторую админку, если уже есть одна? Нужно допилить эту, чтобы она больше использовала возможности ООП/ФП, и в результате этого могла гибко кастомизироваться.

Тоже первым делом подумал про DSL для описания интерфейса редактирования моделей. Очень интересная тема.

я грешным делом подумываю о том, что если вопрос упёрся именно в DSL (а не в наследование от базового класса Модель), то нужно сразу брать Jetbrains MPS. Это такая шутка для кодирования DSL легко и просто, чуть ли не мышкой. А целью выбрать обычную жаву, например - это позволит уговорить безголовое руководство, считающее что все должны писать на одном языке (Java), даже если он абсолютно не подходит под задачу.

Пробовал Play после кучи фреймворков (и Джанга мой один из любимых фреймворков). Мне показалось (я бегло тестил Play2) втечение 4 дней, что Play это ад. Компилилось на моем старом тогда ещё атлоне одноядернике около 40 секунд базовое приложение не сложнее трёх хелловордов :-) Писал на скале. Короче, тормоз тот ещё. За гоу плюсую, но ревел мне не сказать, что не понравился на все 100, но я бы писал на нем, если была бы хорошая экосистема пакетов/модулей и хорошая архитектура, мне архитектура в ревеле не очень нравится. Писать вполне можно, но удовольствия - никакого. Тестил производительность - хуже NodeJS, или иногда на уровне. Правда, ревел может многопоточный код, поэтому, если писать движок для игры на ревел - то это будет более оправданно. Из жабы фреймворков понравилось только два: Railo на CFScript и Grails на Groovy. Я бы писал на Grails - очень грамотно сделан и результаты тестов впечатляют. Но тоже требуется время на компиляцию для продакшен тестов, которое примерно соответствует Play. После Grails Play не интересен вообще. Уж лучше сразу писать на Jetty и чистой жабе.

Для какого большинства задач она бесполезна? Типичное веб приложение: получение данных от пользователя, обработка запроса, обращение к базе, формирование результата, отправка ответа пользователю. Это не считая взаимодействия с внешними источниками. Если операции ввода вывода будут асинхронными, то это позволит сократить кол-во инстансов приложения за счет того, что вместо ожидания IO будет обрабатываться то, что уже есть.

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

Что в реальности? play чуть быстрее raw php в JSON serialization (то есть делаем апи например) и намного медленее golang (если хотите скорости то вам сюда), rack-jruby тут тоже доставляет, pypy радует. То есть профитность даже в делании API для вас не особо большая (если она вообще есть)

Идем дальше: single query (ситуация которую описываете вы в большей степени) scalatra raw примерно сравнима по скорости в single query с php, оба отстают в пару раз от golang, но тут разрыв некритичен, nodejs посасывает в середине, джанга тут отстает сильно от скалы, есть определенный профит значит

Next: multi query (ну это уже реал ворлд, мы же не делаем по одному запросу, да?) на коне опять же go и raw php с hhvm, тот же фласк примерно работает как play, разницы в скорости в этом тесте не очень большие

Выводы для себя я сделал такие: если вы хотите профита от асинхронности, то вам надо работать напрямую с ОЗУ посредством всяких редисов, мемкешей и прочего, в остальных случаях толку от этого не особо много, особенно при работе с БД.

Еще интересно в твоей фразе деление на админа и пользователя. Например, я пишу форум а-ля ЛОР. Можно ли считать модератора пользователем?

да модератор это пользователь, просто прав побольше, ему нужна админка которая ориентирована на его задачу, соответственно пише м свою в рамках форума (доп опции, кнопки)

зачем делать «отдельную» вторую админку, если уже есть одна?

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

Я вот сейчас пишу сайт на node.js для товарища за пиво, и жутко матерюсь - да, у меня получилась шикарная админка на вебсокетах, но я писал ее аж целых две недели по вечерам! Плюс понадобилось нефиговое знание матчасти типа HTTP, ajax, тех же вебсокетов. Разительно отличается от того, чтобы написать class MyAdminka extends BaseAdminka...

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

большие дяди уже все померели

Так померли или померяли?

Спасибо за ссылку на бенчи. Но прежде чем делать вывод о том, по ком прошелся маркетинг надо подумать почему Golang показывает такой RPS при этом обладая не самой высокой скоростью выполнения? Я говорил не про асинхронность конкретно в Play! а про архитектуру в общем. Не при чем здесь ни ОЗУ ни Redis и уж точно кеширование.

Я не ищу серебряной пули и не предлагаю делать асинхронную обработку в бложиках. Да и Play! для бложика применять не советую. :) На более серьезных проектах опять же не обязательно. Можно докупить памяти и наплодить инстансов с бизнес логикой и не париться вообще.

Асинхронная обработка IO - это лишь вариант, который позволит повысить RPS не раздувая кластер, но путем усложнения самой логики. Это уже неоднократно проверено и спорить с этим не стоит, говоря, что профита от нее нет.

в остальных случаях толку от этого не особо много, особенно при работе с БД

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

В любом случае, спасибо за мнение.

Спасибо за ответ. У скалки компилятор и вправду скоростями не радует. Но пока меня это не сильно достает. Насчет Go согласен.

почему Golang показывает такой RPS

golang изначально создавался под эту задачу, поэтому его основные фишки - бешеная конкурентность и мега быстрая компиляция, по мне так лучше его вам изучать, чем тот же play. (кроме того язык проще скалы и учиться быстро и задорно), кроме того в тестах не отражен расход памяти, golang в разы экономнее JVM (что мегажирный плюс помойму).

Это уже неоднократно проверено и спорить с этим не стоит, говоря, что профита от нее нет.

профит есть, но смотря в каких задачах и с чем работает стек, просто если вы возьмете и будете использовать play, там где использовали django, профит будет отрицательным (тяжелый стек, долго стартует, долго разрабатывать), а в тех задачах где нужна конкурентность лучше посмотреть на golang или на худой конец на ноду.

если вы хотите профита от асинхронности, то вам надо работать напрямую с ОЗУ [..], в остальных случаях толку от этого не особо много, особенно при работе с БД

Вот-вот. С долгими запросами особенно толку мало. А ещё асинхронность нафиг не нужна при дисковом или сетевом I/O.

golang изначально создавался под эту задачу, поэтому его основные фишки - бешеная конкурентность и мега быстрая компиляция

Точно. Именно за это я и начал ковырять Go еще когда он до стабильной версии не дополз. Как я уже говорил в этом треде, я использую Go в нескольких проектах и очень доволен. Но пока у него сильно хуже инфраструктура, да и логику приложения не очень удобно описывать без нормальной объектной модели(тут чисто вопрос вкуса). А в остальном он очень хорош для своих задач. У меня, например, на нем крутятся пара аггрегаторов новостей + сервера для предоставления информации через свой API.

профит есть, но смотря в каких задачах и с чем работает стек

Вот с этим согласен. Но я и не собирался заменять Django на что то. «Play! после Django» я имел ввиду освоение Play! после продолжительной работы с Django и другими питонячими фреймворками.

Как я понял, java(как платформа) для вэба сливает, да? То есть новые проекты лучше писать на питоне/руби/ноде?

Как я понял, java(как платформа) для вэба сливает, да?

Для веба есть Golang, у которого жаба глотает в захлёб. Да.

То есть новые проекты лучше писать на питоне/руби/ноде?

Новый проект — бери Golang. Стартап — пиши на Golang. Бизнес — Go, Go, Go.

Как я понял, java(как платформа) для вэба сливает, да?

java как язык для веба сливает да. смотри clojure(script)

Go, Go, Go.

--> стена

в большинстве случаев, а не берут установленный в цмс шаблон и пилят его

во всех сайтах на вордпрессе используются стандартные сервисы вордпресса. Неважно какая морда у сайта - админка одна на всех. В т.ч. поэтому там можно в 1 клик ставить плагины на эту админку и сайт вообще. Это потому, что админка хорошая и продуманная. В частности, огромное количество к месту стоящих хуков. У джанги задача сложнее в 10 раз, соответственно и код админки должен быть сложнее не менее чем в 10 раз. Впрочем, наплевать на джангу. Не хочет оно развиваться - ну и наплевать на нее.

В т.ч. поэтому там можно в 1 клик ставить плагины

проблема всех установок в 1 клик в вордпрессе, что в модулях куча ошибок которые править потом тебе, проблемы с совместимостью или модули которые добавляют кучу дыр к твоему WP, никогда не любил эту блого-цмску, ядро там очень слабое нефункциональное, а плагины убоги.

То есть слово платформа в скобках по-твоему я указал просто так, да? Мне было интересно узнать именно ее положение, а не языка.

Нет, голанг пока совсем не интересен.

Интересы, дорогой мой, разные бывают — может у тебя там хронически блого-люэс, тогда вот да — golang вряд ли твоя тема, как и джаба-торпеда между прочем.

Компилилось на моем старом тогда ещё атлоне одноядернике около 40 секунд

на недокомпах неюзабельно, да. Наверное из-за скалы, она компилируется медленно. Еще медленней ее обрабатывает Идея - кэш для автодополнения тот же. Под Скалу нужен нормальный комп.

У меня нормальный комп. i7 3770k. Но на слабом компе всегда тестю платформы. Ибо это даёт повод выявить аутсайдера по ресурсам, которым стал Play2. Тяжелее Play2 я еще ничего не встречал. Тот атлон x64 примерно равен по производительности современным атомам, которые частенько ставят в мини-серверы некоторые хостеры. И на нём тот же гоу с нодой выдавали около 800 rps на простом приложении к SQLite, это вполне тру для такого старичка. Play2 же выдал 300 с чем-то, на продакшн настройках. JVM, каюсь, не тюнил, и не считаю нужным. Но прогревал кэш, и прочее. Жаба не сливает в вебе только если используется жаба-стек технологий, навроде, Jira, где куча mvc уже написана ДО написания web мордочки. А тупо писать интернет магазины/масс медиа на Java не имеет смысла - потеря времени, а Scala не спасёт от частой неповоротливости и гонки за ресурсами. Хотя, для написания своих API - вполне пригодно, но как-то уже тошнит часто от Java и C# многословности и лапшевидности.

да к я тебе говорю что как платформа jvm ого-го

http://java.dzone.com/articles/develope-high-performance

не нужно собирать play на хостинге. Собираешь dist на локальном компьютере и заливаешь на хостинг.

касательно rps, у меня оно не тормозит. База данных - mongo, драйвер - reactivemongo. Может ты где-то понаписал блокирующего нереактивного кода? Или какие-то плагины заюзал тормозные?

А может у тебя просто убогий сервак с 500 мегабайтами рамы. На таком точно ничего хорошего не взлетит.

Java/Scala хороши тем, что на них просто и удобно писать. Всё Просто Работает. А JS писать отвратительно. Даже с Coffeescrpt.

Я вот сейчас на Ноде пишу сайт для убого хостинга (там всего 500 мегабайт рамы) - вот это ад! Никогда больше не буду так делать. Сегодня очередную пачку кода перегнал в Coffescript и раскидал по модулям - стало чуть легче. Люди, юзающие 500-мегабайтные хостинги, и из-за этого пишущие на говне, должны сделать повдоль четверократно.

В чём-то ты прав, думаю, читающие мои комменты поняли и мою точку зрения, спс.

извини что так резко ответил. Просто целыми днями слышу что жава говно, жава говно, жава говно, а как начнешь писать - у меня на жаве почему-то УМВР, а крутейшие поцыки на этом вашем Эрланге три строчки связать не могут. Я полный дибил, значит либо товарищи еще большие дибилы, либо с Эрлангом не все так просто. Лично мне Скала не нравится, это тормозное подобие Крестов под ЖВМ, правиальная штука - это Кложура, но на Кложуре нет никакого self-contained web framework. А значит я буду писать на Кложуре в одиночестве, потому что остальные не захотят инвестировать кучу времени в новую технологию. Сейчас со Скалой можно вывозить в том числе и потому, что Идея имеет такую фишку: копипастаешь жава-код из .java в .scala, и оно производит автоматическую конверсию в скалу. Без этой фичи меня бы съели даже со скалой.

И на нём тот же гоу с нодой выдавали около 800 rps на простом приложении к SQLite, это вполне тру для такого старичка. Play2 же выдал 300 с чем-то, на продакшн настройках

Странно. Я не сталкивался с такой разницей в производительности. Может где-то блокировки были? В целом, по моим замерам, у Play! довольно высокий RPS, но Scala позволяет легко отстрелить себе ногу без знания реализации методов, с которыми работаешь. Это я уже на себе проверил :)

А тупо писать интернет магазины/масс медиа на Java не имеет смысла - потеря времени

В принципе да, но есть и обратная сторона медали. Java(платформа) обладает всем для разработки и дистрибуции коммерческого софта. Будь то какая-то CRM или тот же YouTrack. С относительно закрытыми исходниками.

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

Просто целыми днями слышу что жава говно, жава говно, жава говно

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

Лично мне Скала не нравится, это тормозное подобие Крестов под ЖВМ

Зря ты так. Во всех тестах, которые я находил и сам проводил скорость выполнения у Scala и Java практически одинаковая. В конце концов эта скорость обеспечивается в большей степени самой JVM. В скалке легко можно наворотить делов, если писать на ней как на Java. И тогда получится тормоз.

На мой взгляд у скалы хороший баланс между ООП и ФП, который позволяет сократить кол-во кода при этом не превращаясь в хаскель :)

по поводу базы - в Play нет ORM, есть такие SQL ориентированные штуки:

• Anorm - по сути голый SQL,
• Squeryl - DSL для работы с базой который пытается быть похожим на ORM,
• Slick - маппинг запросов на Scala коллекции.

+ ко всему есть встроенный механизм evolution который позволяет апдейтить схему базы с помощью SQL файлов которые либо пишутся в ручную, либо генерятся вышеобозначенными проектами.

Про Anorm ничего толком не знаю но про него есть не мало инфы в книгах и в доке. Была гдето статья где человек который очень долго работал с Squeryl - рассказывал о куче его недостатков и кучи сложностей при работе с хитрыми запросами и выводе было, что он полностью перешел на Slick и всем доволен.

Slick - судя по всему штука хорошая, была информация что в следующих версиях play будет доступен плагин для работы с ним из коробки (но пока информации как его использовать довольно мало). Но разбиратся с ним по началу сложновато некоторые вещи могут временно ставить в тупик.

Также слышал о проблемах у тех людей которые хотят подключатся в приложении сразу к нескольким разным SQL базам и в случае если есть желание, чтобы приложение работало даже если ему не удалось при старте подключится к базе.

Возможно с MongoDB все намного проще, но я еще не успел глянуть.

А так в целом у меня такое ощушение, что на play сложно сделать небольшое приложение но очень удобно его развивать и поддерживать когда оно будет рассти.

Спасибо за ответ. Да, Play! Не для маленьких проектов. А как же Ebean? Идет из коробки.

и сам проводил скорость выполнения у Scala и Java практически одинаковая.

скала говно не поэтому. А потому что это C++ для JVM. C++ тоже не тормозит, от этого он меньшим говном не становится.

Java/Scala хороши тем, что на них просто и удобно писать

удобно писать на том, что ты хорошо знаешь, просто нужно выйти из зоны комфорта, вот ты приводил в пример Clojure - нравится тебе? пишы на нем :)

А JS писать отвратительно. Даже с Coffeescrpt.

да, JS у меня топ1 ненавидимый язык (он даже хуже пхп), но от него никуда не уйдешь, приходиться страдать иногда, coffeescript еще как-то юзабелен, так же попробуй typescript (ты как явист должен его оценить)

Я вот сейчас на Ноде пишу сайт

никто на ноде не пишет «сайтов», только сервисы либо отдельные модули где нужна конкурентность

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

ну это ты загнул совсем

скала говно не поэтому. А потому что это C++ для JVM. C++ тоже не тормозит, от этого он меньшим говном не становится.

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

никто на ноде не пишет «сайтов»,

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

typescript

ок, спасибо!

тут дело в том, что Scala - это Ява, какой она должна быть. А мне не хочется яву, хочется что-то на порядок мощнее. Вот лисп - да, на порядок мощнее. Clojure хоть и не CL, но хоть что-то. А вообще, я всячески за Jetbrains MPS - можно под каждую задачу писать самостоятельно такой язык, который под нее более подходит. Писать просто и быстро. Еще бы найти заказчика на это.

Если это открытый исходный код - то зачем его продавать? Продавать нужно «продукт», который основан на коде. Код можно как открыть, так и продавать права на него. Здесь широкие возможности монетизации на разогретом рынке, которым Российский рынок по НЕ является.
По мне так ява хороший язык, когда писать приходится не в спешке, и, когда много модулей, классов имеют хорошую архитектуру + не оставляют мусора после GC. А вот сама JVM и её потребление оперативы на коллекциях и других структурах данных - меня удручает. Play2 на скале ворочается медленно потому, что её никто не оптимизировал на производительность - это очевидно. Видимо, создателям важна другая сторона - универсальность и надежность. Лично я вам рекомендую всего -лишь попробовать Grails, есть шанс, что вам понравится :-)

мне не хочется яву, хочется что-то на порядок мощнее

Мощнее в плане синтаксических возможностей или мощнее в плане пиковой производительности? Если производительность интересует - это в сторону D или Go. D мне нравится больше, но их комлятор и бинарник скомпиленный пока далеки до идеала, но работают в правильном направлении, хоть и медленно. Гоу - всё хорошо, но мало развита соответсвующая экосистема, библиотеки и прочее - не просто найти нужное. Время разработки на обоих одинакова, скомпиленный код на гоу запускается быстрее, на D запускается медленней, но работает быстрее TCP стек - смотрите vibe.d (там биндинги к libevent).
Если вы хотите более крутой язык с возможностями явы и всяких питонов, то для статических языков - сделать такое очень сложно, да и нужно ли? Питон, вобщем-то и создавался как замена явы в прикладной и сетевой нише, осталось только подтянуть производительность python VM до уровня JVM, либо ждать JIT для Jython проекта, я не совсем в курсе что у них там за фичи по увеличению производительности.
По мне так... Python / D и диалекты JavaScript создадут будущее. Наверняка скоро JS будут компилить в нативный код, навроде Lua JIT, благодаря V8 он и сейчас работает быстро, но динамическая природа и event-based модель просто не совсем пригодна для написания крупных проектов.

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

Во-вторых, должна быть хорошая поддержка средствами IDE, чтобы IDE знала язык и библиотеки «лучше, чем ты сам». Т.е. я набираю имя класса, ставлю точку, и IDE по-быстрому объясняет мне, как этим пользоваться. Это позволяет писать мне на 10 языках одновременно, не хуже (по крайней мере - не медленней) чем «профессионалы» узкой направленности, и нисколько не беспокоиться о специальном узком обучении. IDE - часть моего мозга.

Важен баланс производительности и описанного выше. В отсутствие описанного выше - производительность не важна, т.к. писать на этом нельзя по опредлению. Неважно, какая производительность у программы, которая никогда не будет написана.