What is the difference between a var and val definition in Scala?


What is the difference between a var and val definition in Scala and why does the language need both? Why would you choose a val over a var and vice versa?


  • Loved this question as I wondered the same thing.

    Dec 17, 2020 at 19:57


As so many others have said, the object assigned to a val cannot be replaced, and the object assigned to a var can. However, said object can have its internal state modified. For example:

class A(n: Int) {
  var value = n

class B(n: Int) {
  val value = new A(n)

object Test {
  def main(args: Array[String]) {
    val x = new B(5)
    x = new B(6) // Doesn't work, because I can't replace the object created on the line above with this new one.
    x.value = new A(6) // Doesn't work, because I can't replace the object assigned to B.value for a new one.
    x.value.value = 6 // Works, because A.value can receive a new object.

So, even though we can’t change the object assigned to x, we could change the state of that object. At the root of it, however, there was a var.

Now, immutability is a good thing for many reasons. First, if an object doesn’t change internal state, you don’t have to worry if some other part of your code is changing it. For example:

x = new B(0)
if (x.value.value == 0)
  println("f didn't do anything to x")
  println("f did something to x")

This becomes particularly important with multithreaded systems. In a multithreaded system, the following can happen:

x = new B(1)
if (x.value.value == 1) {
  print(x.value.value) // Can be different than 1!

If you use val exclusively, and only use immutable data structures (that is, avoid arrays, everything in scala.collection.mutable, etc.), you can rest assured this won’t happen. That is, unless there’s some code, perhaps even a framework, doing reflection tricks — reflection can change “immutable” values, unfortunately.

That’s one reason, but there is another reason for it. When you use var, you can be tempted into reusing the same var for multiple purposes. This has some problems:

  • It will be more difficult for people reading the code to know what is the value of a variable in a certain part of the code.
  • You may forget to re-initialize the variable in some code path, and end up passing wrong values downstream in the code.

Simply put, using val is safer and leads to more readable code.

We can, then, go the other direction. If val is that better, why have var at all? Well, some languages did take that route, but there are situations in which mutability improves performance, a lot.

For example, take an immutable Queue. When you either enqueue or dequeue things in it, you get a new Queue object. How then, would you go about processing all items in it?

I’ll go through that with an example. Let’s say you have a queue of digits, and you want to compose a number out of them. For example, if I have a queue with 2, 1, 3, in that order, I want to get back the number 213. Let’s first solve it with a mutable.Queue:

def toNum(q: scala.collection.mutable.Queue[Int]) = {
  var num = 0
  while (!q.isEmpty) {
    num *= 10
    num += q.dequeue

This code is fast and easy to understand. Its main drawback is that the queue that is passed is modified by toNum, so you have to make a copy of it beforehand. That’s the kind of object management that immutability makes you free from.

Now, let’s covert it to an immutable.Queue:

def toNum(q: scala.collection.immutable.Queue[Int]) = {
  def recurse(qr: scala.collection.immutable.Queue[Int], num: Int): Int = {
    if (qr.isEmpty)
    else {
      val (digit, newQ) = qr.dequeue
      recurse(newQ, num * 10 + digit)
  recurse(q, 0)

Because I can’t reuse some variable to keep track of my num, like in the previous example, I need to resort to recursion. In this case, it is a tail-recursion, which has pretty good performance. But that is not always the case: sometimes there is just no good (readable, simple) tail recursion solution.

Note, however, that I can rewrite that code to use an immutable.Queue and a var at the same time! For example:

def toNum(q: scala.collection.immutable.Queue[Int]) = {
  var qr = q
  var num = 0
  while (!qr.isEmpty) {
    val (digit, newQ) = qr.dequeue
    num *= 10
    num += digit
    qr = newQ

This code is still efficient, does not require recursion, and you don’t need to worry whether you have to make a copy of your queue or not before calling toNum. Naturally, I avoided reusing variables for other purposes, and no code outside this function sees them, so I don’t need to worry about their values changing from one line to the next — except when I explicitly do so.

Scala opted to let the programmer do that, if the programmer deemed it to be the best solution. Other languages have chosen to make such code difficult. The price Scala (and any language with widespread mutability) pays is that the compiler doesn’t have as much leeway in optimizing the code as it could otherwise. Java’s answer to that is optimizing the code based on the run-time profile. We could go on and on about pros and cons to each side.

Personally, I think Scala strikes the right balance, for now. It is not perfect, by far. I think both Clojure and Haskell have very interesting notions not adopted by Scala, but Scala has its own strengths as well. We’ll see what comes up on the future.


  • A little late, but… Does var qr = q make a copy of q?

    – user445107

    Jan 14, 2013 at 13:43

  • 7

    @davips It doesn’t make a copy of the object referenced by q. It does make a copy — on the stack, not the heap — of the reference to that object. As for performance, you’ll have to be more clear about what “it” you are speaking of.

    Jan 14, 2013 at 15:08

  • Ok, with your help and some info ((x::xs).drop(1) is exactly xs, not a “copy” of xs) from here link I could understand. tnx!

    – user445107

    Jan 15, 2013 at 22:20

  • “This code is still efficient” – is it? Since qr is an immutable queue, every time the expression qr.dequeue is called it makes a new Queue (see <…).

    – Owen

    Apr 1, 2019 at 6:25

  • @Owen Yes, but notice that it is a shallow object. The code is still O(n) whether mutable, if you copy the queue, or immutable.

    Apr 1, 2019 at 17:57


val is final, that is, cannot be set. Think final in java.


  • 3

    But if I understand correctly (not a Scala expert), val variables are immutable, but the objects they reference don’t have to be. According to the link Stefan posted: “Here names reference cannot be changed to point to a different Array, but the array itself can be modified. In other words the contents/elements of the array can be modified.” So it is like how final works in Java.

    Nov 24, 2009 at 17:04

  • 3

    Exactly why I posted it as is. I can call += on a mutabled hashmap defined as a val just fine-I believe its exactly how final works in java

    Nov 24, 2009 at 17:10

  • Ack, I thought the built-in scala types could do better than simply allowing re-assignment. I need to fact-check.

    Nov 24, 2009 at 17:19

  • I was confusing scala’s immutable Sequence types with the general notion. Functional programming has me all turned around.

    Nov 24, 2009 at 17:23

  • I added and removed a dummy character in your answer so I could give you the upvote.

    Nov 24, 2009 at 17:24


In simple terms:

var = variable

val = variable + final


  • 4

    I thought it was more variable and value

    – user

    Jul 2, 2020 at 17:37