4 ms·

You must think about synchronization, really, not necessarily ownership. What you're saying is true, but it's still not an obvious choice - there's still a tra

You must think about synchronization, really, not necessarily ownership. What you're saying is true, but it's still not an obvious choice - there's still a tradeoff. The (hypothetical, e.g. Rust) compiler can check only a subset of correct programs, which means that many correct programs can't be successfully checked. This is all good if it only affects edge cases, it's not that good if it affects common cases. It additionally becomes less of an issue (in Go) if you avoid shared mutable state and use channels for complex cases. So all in all I agree the compiler checking your synchronization is nice, but it's a tradeoff (at least for now), and with the current state of it I think most projects will be just fine without it. On the other hand, there are projects that should definitely use languages that allow for static analysis like that.

erik_seaberg 3y ago
Yeah, I’m thinking of ownership as exclusive access handed off in sync, and disposal as one more duty of the final owner. I would feel a lot more comfortable with channels if a linter would verify that every message is either mutex protected or a newly created graph (maybe a deep copy) never accessed again by the sender. Go already does some escape analysis to minimize heap allocations, but doesn’t flag a goroutine receiving nested maps or array slices that may be shared.