Personally, Scala's multiple ways of solving the same problem is a major concern to me, it's language with bipolar disorder.
For example.
Iterating through a container.
1. list.foreach(anonmyous function)
2. for (i <= list)
3. while loop.
Throw in both scala.collections.immutable/mutable, and java.util collections.
Scala wants you to use functional programming styles to solve problems. Thus do everything list.foreach() way. But it's backed on top of jvm which isn't the most functional programming friendly virtual machine. All the functional programming end up being syntaxical sugar and a burden if you want any performance at all. So for performance you are forced to write things the java way, which terrible because the language is designed to lean towards solving problems functionally, so you shoot yourself in the foot either way.
This is a familiar pattern in any language, not just scala. If you doubt me just check out the source code for memcpy.c. Witness the loop unrolling, the byte fiddling the register level manipulations and the several hundreds, if not thousands, of lines of code required to implement the function. Wouldn't a simple for loop be enough?
High performance code anywhere will force you to drop down to the lowest level possible and work from there. The rationale of functional programming is that you can work largely at a high level and drop down to low level techniques in the 1-10% of the code that really matter for performance. One measure of the success of Scala is that it is being benchmarked against Java unlike Python/Ruby/Groovy etc. It is a reasonably high level language, yet the benchmark comparisons are always against Java. If necessary the performance required can be had by writing your while loops to avoid the object allocation required to build a closure. I don't see this as a disadvantage at all, as I can use the high level techniques in the remaining 90% of the code.
But Scala doesn't let that happen nicely does it? It doesn't go down without a bit of fighting. Scala's quirks make writing lower level code more difficult. Interfacing with Java collections feels just awkward.
EDIT: Quoting, as OP updated his comment as I responded.
>But Scala doesn't let that happen nicely does it? Interfacing with Java collections feels just awkward.
Awkward? The Scala interface is better than the native Java interface itself. I can perform a map, reduce, filter on the Java array in Scala, something that is impossible in Java. How can it be more awkward than Java itself?
What I'm saying is, if you decided to say, use a Java HashMap in one part of your code for performance reasons. You'll have to live with that with the rest of your code. Half of the classes in the scala library doesn't like it because it doesn't implement the required traits and as far as I can tell there is no nice way of converting between collections.
Scala doesn't provide a built in for your specific case but
import scala.collection.breakOut
and you can convert mutable Java hash map to immutable scala map
b = a.asScala.map(p => p)(breakOut)
where b : scala.collection.immutable.HashMap[java.lang.String,Int]
and a : java.util.HashMap[String,Int]
Not too bad at all. Moreover, why would you want to convert a Java map to Scala if you specifically used the Java map to improve performance? How is this any worse than coding in Java itself?
For example. Iterating through a container.
1. list.foreach(anonmyous function) 2. for (i <= list) 3. while loop.
Throw in both scala.collections.immutable/mutable, and java.util collections.
Scala wants you to use functional programming styles to solve problems. Thus do everything list.foreach() way. But it's backed on top of jvm which isn't the most functional programming friendly virtual machine. All the functional programming end up being syntaxical sugar and a burden if you want any performance at all. So for performance you are forced to write things the java way, which terrible because the language is designed to lean towards solving problems functionally, so you shoot yourself in the foot either way.