[eternalban]

Root issue is that Go's "packages" are in fact stateful modules, and since Go does not support 'finals' or 'vals', you actually never know if somewhere malice or mishap has changed an imported package's global variables.

I wonder what a marriage of Go's light touch syntax, the golden nail of go/select (but generalized to include IO), and a proper type system would look like.

[krylon]

All in all, I like Go, but the abscence of proper const/readonly/immutable data is one thing that I am unhappy with.

Go's const is closest to C's, which is ... terrible. const-correctness is one of the things where C++ offers a huge improvement over C.

At work, I use C# from time to time, which has two types of const: const as in compile-time-constant, along with all the restrictions that implies. And readonly which qualifies a variable as "once it has been initialized, it may not be changed".

To be fair, I have not run into major problems for a lack of it, but then again I mostly use Go for toy projects in my free time. Were I to use Go in production code, I would sleep a lot better if I could declare data as immutable.

[euyyn]

Wait, but the argument of the post isn't "some unrelated piece of code could go and change the value of config.Pi, affecting everyone". Rather "I don't know if the code of the config package set config.Pi to be actually pi".