I was reading my preview of the Artima Scala book over the weekend when I had a sudden moment of clarity.

In Scala, generic types have by default non-variant subtyping. That is, with Queue defined as above, queues with different element types would never be in a subtype relation. However, you can demand co-variant subtyping of queues by changing the first line of the definition of class Queue as follows. class Queue[+T] { ... } Prefixing a formal type parameter with a + indicates that subtyping is co-variant in that parameter. Besides +, there is also a prefix - which indicates contra-variant subtyping. If Queue was defined class Queue[-T] { ... } then if T is a subtype of type S this would imply that Queue[S] is a subtype of Queue[T] (which in the case of queues would be rather surprising!).

Scala is a multi-paradigm language that many in the developer intelligentsia are annointing as the 'successor' to Java.

Its syntax is based on Java's, and it remains compatible enough that you can call existing Java code and libraries directly from Scala, just as you can expose Scala objects within Java code. However, it brings along an improved type system, first-class support for functional programming, an actor system that imitates Erlang, and so on. The cost of all this is the addition of a not-insignificant chunk of complexity to the language.

That's right.

Scala is to Java as C++ is to C.

Seeing as Java started off as the language that removed and simplified a lot of the stuff from C++ that developers tended to shoot themselves in the feet with, I find myself wondering more what language might bill itself as Scala's successor, and how it might distill the best parts of that language to a more manageable, coherent whole.

(The first smart-arse to answer "LISP" wins a swift kick in the nuts.)