LINUX.ORG.RU

Scala + Play: кто-нибудь пробовал?

 ,


0

3

Кто-нибудь пробовал связку Scala/Play? Собираемся писать проект, средних размеров вебсайт и подбираем веб стак. Сами джава разработчики. Можете подсказать в чём плюсы-минусы этого стака? Как вариант, смотрим, на RoR, но знания Руби слабоваты + как привыкли работать со статически типизированным языком (Java).



Последнее исправление: podelkin (всего исправлений: 1)

А почему не просто на Java, раз java-разработчики? Зачем Scala?
PS: в web-development перенести бы

kovrik ★★★★★
()

Я пробовал только Scala без Play. Мне понравилось.

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

dave ★★★★★
()
Ответ на: комментарий от kovrik

Есть возможнось и желание выбирать и пробовать. Джава - это многословно и меньше фана, язык для энтерпрайза.

podelkin
() автор топика

да нормально все.

в чём плюсы-минусы этого стака?

в том, что скаля. если у вас будет какой-нить томкат и jsp, то будет пачка гемороя с типами. play от этого сильно избавляет. зато появляется другая проблема, у меня, например, почему-то не хочет играть flash, если play работает через апач. почему я хз, так и не поборол, сделал знатный костыль :)

если же делать что-то развито, например с extjs, то разница в play vs tomcat имхо не велика. extDirect, жабья либа для него и алга собсно.

Rastafarra ★★★★
()
Ответ на: комментарий от dave

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

это афигеть какая жопа, если видишь в первый раз ))

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

Rastafarra ★★★★
()

Плюсы:

- двойное API;

- хорошее mvc + rest;

- встроен фреймворк Akka 2 для асинхронности/распределенности;

- перекомпиляция на лету + собственный шелл;

- легкое развертывание.

Минусы:

- в скаловской версии противоречивая библиотека для работы с БД anorm;

- потребление памяти выше среднего.

+/-:

- play 2.0 в отличие от play 1.x написан на скале;

- шелл, система сборки и прочий обвес сделан на sbt, который некоторым не нравится.

ovk48 ★★★
()
Ответ на: комментарий от anonymous

отсутствие вменяемой IDE?

Intellij Idea - вполне справляется со скалой.

А как же дикий синтаксис?

Если сильно не извращаться - то синтаксис приятный.

RedPossum ★★★★★
()
Ответ на: комментарий от anonymous

А как же дикий синтаксис и отсутствие вменяемой IDE? Может лучше Clojure?

По-твоему значит, с синтаксисом и поддержкой в IDE у кложуры жаба-разработчику будет легче, чем у скалы? :)

ovk48 ★★★
()
Ответ на: комментарий от anonymous

А чем Clojure лучше? Менее распространённая, учить emacs желания нету - и так хавает новых вещей разбиратсья. Скала, конечно, замороченная ,что немного отпугивает, но поначалу можно писать в джава-стиле используя подсет фич, а вот на лиспоподобный синтаксис пока переходить желания нет.

podelkin
() автор топика
Ответ на: комментарий от podelkin

Плюс есть желание поковыряться в исходниках пары Scala проектов (Akka, Spark), поэтому выгоднее привыкать к Скале.

podelkin
() автор топика
Ответ на: комментарий от anonymous

по интернетам гуляют статьи о сложности скалы?

рядом с ними ровно так же гуляют и «о легкости скалы». и? что сказать-то хотел?

Rastafarra ★★★★
()
Ответ на: комментарий от Rastafarra

https://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/Lisko...
Ну что? Все понятно? Для Ъ процитирую

  def lift4[T[+_, +_, +_, +_], A, A2, B, B2, C, C2, D, D2](
    a: A <~< A2,
    b: B <~< B2,
    c: C <~< C2,
    d: D <~< D2
  ): (T[A, B, C, D] <~< T[A2, B2, C2, D2]) = {
    type a[-X] = T[X, B2, C2, D2] <~< T[A2, B2, C2, D2]
    type b[-X] = T[A, X, C2, D2] <~< T[A2, B2, C2, D2]
    type c[-X] = T[A, B, X, D2] <~< T[A2, B2, C2, D2]
    type d[-X] = T[A, B, C, X] <~< T[A2, B2, C2, D2]
    d.subst[d](c.subst[c](b.subst[b](a.subst[a](refl))))
  }
А там еще укуристее есть.

bga_ ★★★★
()
Ответ на: комментарий от Rastafarra

Скала была бы читаема если бы не [] у типов, куча опараторов неизвестного назначения, дикое количество _ (сахар для лямбды)

bga_ ★★★★
()
Ответ на: комментарий от bga_

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

RedPossum ★★★★★
()
Ответ на: комментарий от bga_

Ну что? Все понятно?

ну более или менее... с ко- и контрвариантностью разобраться и в бой :)

Для Ъ процитирую

гики такого кода могут наплодить на любом языке, это не особенность отдельно взятой скалы.

Rastafarra ★★★★
()
Ответ на: комментарий от RedPossum

А вдруг тебе этой либой пользоватся? Плохо что язык позволяет так писать. Мне казалось история перла выучена.

bga_ ★★★★
()
Ответ на: комментарий от bga_

Плохо что язык позволяет так писать.

Да почти любой язык, не заковывающий человека в смирительную рубашку, позволяет писать непойми что, особенно в области генериков. Если кому либо и придет на ум лезть в код, где все эти [_+, +A, -B], то квалификация этого кого-то и знание языка должны быть на уровне. А если их нет, то достаточно знать что

