What are your experiences developing in Scala/Lift?

Question

I heard a lot of good things about Scala and the Lift Web framework recently, especially from Foursquare\'s guys hence, I might use this technology in my next projects.

Answer 1

1. I'm currently doing most of my things in Scala right now. (I should mention that I think that Scala is the best thing since the invention of the wheel some time ago. :-D )

   In my humble opinion it is the only language which truly allows people to choose the best approach to a task without some unnecessary divide between (more) object-oriented and (more) functional approaches.

   Looking at the languages which claimed something like this before, I can basically see two competing language design camps:

   • The ones from the object-oriented side which saw that functional programming gained some traction lately and thought "Well, we don't really understand that functional thingie, but let's add some fancy syntactical sugar to our language, so we can claim it is functional too!" (examples: Java, Python)

   • Then the ones from the functional side, who thought "Well, our functional approach is far superior to anything else and that object-oriented nonsense is annoying, but let's put some additional keywords into our language, that will make our language escape academia for sure!" (examples: F#, OCaml)

   Scala's designers unified many approaches coming from both sides and created some well-designed language, which is - in my humble opinion - the biggest difference to other languages, which decided to take the "Frankenstein" approach to programming language design.

2. Having done only smaller things with Lift yet and only superficial experience with Rails and Django, I have to admit that most of the time when I wondered why something in Lift worked differently from what I expected, this was due to the fact that my expectations were flawed and Lift's approach superior.

   Lift is certainly no "easy introduction to Scala" but learning how Lift works was almost as rewarding as learning Scala before it.

   The ability to have a "clean" view without any logic in it is a great improvement to other frameworks which claimed the same, but fell short of it. Scala's XML literal support makes it possible to verify the well-formedness of your response: The compiler will prove at compile time that you only emit well-formed XML to a client.

3. Lift is viable technology and at the moment the only real approach if you want to build web applications which look, feel and behave like "real" desktop applications without writing insane amounts of code yourself.

Answer 2

I'm working on my second Lift app at the moment - it's very strongly in Lift's sweet spot - very realtime, lots of concurrency.

The first one we wimped out after a few days of wrestling with the DB layer (it's better now, I am led to believe), and went to Play/Scala instead. That maximized the existing knowledge of our team and made it possible to make deadline. But the hot code reloading pretty much stopped happening once our project got moderately large (kept running out of PermGen - it's an ongoing problem with Scala compilation pretty much anywhere), and the manual juggling of things like method call parameters and location security in different places in the website got quite cumbersome. We were glad when it was done - in the same way as I tended to find Rails 1, the speed increases shrank as the project size increased, and by the end it was every bit as tedious and error-prone as working in a Velocity/Spring/XML++ whatever).

This time we've been committed to just working out how Lift does what it does, and the right ways to do things. This has meant a lot of casual browsing through the mailing list (discussions that are several versions old are often still relevant), and most importantly a new ethos for the team. It's been necessary to internalize very strongly the motto:

"This is feeling hard and repetitive. I bet they made an easier way to do this."

So far Lift has never disappointed us. I'm not talking, by the way, about stuff like the Sitemap and list concatenation syntax - you MUST have a pretty good handle on functional Scala, or you just won't be able to read the source code or even configure your app.

That said it's not crazy IO monads or anything, just some common idioms that you'd pick up in a few weeks of Scala anyway.

The biggest problem for us has been a slow compile cycle. It takes about 20 seconds to jetty:run our project, which is a different feeling to Play which (when it's working) hot compiles all your stuff. On the other hand, we actually timed that the other day when one of our devs complained about it, and it worked out that although Play technically hot compiled it, the page still took 12 seconds to load in Dev mode. So there's not a huge loss, it just feels a bit slow to have to hop out to the command line.

Lift lets you do a great deal, and there are many places in our app where (because it's available), we've said "Yeah, we really WOULD prefer to have that live updated immediately to all viewers of that page, instead of them discovering later that they're out of date (think of all the times you've posted simultaneously to someone on SO, with the same answer). COMET is everywhere, it turns out - it's not a specialist use case, it's the way things should work. And Lift makes it really easy.

We also love the strong, programatically configurable, security model - once we switched our mindsets to "We have to whitelist every location, and specify the necessary entrance conditions", we never saw another session problem - you know, those ones where you assumed that the user would have traversed a certain path, and thus would know a whole bunch of parameters? Like, a valid username, and an area of interest or whatever? (I'm being intentionally vague). That can be one of the awkward things about a stateful framework, that you're going to want to have usable state when the user hits a page, instead of (for instance) just demanding that all the state gets carried along at each request.

My takeaway from this renewed shot at Lift:

It's worth it. Not just to build the app that you're trying to build, but to build the app that you didn't know you needed.

There's a lot of head scratching, but not a lot of code. And when it works it really works. It's fast, and clean, and for all of the miracles that it's working between the browser and the server, I've never yet seen it get confused.

Answer 3

I'm developing enterprise financial application in Lift for more than 6 months and I was JAVA programmer former. I have noticed a few points, which could help you:

1. I write noticeable less lines of codes (great example)

2. Around Lift there is strong a very kindly community. They always try to provide a substantive answer. I haven't any bad experience. Even they are open for new suggestions for new features in Lift. They approved two of my suggestions!

3. New stable minor version of Lift is announced about every 6 - 8 weeks. New milestone is regular every two weeks.

4. Lift is great framework for web applications. You can read about seven main features of Lift.

5. Lift default ORM module - Mapper is not for big and advanced database models with lot of foreign keys and constraints. We had to use Squeryl.

I can't imagine that I have to return to JAVA code now. But my little advice is to try to code some simple application and you will see.