That's certainly an accurate description of the cause. But I don't think that it's a valid excuse: not supporting immutability well is fine, pretending that you

That's certainly an accurate description of the cause. But I don't think that it's a valid excuse: not supporting immutability well is fine, pretending that you do when actually you don't is not. The kotlin defense to this surely is that immutability happily exists in val constructor args (with the usual exception: not transitive through references), but that's purely contextual and a difference that is very hard to represent at usage site (e.g. they look exactly the same in the intellij "javadoc" view). If for some reason bean-style methods had to be represented through var/val syntax, I think that it would have been much better if read-only calculated getters were represented by a var without set(), leaving val to cases where you're guaranteed to get the same when referenced twice (value set once in constructor or some lazyness shenanigans).