Martin Odersky, the creator of Scala, on this Google Tech Talk (@13:54 min) says:

Pattern matching is the reverse of Object construction, that all it is...

I must say, the Functional Programming side of Scala is a whole new world to me, and the pattern matching mechanism a big a part of it, and I have the intention to deep dive all this.

David Pollak wrote a very detailed description of Scala SDK Actors on the Lift discussion list, some serious flaws are pointed out as a justification of why Lift has it's own Actor library:

• Lift creates/destroys an Actor for each Comet request. This rapid creation/destruction of Actors caused memory back-ups, and the existing Actor code seems to be oriented to long running Actors rather than Actors with Object-length lifespans.
• The FJ libraries used for Actor scheduling have problems on multi-core machines and are also a source of memory retention issues.
• Replacing the FJ libraries with a scheduler based on java.util.concurrent exposes race/deadlock conditions related to the fact that some parts of the Actor processing (e.g., testing mailbox items against partial functions while the Actor itself is synchronized)
• The Actors require external threads to function and it's not possible to create external threads in the Google App Engine (making Actor-based functionality including CometActors non-functioning in GAE apps)
• Actors are fragile when exceptions are thrown
• Actors have running and not running states (as compared with objects which can always respond to message sends). In practice, managing the running and not running states is as hard as managing memory in C.
• There are hidden actors associated with each thread which display the above fragility and state management issues
• And as a practical matter, I've got a couple of applications that are going into production over the next few weeks and cannot wait for the various fixes to make it into Scala 2.8 and the hacks and work-arounds that I've done to the 2.7.4 Actor libraries became too complex for my comfort.

Interesting to notice the authors worries about overcoming some limitations to run Lift on Google App Engine, what would certainly boost it's main adoption in a near future :)

Martin Odersky says on this interview that types can be really annoying for small scripts but for the other case, big systems (real production systems) the refactoring that it allows and the reliability of your code are a fair (or small) price to pay:

They are probably less important when programming in the small. Types can be in a spectrum from incredibly useful to extremely annoying. Typically the annoying parts are type definitions that are redundant, which require you to do a lot of (finger) typing. The useful parts are, of course, when types save you from errors, when types give you useful program documentation, when types act as a safety net for safe refactoring.

I could not agree more, if I'm doing a 50~100 lines script I'm probably not using a full IDE and the Java anonymous inner class full syntax will not be generated by my jEdit (or any other text editor), so a friendly idiom for closures are really a differential.

At the same time I'll not need to maintain this script for months or years, or might never read it again, hence the possibility of powerful automated refactoring (that for instance IntelliJ of Eclipse provide) are not a need, like they are and we already take them for granted on regular systems that we deploy to hundreds/thousands of users.

Automated refactorings are the open gates to the easy and encouraged evolution of software code, and statically declared types are their very foundation.

As I quoted Yakov here before: If you would like to add Java pyrotechnic new features, consider letting Java doing its fantastic job where it is and give life to your ideas in a new language, and better yet, a language with a compiler to java bytecode, that's what Scala folks did!

Scala is a statically typed, object-oriented programming language that blends imperative and functional programming styles. Scala is designed to integrate easily with applications that run on modern virtual machines, primarily the Java virtual machine (JVM). The main Scala compiler, scalac, generates Java class files that can be run on the JVM.

Scala was developed starting in 2003 by Martin Odersky's group at EPFL, Lausanne, Switzerland. Previously, Martin had been active in the Java field. He co-designed the first version of Java generics and was the original author of the current javac compiler. The work on Scala was motivated by the desire to overcome limitations imposed by backwards compatibility with Java. So Scala is not a superset of Java, but it retains seamless interoperability.

One reason you might want to use Scala is that it allows you to increase your productivity compared to Java while leveraging JVM execution speed, your existing investments in Java code, knowledge, and the vast array of APIs available for the JVM. It has the conciseness of a dynamic language like Ruby or Python, but it is statically typed, like Java. Another reason is that Scala comes with an Erlang-like Actors library that greatly simplifies concurrent programming, but runs on the JVM.

From First steps to Scala.