[jimmytucson]

Not shilling for Go here but there are a few misconceptions in this blog post. In addition to the others mentioned:

> All of these examples involve assigning to a constant a value known at compile time but none of them will work

Maps are not known at compile time. Hash functions are randomized based on a seed only known at execution time. The hashed value of "HELLO" is actually different each time the program runs. Even if the hash function weren't random, the runtime has to allocate buckets for map values on the heap, which involves calling the OS to get memory addresses for those buckets, etc.

In Go, `const` means "the compiler can completely evaluate this expression and store the final bytes in the executable," which has the effect of making them non-reassignable, but protection from reassignment is not an actual feature of the language the way it is in Java and C++ (goes back to the maintainers wanting to keep it simple).

[j_w]

Doesn't protection from reassignment not exist in most languages anyways? In C++ you should be able to cast away the const. Realistically you probably can achieve this in any language with reflection.

Unless a const is literally a compile time constant inserted through the program, it's likely able to be changed somehow in most languages.

[jimmytucson]

You can definitely protect from reassignment in those languages (e.g. `final` in Java) but they don't completely prevent you from changing the underlying data. Rust would be one that comes to mind that has true immutability. I guess the Go maintainers just didn't want to go down that road, which I get.

[j_w]

Sorry, I guess I read "protect from reassignment" as "protect the underlying data" then.

I would argue that if you CAN change the underlying data, then the understanding of const by 99% of people is made incorrect. Therefore it's not really a good feature (in my opinion).