Benefits of named return values in Go

Re:Benefits of named return values in Go by heythere124 on Friday June 30, 2017 @07:02AM (#14669841)

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

[ Parent | on HN ]

Re:Benefits of named return values in Go by the8472 on Friday June 30, 2017 @08:05AM (#14670168)

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.

[ Parent | on HN ]

Re:Benefits of named return values in Go by heythere124 on Friday June 30, 2017 @08:18AM (#14670228)

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

[ Parent | on HN ]

Re:Benefits of named return values in Go by the8472 on Friday June 30, 2017 @12:46PM (#14671900)

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

[ Parent | on HN ]

Re:Benefits of named return values in Go by Filligree on Friday June 30, 2017 @07:59AM (#14670136)

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).

[ Parent | on HN ]

Re:Benefits of named return values in Go by heythere124 on Friday June 30, 2017 @08:25AM (#14670263)

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.

[ Parent | on HN ]

Re:Benefits of named return values in Go by Filligree on Friday June 30, 2017 @09:19AM (#14670496)

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

[ Parent | on HN ]

Re:Benefits of named return values in Go by heythere124 on Friday June 30, 2017 @10:09AM (#14670806)

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.

[ Parent | on HN ]

Re:Benefits of named return values in Go by pcwalton on Friday June 30, 2017 @12:44PM (#14671889)

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.

[ Parent | on HN ]

Re:Benefits of named return values in Go by pcwalton on Friday June 30, 2017 @11:55AM (#14671527)

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.

[ Parent | on HN ]