Долго колбасило в выборе между Play Framework на Java/Scala и Revel на Go.

А почему Grails не учавствовал ?

если выбор между Scala и Go, то лучше Scala.
Go, как язык, какой-то немного обрезанный со всех сторон. Не гибкий. Полиморфизма нету никакого.
Так что уж для веба-то точно JVM лучше.

для явы нет нормального template-engine

и все юзают убогий JSP, а mustache имеет убогий функционал (ява тут не виновата)

а производительность - это дело десятое, я тут на днях съекономил 220мб в 20мб памяти подправив пару строк кода

я тут на днях съекономил 220мб в 20мб памяти подправив пару строк кода

Cool story, bro!

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

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

для явы нет нормального template-engine

а «нормальный» - это какой ?

Go, go Johnny go go Go, Johnny B. Goode

ну ты сам попробуй изложить требования, и узреешь, что например в тупом и перегруженном синтаксисом jsp есть тыща способов устроить геноцид ног, но нет «макросов», и тупо придется копипастить код 8)

А почему Grails не учавствовал ?

Сам его не щупал (не удалось по-простому заставить работать, вываливает много экранов стектрейса (его вложенность сама по себе убивает) на тему того, что «java.lang.ClassNotFoundException: unable to locate the java compiler com.sun.tools.javac.Main», при том, что другие Java-приложения работают отлично). Но, говорят, что он же весьма тормозной?

я просто хотел пример «нормального», чтобы знать на что ориентироваться

ты его на oepnjdk запускал или вообще на jre чтоли?

для явы нет нормального template-engine

я только здесь насчитал 14 штук + некотоое количество велосипедов, о которых известно лишь паре человек. ты точно опробовал все?

/* если что, на яве почти ничего не писал */

если выбор между Scala и Go, то лучше Scala.

Мне Go как-то больше импонрует. Хотя и там и там знакомство пока чисто косметическое.

Другое дело, что за Scala стоит JVM. Но это же можно и недостатком считать. Достаточно глянуть, как долго (много секунд) обновляется после изменения сорца окружение в Play и как быстро (доли секунды) — в Revel :)

Полиморфизма нету никакого.

К Go нельзя подходить с классической ООП точки зрения, как я понял. Сочетание утиной типизации и... не знаю, как оно правильно называется, эдакая «контейнеризация» вместо наследования выглядять на мой поверхностный взгляд привлекательно.

а производительность - это дело десятое

Мне, как старому PHP-шнику, можешь это не говорить :) Но именно потому и интересны именно очень производительные и экономные решения. Если где-то не хватит PHP, какой смысл менять шило на мыло?

я тут на днях съекономил 220мб в 20мб памяти подправив пару строк кода

Кстати, тут JVM, правда, тоже рулит. Средства профилирования в ней отличные и давно отработанные. Боюсь, что в Go с этим не так радужно.

да я их сколько смотрел они все какието ненормальные, а так да можешь потроллить - по функциям типа velocity, но с нормальным синтаксисом/поддержкой заглушек для верстки (когда вместо <val=${varName}>тут будет значение varName</var> выводится содержимое тега при верстке шаблона в браузере и содержимое переменной после рендеринга) и объявлением зависимостей (чтобы сказать - для этого шаблона подтяни some.js и some.css)

Достаточно глянуть, как долго (много секунд) обновляется после изменения сорца окружение в Play

дело не в jvm, дело в scala

а «нормальный» - это какой ?

Кстати, мои предпочтения у шаблонизаторов, имеющих наследование и позволяющих включать логику. Как с этим у шаблонизатора Play (вроде, нет отдельного имени?) не разбирался дальше HelloWorld'а. Но, если не понравится, что мешает подключить другой? Не верю, что под JVM нет выбора шаблонизаторов :)

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

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

ты его на oepnjdk запускал или вообще на jre чтоли?

java-1.7.0-openjdk-amd64

Без JDK он и не встанет, он за собой по зависимостям его тянет.

Как я уже говорил, другие — работают. Тот же Play Framework, что на лету компилит изменения в сорцах.

и объявлением зависимостей (чтобы сказать - для этого шаблона подтяни some.js и some.css)

Ну, как на мой взгляд, этим заниматься контроллер должен. По крайней мере в моём фреймворке это так сделано :)

ну судя по названиям классов он требует оракловский официальный jdk

дело не в jvm, дело в scala

И в JVM тоже. Я же с Java хорошо ещё со времён L2J знаком :) Сколько тысяч компиляций и перезапусков я лет 5..7 назад проводил...

Но, говорят, что он же весьма тормозной?

про java тоже самое говорят

ну судя по названиям классов он требует оракловский официальный jdk

Я тоже так сперва подумал. Но потом подумал, фиг знает, может это стандартные имена классов и в openjdk они же используются. Проверять не стал, забил :)

а я тут топик недавно создавал в т.ч. и на эту тему, там мне тоже доказывали что в контроллере, но я спросил: а зачем в контроллере объявлять элементы дизайна? Понятно если js - кусок какойто логики, но ведь с css это не так

Но, говорят, что он же весьма тормозной?

про java тоже самое говорят

Ладно, сейчас попробую запустить Grails на машине с официальным сановским JDK (под Gentoo, а то я в LXC-машине с Ubuntu гоняю тесты), сравню с конкурентами.

...

А, блин, под Gentoo же нет оверлея с Grails. Тогда не судьба.

Кстати, в LXC на Hello world'ах пиковая производительность у меня получается:
— Django: ~500 rps
— Play Framework: ~1000 rps
— Revel: ~1600 rps

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

стоп, так «для явы нет нормального template-engine», или «вообще нет нормального template-engine» (т.е. есть, но не для java) ?

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

