Mutable vs Immutable Collections

Analogy categoryAnalogies

Two Collection Hierarchies

Scala ships two parallel collection hierarchies: scala.collection.immutable and scala.collection.mutable. When you write an unqualified name like List, Map, Set, or Vector in Scala code, it resolves to the immutable version by default, thanks to aliases defined in Predef and the scala package object. To use the mutable counterpart, you must explicitly import it, typically as scala.collection.mutable.Map or by importing the mutable package and qualifying usage as mutable.Map, mutable.Set, and so on.

🏏

Cricket analogy: Scala's two collection hierarchies are like having both a printed final scorecard (immutable) and a live scoring app during the match (mutable) - when a commentator just says "the scorecard" without qualifying it, everyone assumes the official printed version, the way unqualified List defaults to immutable.

Why Immutability by Default

Scala favors immutability by default for several concrete reasons. Immutable collections are inherently safe to share across threads without locks or synchronization, since no thread can ever observe a partially-updated or corrupted state - the collection simply never changes after it's built. This safety doesn't come at the cost of copying everything on every change: persistent immutable data structures use structural sharing, reusing the unchanged parts of the old version rather than deep-copying the whole thing, so producing a "modified" version is efficient. Immutability also supports referential transparency, making code easier to reason about and test since a given collection value can never surprise you by changing underneath a reference you're holding.

🏏

Cricket analogy: An immutable scorecard can be photocopied and handed to a hundred commentators simultaneously without anyone worrying it'll change underneath them - exactly why immutable collections are safe to share across threads without locks - while structural sharing means a revised scorecard reuses the untouched overs rather than rewriting the whole innings.

scala

import scala.collection.mutable

// Immutable: prepending conceptually produces a "new" list via structural sharing
val original: List[Int] = List(1, 2, 3)
val extended: List[Int] = 0 :: original   // original is untouched

// Mutable: same buffer grows in place
val buffer: mutable.ListBuffer[Int] = mutable.ListBuffer(1, 2, 3)
buffer += 4          // buffer now holds 1, 2, 3, 4 - no new object needed
val asList: List[Int] = buffer.toList

When to Reach for Mutable Collections

Mutable collections still have their place, particularly for performance-sensitive, tightly scoped code. Building up a sequence with repeated in-place appends using a mutable ArrayBuffer or ListBuffer avoids the allocation overhead of repeatedly creating new immutable collections one element at a time, and once the building is done, converting to an immutable result (toList, toVector) hands back a safe value to the rest of the program. The tradeoff is that mutable collections are not thread-safe by default: concurrent reads and writes from multiple threads can corrupt internal state or produce inconsistent results without explicit synchronization or a concurrent-safe alternative.

🏏

Cricket analogy: Building up a long list of ball-by-ball deliveries during a live over is like using a mutable ArrayBuffer - a scorer scribbling each ball directly onto a working sheet is far faster than rewriting the whole scorecard from scratch after every delivery, then converting the finished over to the official immutable record.

Mutable collections such as scala.collection.mutable.HashMap are not thread-safe by default. Concurrent reads and writes from multiple threads can corrupt internal state or produce inconsistent results; use synchronization, java.util.concurrent collections, or immutable collections shared via safe publication instead.

Converting Between Mutable and Immutable

Converting between the two hierarchies is straightforward: toList, toVector, and toBuffer convert a collection to the corresponding target type, and mutable builders like ListBuffer expose a result() method that hands back the finished immutable List. Internally, Scala's collections library uses the Builder pattern to perform these conversions efficiently in a single pass rather than element-by-element rebuilding, which is why calling .toList on a large ListBuffer is fast even though the destination type is completely different from the source.

🏏

Cricket analogy: Calling .result() on a ListBuffer after scribbling every ball of an over is like the scorer formally transcribing the working sheet into the official printed scorecard - the moment of conversion where the fast, mutable scratch pad becomes the trusted, immutable record.

ListBuffer append (+=) is O(1) amortized, unlike immutable List's O(n) :+. A common idiom is to accumulate results in a ListBuffer inside a loop, then call .toList once at the end to hand back an immutable List to the rest of your program.

Scala has two parallel collection hierarchies: scala.collection.immutable and scala.collection.mutable.
Unqualified names like List, Map, Set, and Vector resolve to the immutable versions by default via Predef.
Immutable collections are safe to share across threads without synchronization since they can never change after creation.
Structural sharing lets immutable collections reuse unchanged parts of the old version instead of copying everything.
Mutable collections like ArrayBuffer and ListBuffer are useful for performance-sensitive, tightly scoped local building of a sequence.
Mutable collections are not thread-safe by default and require external synchronization for concurrent access.
Methods like toList, toVector, and toBuffer convert between mutable and immutable representations.