(1) when speaking of dynamic typing versus static typing, it's not a black and white issue - it's actually full of color, but if it helps, you can think of it a

(1) when speaking of dynamic typing versus static typing, it's not a black and white issue - it's actually full of color, but if it helps, you can think of it as an axis where languages are the dots. Clojure is a dynamic language, but Ruby is more dynamic than Clojure, hence the machinery for running on the JVM is more complicated, which is why Clojure has better performance. Java is considered a static language, but because it is able of runtime introspection, runtime code generation and runtime dispatch, it is much, much more dynamic than a language like Haskell - which for the moment is the most static language out of all languages known to the mainstream. The issue of dynamic versus static is also not an issue of specifying types. In fact it has nothing to do with that. The real difference comes from what the compiler does at compile-time. By definition compilers using static typing will reject pieces of code that are correct if it cannot prove that the types used support the operations you say they support. With dynamic typing on the other hand you can basically make shit up and have it executed and fail at runtime instead of compile-time ... but where the boundaries lie between compile-time and runtime differs from language to language, a language being considered either static or dynamic depending on which side the balance is inclining ... and btw, ironically languages like Java are somewhere in the middle. I'm seeing programmers making a confusion between duck-typing and structural-typing or type-inferencing - like all the time, even though these concepts are fundamentally different, which shows unfamiliarity with either one or the other, but mostly with duck-typing, as duck-typing is really NOT about the lack of manifest-typing, which is just a side-effect. (2) Play v2 is not a language. I personally don't like it, as I don't like big frameworks, being more the kind of person that prefers smaller libraries that compose well. But Play v2 brings with it some really cool tools - statically type-safe templates, Iteratees for dealing with Comet/WebSockets, etc... if you evaluate Play v2 for building simple apps, like freaking blogs and such, some of the abstractions may seem over the top, but those abstractions are there to help you with other things you may need, as Play's philosophy is to be a "scalable" framework, while still being easy to use, just like Scala is a scalable language. The amount of pain you have to endure if you want to deal with Comet/Websockets in popular Ruby/Python frameworks is really breathtaking, while Play makes all of that easy and natural. Play v2 is more immature than Play v1, but it has better foundations and is just getting started. Play v1 wasn't going anywhere the way it was and sometimes major architectural changes are needed, even though the spirit remains the same - Rails 3 is also architecturally different from Rails 2 and 1, as the needs of web developers evolve and many companies haven't migrated. > unless you've checked into other languages first, like Ruby, Python, Haskell, Go, Clojure I second that argument. You should pick languages that are more suitable to personal style and more optimized for the problems you work on - however you have to be careful about it, as the metrics commonly used (e.g. beauty of syntax) are not so important as the resulting artifacts and also, language choice may be important, but is not as important as everything else (tools, libraries, ecosystem, community, etc...). Also, mentioning particular languages as having priority over Scala is weird. I have problems believing that you learned all of those languages you mention. If you specified 2, maybe 3, then I'd believe you, but why give advice for preferring languages you don't know? In particular, if you like Ruby and Python, you simply cannot mention Haskell in that same sentence as Haskell is everything that Ruby and Python aren't. And if you like Haskell, then placing Ruby and Python in that same sentence is some kind of abomination.