[jiehong]

Java falls a bit in between Go and Rust on that example:

Closures only allow variables that are effectively final, aka you can’t reassign them (the compiler will stop you).

But you could pass an object and update its internal state.

[qsort]

"final" in Java is kind of useless, really. A const mechanism like C++ has would go a long way and would be a perfect fit for the OO nature of the language.

[eganjs]

Final in Java means the value of a variable, property or parameter will not change after its initial assignment. Values in Java can be either a reference to an object or a primitive such as an integer, double or bool. It's definitely far from useless as it asserts that the reference or value you capture in a closure is not an old version that has been replaced, this approach is a consequence of Java disallowing arbitrary pointers. IMO Java's biggest mistake here is mutability by default, which Kotlin has learned from. If you understand why it is this way it makes a lot of sense and tbh I think it promotes better code. That said I would like to see more immutability in Java and with things like Record classes you can see Java is moving in the right direction.

[qsort]

I agree with that and I use final as much as possible. E.g. instance variables that don't need to change, I almost religiously declare them as "final" and initialize them in the constructor.

What I mean is that what Java really "should" have is const like C++. A C++ function with a prototype of:

    int doSomething(std::vector<int> const &x)

tells me much more than the equivalent Java:

    int doSomething(final List<Integer> x)

Also C++ member functions can declare themselves as not modifying their "this" instance. E.g. there's no way to write this code in Java:

   int X::doSomething(std::vector<int> const &x) const {
       ...
   }

which is an extremely powerful, compile-time checkable description of what we are doing.

It's not that final is useless (probably wrong choice of words there), what it does is okay and it's correct to use it as much as possible, but it's a far cry from the static guarantees afforded by const-correct code.

I also agree that the correct approach is immutability by default, but that ship has sailed, and it's also an orthogonal concern to what I'm saying here.