You're right, it's not quite impossible. However, the idiomatic ways of doing things in Scala tend to be very bad for performance if you're in a tight loop. For example, if you have two arrays that you need to iterate through simultaneously, you need to zip them together. In order to regain the performance, you end up having to do something like the while loop or use recursion. This is similar to the problem of doing heavily numeric code in Clojure before release 1.3. You could get Java-like numeric performance out of Clojure, but you'd have to abandon doing it in any sort of ideal way.

One example where something was impossible in Scala is that to implement a Parcelable for Android. This requires the creation of a static field, which Scala doesn't allow. Now, I won't argue that an API that requires such a construct is good, but it might be necessary for your application. I believe Scala now contains special code in the compiler just to support this peculiarity in the Android API.

In your example of iterating through two arrays, the proper Scala idiom is (a1,a2).zipped.map((v1,v2) => ...). This avoids doing an actual zip which would have significant overhead. It also makes it easier to write the map as the map method on Tuple2.Zipped takes a function of two arguments so you don't have to deal with pulling values out of a tuple.

I would actually find the details of where Scala performance is poor to be very interesting. Most significant IMO would be whether they are real problems or people picking improper implementations. For example I'd like to be able to answer the following, would using a view have given them the performance they needed without producing ugly code?