5 ms·

Ask HN: Scala technology stack?

17 points by drKarl 16y ago

I'm doing some research to define the technology stack I'll be using in my next project. I have a Java background, but I'm interested in expanding my horizons and use the best tools available. 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. 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). But I need to decide other important tools. For templating I'm fascinated by Haml and Sass used in the Ruby world, so I'd like to try Scalate with Scaml templates. For ORM, I've found SQueryl which looks very promising, but I've also found others such as Scala-query, Querulous or Circumflex-ORM. For build engine I'm looking at Gradle. I've read about SBT (Simple build tool for Scala) but Gradle looks more powerful. 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. 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. 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?

alnayyir 16y ago
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.
rb2k_ 16y ago
> 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 16y ago
  "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.
Uchikoma 16y ago
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).
- alnayyir 16y ago
  >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). Fixating on the way wrong things here. Cf. rb2k_
  - Uchikoma 16y ago
    Care to elaborate?
    - alnayyir 16y ago
      All it takes is for 5% of your requests to require a uncached database fetch for your concurrency model and I/O handling to be more important than rendering or other CPU bound activities in the process of serving a request on the frontend. Wrong priorities in the absence of circumstantial profiling.
      - Uchikoma 16y ago
        "Wrong priorities in the absence of circumstantial profiling." Puh, then I'm glad we extensivly profiled our app.
      - Uchikoma 16y ago
mgkimsal 16y ago
groovy++ might be worth a look if performance is a consideration. http://code.google.com/p/groovypptest/ http://code.google.com/p/groovypptest/ might be more recent at https://github.com/alextkachman/groovypp 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 16y ago
  Didn't know about Groovy++. I'll read more about it!! Is it that faster than regular Groovy??
  - mgkimsal 16y ago
    For some tasks, yes. Benchmarks: http://www.google.com/buzz/alex.tkachman/2qog71JrDvU/Latest-Groovy-Benchmarks-against-Java-It-seems http://www.google.com/buzz/alex.tkachman/2qog71JrDvU/Latest-... Graph: http://www.google.com/buzz/106045618354056753098/YPrgoMfGL8z/Java-vs-Groovy-benchmarks http://www.google.com/buzz/106045618354056753098/YPrgoMfGL8z... Well, this is Groovy++ vs regular Java, not against Groovy. http://www.indicthreads.com/7355/what-is-groovy-how-does-it-compare-with-java-and-groovy/ http://www.indicthreads.com/7355/what-is-groovy-how-does-it-... has a bit more comparison which might be useful.
clyfe 16y ago
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 16y ago
  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 16y ago
I'm surprised no one mentioned akka - http://akkasource.org http://akkasource.org

kingcub 16y ago

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 16y ago
books on Lift 2 http://manning.com/perrett 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 http://simply.liftweb.net/Simply_Lift.pdf
- kingcub 16y ago
  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 http://groups.google.com/group/the-lift-book?pli=1 Here is a [link](http://main.scala-tools.org/mvnsites/liftweb-2.1/framework/scaladocs/index.html http://main.scala-tools.org/mvnsites/liftweb-2.1/framework/s...) 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.