lift4(a,b,c,d) = co1_3(a) compose co2_3(b) compose co3_3(c) compose co4_4(d)

RedPossum ★★★★★
()
Ответ на: комментарий от bga_

Скала была бы читаема если бы не [] у типов

фиг знает, мне явно нравится. если наплодить a [b [c [d]]], то тут да, как-то теряется прелесть, но можно же этого и не делать :)

куча опараторов неизвестного назначения

есть дока. зато свои делать очень удобно и каждый раз явно тянет :) еще бы префиксные в любом количестве разрешили бы определять....

дикое количество _ (сахар для лямбды)

ну это да, во многих случаях я тоже за явное описание.

Rastafarra ★★★★
()
Ответ на: комментарий от RedPossum

Акку и так в скалу встраивают(встроили?)

Ну да, в 2.10 вроде обещали. Но в play есть хелперы, в т.ч. автоматом создаваемая и обслуживаемая ActorSystem.

ovk48 ★★★
()
Ответ на: комментарий от bga_

А вдруг тебе этой либой пользоватся?

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

Плохо что язык позволяет так писать.

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

Rastafarra ★★★★
()
Ответ на: комментарий от Rastafarra

Странные вы люди, программисты. То вам скучно то вам ненадежно. Вы не там ищите фан. Фана в минимизации кода, «интересном», «красивом» его написании мало и рано или поздно он надоедает. Хачить язык тоже (я 2 года хачил js, реально надоело). Фана гораздо больше в проектировании, во всякой математике и мысленных экспериментах.

bga_ ★★★★
()
Ответ на: комментарий от Rastafarra

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

bga_ ★★★★
()
Ответ на: комментарий от bga_

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

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

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

так-то мне и ocaml (с ocamlp4, естественно) хорош, но батарейки у него слабоваты для ынтерпрайза...

Rastafarra ★★★★
()
Ответ на: комментарий от bga_

Фана гораздо больше в проектировании

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

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

Плотские утехи надоедят быстро. Будь как Гаусс или Кантор.

bga_ ★★★★
()
Ответ на: комментарий от bga_

[..]А там еще укуристее есть.

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

dave ★★★★★
()

Playframework вещь хорошая. Scala язык сомнительного свойства, у него небольшой избыток в конструкциях.

ИМХО, я бы остался на Java. Однако, если хочется развиваться, я бы выбрал Clojure для обработки многопоточности, очень компактный язык и активно развивается.

Sigrlami
()
Ответ на: комментарий от Sigrlami

Ну наконец то. А то все Scala да Scala.

anonymous
()
Ответ на: комментарий от Sigrlami

Я посмотрел на Clojure - действительно небольшой и выразительный, хоть и непривычный после Си-подобных языков. А вы пробовали Clojure? В частности, веб фреймворки - Noir или что у них там есть более менее допиленное?

podelkin
() автор топика
Ответ на: комментарий от podelkin

Да, пробовал, правда я занимаюсь бекэндом.

Noir наиболее адекватный, он представляет из себя надстройку над несколькими другими более низкими по уровню библиотеками. Идеология работы в вебе как у Ruby Rack. Ко всему есть Clojure-to-js компилятор. Я например не люблю js, но так как он поддерживается везде и на нем все пишут, то это удобная фича Clojure сообщества, «нагенерить этого вашего js» )

В последних версиях появился extensible reader позволяющий парсить и сериализовать кастомизированные типы данных, с поддержкой дат и UUID, без использования Java.

Ко всему, удобно писать DSL под логику и использовать джававское окружение.

Теперь о недостатках в продакшене: 1. До Play framework им как до Мекки пешком, я не знаю или можно через джававские биндинги подкючить его к Clojure.

2.Нет мегакрутой иде, если не привыкли к эмаксу будет печально, Джет Брейнс что-то там пытались делать, но там совсем сыро.

Sigrlami
()
Ответ на: комментарий от Sigrlami

Спасибо за инфу, возможно, потыкаю её. Нишу Clojure примерно прикинул: можно юзать для бизнес логики в связке с веб прослойкой на чём-нибудь более проработанном, при условии, что команда не против. Вижу, что лаконичнее и выразительнее Скалы, но пока ещё сырые вебфреймворки, IDE. Везде эти компромиссы... :)

podelkin
() автор топика
Ответ на: комментарий от podelkin

К сожалению. Я только могу предложить третью альтернативу Groovy(не уступает ни Scala, не Clojure по функциональности) и Grails как фреймворк. Недавно начал постигать и его, литературы полно.

http://www.ibm.com/developerworks/java/library/j-ft7/index.html для начала ознакомления.

У Java разработчика, есть 3 пути развития Groovy, Scala, Clojure, реализующие функциональные возможности. В каждом есть свои недостатки и преимущества, тут надо выбирать.

В Scala плюс, это механизм акторов, как в Erlang-e, для адекватной работы с многопоточностью. Вот отрывок выступления тех. лида Twitter http://www.youtube.com/watch?feature=player_detailpage&v=ohHdZXnsNi8#t=250s где он говорит, как Scala и Сlojure вписалась в их структуру, и что саппорту удобно скачивать логи ошибок, т.к везде те же механизмы для JVM. Деплой тоже унифицированный.

Sigrlami
()
9 марта 2013 г.

Кто-нибудь пробовал связку Scala/Play?

http://www.magazon2.ru сделан на Scala/Play.

+ scala

- сейчас мало статей на русском яз.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.