@prologic@twtxt.net I believe it originated in the C++ universe, but it can be translated (to some degree) to some other languages, too. To my understanding it boils down to everthing, that is not being intended to be modified, to be marked const. If you then try to violate unmodifiable stuff, the compiler raps you over the knuckles. I found this long FAQ about it if you want to go into the details: https://isocpp.org/wiki/faq/const-correctness ;-)

I’ve been hit a few times in the past with nasty bugs, because wrong variables were updated. Would they have been annotated as unmodifiable, the bugs were found by the compiler and hence prevented in the first place. So, const correctness not only helps the compiler to spot errors, but also clearly communicates to the next programmer, that something is not supposed to be updated. Yeah, the code in question was not very well engineered, super long (although I generally don’t mind longer code segments per se if they’re justified) and not well tested. So proper tests could have detected the bugs, too. Which I ended up writing to fix and validate. Still, const correctness is valuable to me as it adds more information about the code and the thoughts of the initial author.

And sadly, Go does not have anything like that. Okay, there’s the const keyword, but it’s usefulness is incredibly limited. So I don’t count that. And the assignment operators := and = do not really count in my point of view either. There’s too much error handling going on, so you basically always end up having to use :=, because only the first variable is new, just err was already used, so = does not work:

foo, err := eggs()
if err != nil {
    return err
}
bar, baz, err := spam(foo)
if err != nil {
    return err
}