It's very easy to accidentally borrow in Go, because Go has implicit reference types. If you send a slice across a channel, you're sending a reference, not a copy.
People have been making slices in Go and sending them across channels without unique ownership and borrow checking for years, and it hasn't been a problem.
Are you sure there's not a problem? That's a potential race condition. Are you sure there's no problem after a few years of changes to the code?
(Claims that there's no need for programmer checking systems are usually wrong. Go read CERT advisories or go to DefCon. Those are just the exploitable bugs. I once spent four years debugging other people's code using mainframe OS crash dumps. Most programmers are not as good as they think they are.)
Can you come up with a reasonable way this could turn into an exploitable security issue? I can see crashes and maybe live locking but Go doesn't have pointer arithmetic, so I can't see how this could be used to bust the stack.
One user's private information could get sent to another user, or you could have a subslice that gets "validated" and then overwritten.
Edit: Of course, this isn't exclusive to data races, this can happen with anything that decides to save the slice for a while, without, say, defensively copying it, when some other code decides to reuse it.
Edit: Way to edit your post. In fact, if you look at Go users and their ability to use it productively, they seem to be doing just fine. You'll make less money if you use a version of Go with unique ownership and borrow checking.
Data races on an underlying array buffer due to simultaneous accesses from multiple threads do not have "a small chance" of occurring in virtually any language where it's allowed.
You can argue that a borrow checker isn't a good fit for Golang, and I'd even agree with you on that, but let's be candid about the frequency of data races in the wild.
In reasonably written message-passing Go code it's not likely. It's no different from any other situation where you've got a slice that isn't supposed to be modified anymore.
> let's be candid about the frequency of data races in the wild.
Have you used Go and ran into problems with people overwriting data in slices underneath you? Was it to such a degree that it took precedence over other bugs and slowed down development in the effort to catch these mistakes manually?
