So...don't use data structures that are not thread-safe in threaded environments? Wrap it with Collections.synchronizedCollection. Or make copies, if you prefer.
For the very small price of a little bit of garbage...
What small price? If I have millions of things stored in an immutable data structure, do I not have to copy the entire structure (or at least some portion of it) when I want to modify anything inside of it?
hang on...
wait a sec...
one more sec, someone's doing something...
now? no, not yet, wait...
how about... NOW! synchronizedCollection, the global lock for Java's mutable datatypes.
Here's the fundamental difference between Java and Scala: if I say, in Scala, val people = List[String]("quacker", "mark242") then by default people is an immutable list. I don't have to do anything special. In Java, either I'm suddenly using the Guava libraries to get something similiar (but not the same), or I'm doing all kinds of funky dances around list iterators, or I'm using Arrays.copyOf, or what have you. In any case, you have all of this extraneous code, when it isn't necessary.
Quick: give me a list comprehension method in Java that takes a list of Strings and returns that list, filtered, of Strings that are only five characters or longer. Make it null-safe and thread-safe. This isn't difficult-- you're thinking about 6-7 lines of Java code in your head, right? Null check, synchronized, new ArrayList, for(s in sList), that kind of thing, right?
In Scala, it's this. Some would argue you don't even need a separate method.
def getFiveCharacters(s: List[String]) = s.filter(_.length >= 5)
Dear god, man, what are you doing wrong in your Java code? This is the exact scenario where you want an immutable list, otherwise you'll be running synchronized code and precisely one core of your CPU will be glowing red like lava, while your other CPU cores sit idle.
I just did this in the scala repl:
(0 to 1000000).toList.par.filter(_ % 100 == 0)
> In Scala, it's this. Some would argue you don't even need a separate method.
It seems a bit unfair to force null checks on the Java code and then present a Scala alternative that throws NPE in two different places.
Option(s).getOrElse(List[String]()).filter(str => Option(str).fold(false)(_.length > 5)) def foo(s: List[String]): List[String] = s match { case l: List[String] => l.filter(_ match { case str: String => str.length > 5; case _ => false}); case _ => List[String]()}
You're right that this is primarily a concern if the Scala dev wants to talk to Java. However, if the Scala dev does not want to talk to Java, perhaps a statically typed FP language with an HM type system would be a better fit.
Depends on the nature of the modification; to choose the right immutable data structure, you want to choose the one that has the best behavior under your expected use.
Pushing something on to the head of an immutable list doesn't require a copy, the new list has the new object as the head and the old list (not a copy) as the tail. Similarly, removing the head doesn't require a copy, it just returns the tail of the existing list. If you want to replace something in the middle of the list, you'll need to copy everything closer to the head than the modified item.
Different immutable collections have different "cheap" access patterns.