

Ask HN: Scala technology stack? - drKarl

I'm doing some research to define the technology stack I'll be using in my next project.<p>I have a Java background, but I'm interested in expanding my horizons and use the best tools available.<p>I've played with Groovy and Python, and they are nice, but I've also read about performance of these languages and there is ample margin for improvement.<p>Now I'm learning Scala, which I read is very fast regarding performance (comparable to Java), is very powerful due to its syntax and functional programming/object hybrid nature, and
is much more expressive than Java (scala code tends to be 1/3 than Java code).<p>But I need to decide other important tools.<p>For templating I'm fascinated by Haml and Sass used in the Ruby world, so I'd like to try Scalate with Scaml templates.<p>For ORM, I've found SQueryl which looks very promising, but I've also found others such as Scala-query, Querulous or Circumflex-ORM.<p>For build engine I'm looking at Gradle. I've read about SBT (Simple build tool for Scala) but Gradle looks more powerful.<p>For web framework I'm looking at the Java framework Play, which is Scala friendly, and brzy (which seems promising but according to the autor "As of right now, brzy is not ready for production use."). 
Also Circumflex Web Framework and Scalatra, inspired by Ruby-esque Sinatra, and many others listed in this thread
http://stackoverflow.com/questions/1488412/what-scala-web-frameworks-are-available.<p>I'm looking for a lightweight web framework easy to configure and setup, without XML configurations, fast and scalable. When I was playing with Groovy I was interested in Grails, for example.<p>So, a possible choice would be Play (or Scalatra) framework, with Scalate Scaml templates, Squeryl and Gradle. Any suggestions or comments on frameworks/tools for scala?
======
Uchikoma
I use Lift. There could be better frameworks, Lift looks terribly complicated
and verbose, but it's fast and works.

I'm not into ORMs, but use the Lift ORM to get started before writing JSON to
NoSQL storages.

IDE: Intellij with the Scala plugin.

I will possibly use Mustache templating via Scalate in Lift instead of the
Lift version, as Mustache templates can be reused in the web frontend in
Javascript.

SBT with ~test-quick and Specs is fantastic for TDD.

I've played with Play alot, it's nice but the default Groovy templating is
slow as hell and I'm not sure their usage of exceptions for work flow does
scale - from my operations experience I think it won't (perhaps this changed
in the last 5 months).

~~~
kingcub
We used lift, we're in the process of ripping it out and replacing it with
something else, anything else really. When I last checked a few month's ago,
Lift's documentation is terrible given it's complexity. A project that is as
large as Lift cannot be learned by scanning the source code and the number of
examples out there to do something really custom is lacking. Tons of it's
source files have only the slightest smidgen of Scaladoc if any at all.

Also anything that actually is documented is probably deprecated or about to
be usurped by another feature. No classes should be added to lift without
proper documentation added first. Yes it's open source, yes no one wants to
write documentation at the end of the day it hurts the project however. I
don't want one on one support or having to write to mailing lists I want a
good explanation of what is going on top to bottom.

However I hear over and over it has worked wonders for other people, so YMMV.
It's certainly not the only way to make a Webserver in Scala it just has the
benefit of being one of the first big Scala projects, and it has used that
time to bloat out and grab as many features as it can without documenting them
properly.

~~~
gtani
books on Lift 2

<http://manning.com/perrett>

(Manning's always running some promo codes, so ~$20 for MEAP and final PDF
book)

<http://simply.liftweb.net/Simply_Lift.pdf>

~~~
kingcub
While I really hope these develop into good resources, The first one isn't
out. The second one is not remotely usable by itself at the moment. Most of
the chapters are empty. There is a smattering of code that revolve around some
very basic things can be found in other Lift books (which are now outdated).
The 4th longest chapter (ch 15) is a wall of text & self promotion that goes
on about how Scalable/Better Lift is than other frameworks.[1]

BTW Here is another book, that is, to my knowledge, the most complete free
reference available for Lift: <http://groups.google.com/group/the-lift-
book?pli=1>

