[heythere124]

Not my area of expertise and it is yours, but if you eliminate a zero instruction before a copy instruction how can you be sure that doesn't affect other threads?

  var x Int
  // Pass x to a thread by reference
  x = 0
  time.Sleep(1000)
  x = 1

[the8472]

How can you be sure that the other threads ever see it in time? they might be suspended for a whole second because a HDD needs to spin up or something like that.

So threads never seeing the value is already a valid outcome, so the compiler might as well always do that.

[heythere124]

time.Sleep(1000) could be replaced with a real syncing mechanism of some kind -- it's only for illustration.

[the8472]

a real syncing mechanism would introduce compiler barriers that prevent such an optimization.

[Filligree]

The answer to that one would be to embed thread-safety in the type system, aka. Rust.

For languages with less sophisticated type systems you get a choice between inefficiency (Go), or complicated rules which state that the programmer is wrong for coding that way (C).

[heythere124]

Your "solution" is possible in many languages. It's just to give threads complete ownership of data they use. It doesn't require a special type system.

In general I don't think Rust actually adds much abstraction that isn't already in say Python. What it does is enforce tight constraints.

[Filligree]

The constraints are important. They're what let you code safely, and also give the compiler the ability to optimize better.

[heythere124]

Not sure those optimisations are worth much. And it's only safety by forcing lowest common denominator code and making you justify everything to a dumb compiler. Rust serves a niche, but it is a tight niche IMO.

[pcwalton]

Aliasing info is hugely important in optimization. In fact, it's needed to solve this very bug.

Aliasing info is, fundamentally, what allows Rust to have memory safety without GC.

[pcwalton]

The memory dependence analysis must prove the memory is unaliased, which ensures among other things that no other thread can have a reference to it. Presumably in Go return pointers are guaranteed to be unaliased.