when you work in a functional programming style then every modification of a objects data member would create a new copy of the object; that one is mostly a copy of the old object except for the variable change that was introduced by the setter. In general that make a lot of sense for smaller objects (in Java the String is immutable, so are tuples) - it is easier to reason about the object and you don't have race conditions.

in Scala you have mutable collections and immutable collections - like that one; the more accessible versions that you have in your default namespace are immutable (that's supposed to be the default choice).

now in theory smaller contingent objects that span 'a few' cache lines would be easier to copy than to modify. Now my problem with that statement is that with the JDK you usually have lots of Object references (can't do a lot with primitive types), so you need to try hard in order to get an object that spans a few cache lines. You would have more of these in go, but they don't do a lot of functional style programming in go, afaik.

maybe it would make some sence to port clojure or scala to the golang runtime.