[jmull]

I hate this example (sorry).

Reducing cognitive load is an excellent goal, but this seems more about distrusting that some other code does what it is meant to do. Pi is pi. If you're worried about it, command-click into it, or whatever the equivalent is in your tools. Or more generally: it's completely fine to be reading something at an abstract or symbolic level and use some mechanism to drill in when desired. The idea that you wouldn't have higher and lower levels doesn't seem right to me, and I don't think there's any way not having abstractions would lead to more readable code. (Now, it's certainly true that not all abstractions are good, and that vaguely defined and haphazardly layered abstractions make understanding code difficult but that's a whole different question.)

For readability, personally, lemme have some spaces between those tokens.

[eknkc]

This does not make any sense to me either.

If you need to pass the value of PI because you somehow do not trust it's origin, how on earth can you trust the exported function named "circumference" to calculate the actual circumference? Also, what if the rule of physics and mathematics change in future and we need to alter the definition of circumference? Maybe we need to pass a function that does the actual multiplication too?

[kibwen]

You've just reinvented Objectivist-C! http://fdiv.net/2012/04/01/objectivist-c

[paulddraper]

Cross-universe compatible code is the next big thing.

[kierenj]

I also find it difficult to understand the example. Why would "pi" be a configurable value? And if something /is/ configurable, the whole point is that the consuming code doesn't care where it's set.

Can anyone explain the argument in another way for me?

[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".

[tthisk]

Also the code should just use math.Pi. There are not that many use-cases I can come up with that you would want to use anything different. So I do agree that it is a terrible example.