However, for learning interesting and useful stuff, I'd probably point people more towards Haskell.
To me, scala feels like a language with headroom, to use audio parlance. It's easy to get started, since you can code in pretty conventional ways. It has sophisticated things to learn about that you can use to write more expressive code, but the key differentiator from Haskell, say, is that you don't need to know all these to get things done. With scala you can hit the ground running.
Haskell, Python, Ruby, and OCaml were created in 1990, 1991, 1995, and 1996, respectively. Literally decades of work have gone into building libraries for these languages, in everything from web protocols to cryptography to machine learning. Scala was released in 2003 (and Scala 2.0, released in 2006, was a complete rewrite). Yet despite being so young, having access to any Java library makes Scala instantly useful. The language team can focus on the core language, and any library you can imagine is just a Google search away.
To give two examples: Adding support for AMQP and XMPP to lift meant writing two thin wrappers over the equivalent Java libraries. You could use the Java libraries directly, but the wrappers take advantage of Scala's Actors, which are the best thing since sliced bread when it comes to concurrency.
The JVM is also the most ubiquitous deployment platform ever. Yes, maven is mysterious and I mostly don't understand how it works. But it works, and it gives me a WAR file, and deploying a WAR is as easy as dropping it into any webapp container.
Could Scala-the-language be prettier if it wasn't tied to the Java platform? Probably.
Would Scala-the-platform be viable today if it didn't have full access to Java-the-platform? Unlikely.
It's hard to overstate the importance of the JVM platform to growing a new language. For Scala, it's the difference between a language that is an academic curiosity and a language I can use to solve real problems now.
I'm sorry you were discouraged by maven. I've found maven to be a huge productivity boost, especially when compared to the alternatives. Though I'll admit it's mostly "black magic" to me. Half the time I don't know what exactly it's doing. But since it "just works", I find it really doesn't matter that much that I don't understand it.
Also, most of the "churn" is in new features. There are 6-12 production apps running off of lift's trunk, so check-in's very, very rarely break backwards compatibility. There is an effort to re-work the ORM layer and make it much, much more powerful (it'll be much more than just ORM). This work is proceeding cautiously though. There will be ample warning before the old ORM is deprecated and thrown out.
If you want to give lift a second chance, I'd encourage you to use the mailing list as a resource (liftweb@googlegroups.com). People are very friendly and generally very willing to answer questions.
If everything is working well, maven can be a huge productivity boost. I'm sure the decision to use maven was to make the learning curve smaller. But I get an uneasy feeling when maven is being used for every aspect of the project, including creating it, compiling it, running it, updating the libraries, deploying it, importing to eclipse, etc...
The best way to use maven is to set up a stable local repository, and be _careful_ when you update them. Archtypes can be upgraded server-side on the fly, and this can cause problems if you're not careful about versioning.
By default, however, people won't set up local copies of maven repositories. And despite the best intentions of liftweb.org, and ibiblio.org, neither organization has a vested interest in your project, and they suffer from downtime frequently. liftweb was down for over a day at one point. You couldn't create a blank project template, or update the dependencies. It's a risky dependency.
That isn't rhetorical.
That said, I don't mind languages like Haskell where imperative programming doesn't fit in well conceptually. It's just that I wouldn't use languages like that for everything.
Scala does a much better job of unifying object-oriented and functional programming than OCaml does. OCaml's OO-system feels tacked on; an afterthought rather than a careful consideration of the original design. In Scala, a function is an object and an object is a function. There are many ways in which the line between functional and object-oriented fades.
The C/Java/Python/Ruby school of syntax that Scala comes from is much more familiar to me than the ML school of syntax that OCaml comes from.
Scala doesn't have the distinction between "+" and "+.":
powerbook58:~ jeortiz$ ocaml
Objective Caml version 3.09.3
# 1 + 1;;
- : int = 2
# 1.0 + 1;;
This expression has type float but is here used with type int
# 1.0 +. 1;;
This expression has type int but is here used with type float
# 1.0 +. 1.0;;
- : float = 2.
That said, I don't want to come across as bashing on OCaml; I'm merely pointing out some differences. OCaml is a great language (that was a joy to learn) and for many applications it can be a better choice than Scala.
* important concepts such as f-bounded polymorphism, covariance, contravariance, implicit parameters and methods, etc.
* traits that solve the diamond problem with multiple inheritance
* functional programming concepts including monads
* advanced concurrency concepts via the actors library
* pattern matching via case classes and extractors
* that type inference can make you highly productive in a statically typed language
Could you state the case for scala, in terms that someone not familiar with it, could appreciate?
Oh really? Type declarations and the like are at most 10% of code. That means that eliminating the need to type them, which is what type inference does, can't decrease code size by more than 10%. It's unlikely that that 10% takes more than 10-15% of development time.
The fact that those are important concepts in Scala doesn't make them important concepts.
> traits that solve the diamond problem with multiple inheritance
There are lots of solutions to the diamond problem. The fact that scala uses traits doesn't make traits important.
> * pattern matching via case classes and extractors
Again, so what?
Scala is full of elegant mechanisms to solve problems that resulted from design choices. The elegance of those mechanisms or their importance to scala doesn't make them important. After all, one might reasonably have made different design decisions, making them irrelevant.
The claim was that scala is special. However, the argument doesn't support that claim. It's a list of "me-toos" and hyperbole.
For example, every language with multiple inheritance has some mechanism to deal with diamonds. Type inference is useful/interesting, but it doesn't result in "highly productive".