The goalposts have been moved. The claim is that this pattern isn’t suitable for production code. The ground truth is that a compliant Go implementation may elect to: crash; read the first value ever set to the variable for the entire lifetime of the program; or behave completely as you’d expect from a single core interleaved execution order. The first is an opt-in, the latter two are up to the whims of the runtime and an implementation may alternate between them at any point.
Is that the kind of uncertainty you want in your production systems? Or is your only requirement that they don’t serve “corrupt” data?
Is that the kind of uncertainty you want in your production systems? Or is your only requirement that they don’t serve “corrupt” data?
Don’t be “clever”. Use locks.