go-datastructures

I too wish there was more standard containers available in Go's standard library. However, I don't think there will be a collections package unless and until generics make it into the language. That said, there are some pretty good libraries out there: - https://github.com/timtadh/data-structures ## I wrote this one. - https://github.com/Workiva/go-datastructures ## this one is also popular. - https://github.com/golang/go/wiki/Projects#data-structures ## big list here.

I think you are wrong in thinking he is protecting the `triggered` variable with the lock. He's using a Mutex to synchronize access on the entire struct. snippet from https://github.com/Workiva/go-datastructures/blob/master/fut... f.lock.Lock() f.triggered = true f.item = item f.err = err f.lock.Unlock() f.wg.Done()

Something I've always wondered - in the futures packages (https://github.com/Workiva/go-datastructures/blob/master/fut...): The author has a variable `triggered` to check the state of whether or not the future is complete. Now to protect that variable from data races, the author uses a standard lock. Now since you need to protect a simple value what I would do in this situation is use an atomic variable w/ atomic.StoreInt32 (you could also probably not even have to use an atomic load in GetResult). Of course the best option would be to benchmark (and I'm assuming the author did, given that the structures are performant), but I'm wondering if my "gut" is right and under what situations others have seen that would necessitate a lock vs. an atomic instruction (high contention on readers, few writers)?

Agreed with setting the standard arbitrarily high. It depends on what problem you're trying to solve—just like deciding when to use any other tool. Context matters. Where I work, we've been trying to build some super-fast systems and things like the GC and even calling interface methods matter. We open sourced some data structures that show just how optimized we're trying to get (https://github.com/Workiva/go-datastructures), but in hindsight, Go might not have been the right tool for the problem.