4 ms·
Oh no, a small chance of a bug! 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
by SamReidHughes 12y ago
Oh no, a small chance of a bug!
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.
- pcwalton 12y agoData 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.
- SamReidHughes 12y agoIn 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. Wow.
- madez 12y agoI think we should assume by default that code is not reasonably written. Tool chains that check properties for us are incredibly useful.
- SamReidHughes 12y agoHave 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?