In Java könnte eine typische Implementierung folgendermaßen aussehen:

1. public static int sum(List<Integer> numbers) {
2. int result = 0;
3. for (int number: numbers) {
4. result += number;
5. }
6. return result;
7. }

Das können wir natürlich auch in Scala analog umsetzen:

1. def sum(numbers: List[Int]): Int = {
2. var result = 0
3. for (number <- numbers) {
4. result += number
5. }
6. result
7. }

Wie sieht nun eine rekursive Alternative aus?

1. def sum(numbers: List[Int]): Int = numbers match {
2. case Nil => 0
3. case x :: xs => x + sum(xs)
4. }

Zunächst fällt auf, dass diese Implementierung kürzer ist. Und wenn man sich erst einmal an die rekursive Denkweise gewöhnt hat, dann erkennt man schnell, dass dieser Weg auch einfacher zu verstehen ist. Denn "Die Summe über eine Liste ist das erste Element plus die Summe über den Rest" entspricht viel eher dem intuitiven Verständnis als "Nimm eine Speicherzelle, iteriere über alle Elemente und addiere diese zum aktuellen Wert der Speicherzelle".

Noch deutlicher wird der Vorteil der Rekursion bei den Fibonacci-Zahlen [2], denn diese sind ja rekursiv definiert:

1. fib(n) =
2. 0 für n = 0
3. 1 für n = 1
4. fib(n-2) + fib(n-1) für n > 1

Das geht noch besser!

Daher ist es entscheidend, dass uns der Compiler und die Ablaufumgebung so gut wie möglich mit Optimierungen [3] unterstützt. Besonders großes Optimierungspotenzial bieten Tail Recursions bzw. Endrekursionen [4], d. h. solche rekursiven Funktionen, deren letzte Aktion zur Ermittlung des Rückgabewerts der rekursive Aufruf ist. In diesem Fall kann der Compiler die Rekursion durch eine Iteration ersetzen, sodass der Stack kein Problem mehr darstellt; eine solche Optimierung wird Tail Call Optimization genannt.

Die Java Virtual Machine lässt für Scala leider nicht alle Spielarten von Tail Call Optimizations zu. Beispielsweise ist es nicht möglich, sich wechselseitig endrekursiv aufrufende Funktionen zu optimieren. Aber natürlich werden alle Funktionen optimiert, die sich selbst endrekursiv aufrufen.