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

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

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

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

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

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

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

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

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

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

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

Плюсы:

- двойное API;

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

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

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

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

Минусы:

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

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

+/-:

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

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

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

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

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

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

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

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

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

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

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

дикий синтаксис

тебя обманули.

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

тебе показалось.

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

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

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

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))))
  }

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А чего тут непонятного-то? :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К сожалению. Я только могу предложить третью альтернативу 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. Деплой тоже унифицированный.

http://blakesmith.me/2012/05/15/understanding-clojure-concurrency-part-1.html http://blakesmith.me/2012/05/25/understanding-clojure-concurrency-part-2.html

Про многопоточность в Clojure, если вдруг решите глубже копнуть, свежий совсем материал.

www.magazon2.ru

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

Много ест памяти.

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

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

+ scala

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