> The only function I couldn't find was the cartesian
> product of two collections, which would be nice to have.

Cartesian product can be expressed by flatMap and map, but the easiest way is with a for expression:


for (x <- 1 to 10; y <- 1 to 10) yield (x, y)


The Scala compiler will translate this to


(1 to 10).flatMap(x => (1 to 10).map(y => (x, y)))


> 1) why the emphasis on immutable data structures? what are
> the benefits? aren't those slower than the mutable types?
You don't need to make defensive copies when passing them to methods (outside your control). This can save quite a lot of time in some circumstances.

> From a quick first look I had, it seems the new
> collections API offers a lot of collection types, I'd dare
> say almost all widely known collection types.
>
> Without being a Scala user and only knowing the very
> basics of the language, I'd like to ask:
>
> 1) why the emphasis on immutable data structures? what are
> the benefits? aren't those slower than the mutable types?

I assume you mean slower for writes. Theoretically there is an opportunity for the compiler to give a performance boost on reads for immutable collections.

As someone who is happy to see the emphasis on immutability, the benefits are safer and simpler code. I need not worry about whether successive reads will produce different results or whether the collection will change while I am iterating over it. This is especially the case when dealing with concurrency but not exclusively.

> 2) when a collection's type is a primitive, does
> autoboxing happen? for example, an Array[int] is actually
> an Array[Integer]?

Unlike Java, there is are no primitives in Scala but as I understand it, compiled Scala uses Java primitives. I've not taken the time to understand how this is done but it's pretty sexy.

> From a quick first look I had, it seems the new
> collections API offers a lot of collection types, I'd dare
> say almost all widely known collection types.
>
> Without being a Scala user and only knowing the very
> basics of the language, I'd like to ask:
>
> 1) why the emphasis on immutable data structures? what are
> the benefits? aren't those slower than the mutable types?
>
The library is symmetric wrt mutability. Every major type has mutable as well as immutable implementations. Immutable ones are available directly whereas mutable ones need an explicit qualification or import.

The reason for preferring immutable is that immutable is safer. So in the spirit of avoiding premature optimizations
we made immutable the default.

Immutable collections do have persistent implementations which keep the cost overhead fairly low, and which even give an advantage over mutable for small collections (an immutable set or map of up to 4 elements takes only a single object; compare to a mutable map backed by a hashtable).

> 2) when a collection's type is a primitive, does
> autoboxing happen? for example, an Array[int] is actually
> an Array[Integer]?

For general collections, yes. But for arrays, no. Scala arrays are represented exactly the same as Java arrays. There's a section on arrays in the collections document.

The next versions of Scala will specialize further collection types iso that primitive types need not be boxed. That's an ongoing process which was started with the availability of @specialized annotation in Scala 2.8.

> 1) why the emphasis on immutable data structures?

Parallel collections should be easier to implement with immutable structures.

http://www.scala-lang.org/node/7285