Here is a [link]([http://main.scala-
tools.org/mvnsites/liftweb-2.1/framework/s...](http://main.scala-
tools.org/mvnsites/liftweb-2.1/framework/scaladocs/index.html)) to the Lift
Scaladocs. Most methods do not have any descriptions, several classes don't
either. This forces digging through source code / searching and asking
question on the mailing list to figure out how Lift wants you to do something.

Ultimately, with how fast Lift moves it's really hard to have any faith in any
book keeping up.

1: Even when using Lift’s session-afﬁnity dependent features, Lift
applications have higher performance, identical availability, identical
scalability, better security, and better user experience than applications
written with web frameworks such as Ruby on Rails, Struts, and GWT.

------
rb2k_
> but I've also read about performance of these languages and there is ample
> margin for improvement.

Do you really need "number crunching" performance?

Most of the time, it's I/O waits anyway

~~~
Uchikoma
"Most of the time, it's I/O waits anyway"

I believed this for years too. But after some years in production I do no
longer believe this. If you cache a lot HTML or data, then I/O is no longer an
issue and the load of your app servers is CPU bound (mostly rendering, I was
suprised about this).

Faster language => less app servers => less money spent.

------
mgkimsal
groovy++ might be worth a look if performance is a consideration.
<http://code.google.com/p/groovypptest/> might be more recent at
<https://github.com/alextkachman/groovypp> \- not sure.

Each version of core groovy gets a bit faster at certain things, but the
dynamicness of it will probably mean it'll always be _somewhat_ slower than
pure java. You need to weigh the benefits - for me, those benefits are faster
app dev time (via Grails) vs the language speed. _Most_ of the stuff I'm doing
is db reads and writes, so the db itself is often a speed bottleneck,
regardless of what language I'm using.

~~~
drKarl
Didn't know about Groovy++. I'll read more about it!! Is it that faster than
regular Groovy??

~~~
mgkimsal
For some tasks, yes.

Benchmarks:
[http://www.google.com/buzz/alex.tkachman/2qog71JrDvU/Latest-...](http://www.google.com/buzz/alex.tkachman/2qog71JrDvU/Latest-
Groovy-Benchmarks-against-Java-It-seems)

Graph:
[http://www.google.com/buzz/106045618354056753098/YPrgoMfGL8z...](http://www.google.com/buzz/106045618354056753098/YPrgoMfGL8z/Java-
vs-Groovy-benchmarks)

Well, this is Groovy++ vs regular Java, not against Groovy.

[http://www.indicthreads.com/7355/what-is-groovy-how-does-
it-...](http://www.indicthreads.com/7355/what-is-groovy-how-does-it-compare-
with-java-and-groovy/) has a bit more comparison which might be useful.

------
clyfe
The only reason I would do web-dev in Scala wold be LiftWeb aka speedy comet-
style apps, that is it's strongest point, otherwise I'd choose
rails/django/whatever.

As each language seems to have a Sinatra clone, Scala's is Scalatra - for when
you want to do something easy and elegantly-ish or something small as in "do
this logic in a elegant fashion but don't hurt my brain". If you're stuck in
Scala and LiftWeb is too much, choose the Scalatra's easy route.

~~~
mark_l_watson
Out of curiosity, I just checked out Scalatra: looks like a good framework for
simple RESTful web apps and to implement web services. Thanks for the
reference.

------
ilmare
I'm surprised no one mentioned akka - <http://akkasource.org>

------
alnayyir
I had a good time with Play, but I can't say that I "battle tested" it. (I
work with Django in my professional life.)

Tbqh, I'm wrangling with my preference for Play/Django-esque frameworks
against the design ethic behind Compojure and my love for Clojure. I haven't
grokked the Clojure approach to web development.

For Scala, I'd say you've already suggested a pretty good template towards the
end of your post.

I'm less certain for my own part for how to approach Clojure.

I'd strongly consider what rb2k_ is saying about performance as well. Your
data processing should be decoupled from your frontend servers regardless of
what you're doing.