но я спросил: а зачем в контроллере объявлять элементы дизайна?

Оно (у меня) элемент представления, но подключением занимается контроллер.

То есть, грубо говоря, для выводимого объекта (страницы для определённости) у меня есть следующие файлы:
— view.php / view.yaml — логика или модель представления.
— view.tpl / view.haml / etc — представление (шаблонизаторы в ассортименте)
— view.inc.css — подключаемые стили
— view.inc.js — подключаемый JS-код

Кроме первого пункта остальные все опциональные. Контроллер фреймворка проследит наличие нужных файлов и сгенерирует нужные вставки.

чо стоп, для не явы - я не искал, посматривал но целенаправленно поиск не проводил

однако, что там у grails внутри что он его не нашел - неясно

Меня убил стектрейс. Сейчас не поленюсь...

$ grails create-controller hello | wc -l
607

Около 600 строк трейса. Я ещё такой вложенности нигде не встречал :D

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

Что ты имеешь в виду под «простым веб приложением»? Отдельное приложение на сервере приложений?

Мне интересен именно PHP-like вариант, когда меняешь исходник (контроллера, модели), жмёшь F5 и видишь изменение. И Revel, и Play это обеспечивают. Естественно, на контроль модификаций файлов ложится небольшой оверхед. Чистый JVM-сервер «вещью в себе» будет пошустрее работать. Но вряд ли сильно.

Оно (у меня) элемент представления, но подключением занимается контроллер.

во во, а в рамках повторонго использования представления - контроллер становится носителем мелочи вроде декларации ресурсов или «взять данные из базы по id и отдать в рендер шаблонов» меня во всех фремфорках печали эта многословность, тем более что у меня как правило используется naked objects приечики отчего даже с orm - нет контроллеров (точнее один универсальный) и представление одно (а иногда надо кастомизировать и вот тут вылезает фигня с фреймворками требующими контроллер на каждое представление)

Что ты имеешь в виду под «простым веб приложением»? Отдельное приложение на сервере приложений?

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

Мне интересен именно PHP-like вариант, когда меняешь исходник (контроллера, модели), жмёшь F5 и видишь изменение.

ну определись, либо это будет jsp - компилируемая сервером, либо черти что компилируемое черти чем, а там уже все зависит от совести разработчиков того чем компилируется шаблон, к примеру, ибо сорцы явы компилируются всегда одним и темже, а вот таже скала компилируется гораздо медленее, как и груви. PHP же у тебя не компилируется, а Go?

в рамках повторонго использования представления - контроллер становится носителем мелочи вроде декларации ресурсов или «взять данные из базы по id и отдать в рендер шаблонов»

Я у себя использую не совсем классический MVC. В полном варианте (есть и сокращённые) работа выглядит так:

— Есть модели. Это тупо классы объектов, источников данных. Могут быть как с ORM-бэкендом, так и иные по сути. Хоть хардкод данных. Хоть, сейчас понемногу делаю, REST-объекты. Важно, что их можно стандартным образом загрузить по ID, выбрать по условию, прочитать параметры, записать параметры. Создать новые.

— Есть представления. Обычно состоят из шаблона и логики представления, которая может дёрнуть упомянутые данные для наполнения шаблона и т.п.

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

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

ну определись, либо это будет jsp - компилируемая сервером, либо черти что компилируемое черти чем

Давно определился :) Именно второй вариант интересен.

PHP же у тебя не компилируется, а Go?

Да оба компилируются :) Только первый в байткод в оперативку, а второй — в нативный код на диск.

ибо сорцы явы компилируются всегда одним и темже, а вот таже скала компилируется гораздо медленее

Кстати, под Play на простых примерах, что компиляция Java-сорца, что Scala-сорца вызывают сходную задержку. Скорее всего там вообще инициализация подсистемы компилятора тормозит.

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

Мне Go очень нравится, пописываю на нем немного just for fun. Но в чем смысл использовать его для «сайтов»? Тогда уже лучше какой-то Grails.

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

Интересно, на фреймворках, типа Revel или Play, где сам бог велел наличием компилятора в оных, такое никто не делал? Представляю производительность шаблона, который в случае Revel/Go будет нативным бинарником :)

Но в чем смысл использовать его для «сайтов»? Тогда уже лучше какой-то Grails.

А чем Grails лучше? Ну, вопрос преимущества JVM оставим, выше он обсуждалсяю

если JAVA_HOME указвает не на jdk а на jre, то получается именно так

если JAVA_HOME указвает не на jdk а на jre, то получается именно так

$ echo $JAVA_HOME
/usr/lib/jvm/java-1.7.0-openjdk-amd64

:)

И если JAVA_HOME неверный, то Play не работает. А у меня — работает.

А чем Grails лучше?

Скоростью разработки

А чем Grails лучше?

Скоростью разработки

У меня сейчас процентов 70 кода вообще на YAML пишется. А 95% всего времени разработки уходит на HTML-вёрстку, дизайн БД и набивку простых текстов.

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

Соответственно, и в выбранном альтернативном фреймворке постараюсь такого рода обвязку организовать. Писать типовые задачи _программируя_ их? Фу.... :)

Не гибкий. Полиморфизма нету никакого.

лолшто? Откуда такое предвзятое мнение?

Я имел ввиду общую скорость разработки, а не скорость программирования

Мне было просто интересно, почему в сравнении Play/Ravel не было Grails, и ответ я уже получил )
Агитировать за использование и что-то доказывать я не буду )

Я имел ввиду общую скорость разработки, а не скорость программирования

Разве они сильно отличаются? Из-за чего?

Тут есть программисты на оном?

Немного знаком с этим языком чудным.