Golang data structures

This point about the B-tree is salient:<p><pre><code> Unfortunately, to make the B-tree generic we require an interface and the most expensive operation in CPU profiling is the interface method which in turn calls into runtime.assertI2T. We need generics. </code></pre> One of the most frustrating aspects of go is having to resort to interface{} every time you want a generic implementation of a data structure.

Something I&#x27;ve always wondered - in the futures packages (<a href="https:&#x2F;&#x2F;github.com&#x2F;Workiva&#x2F;go-datastructures&#x2F;blob&#x2F;master&#x2F;futures&#x2F;futures.go" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Workiva&#x2F;go-datastructures&#x2F;blob&#x2F;master&#x2F;fut...</a>):<p>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&#x2F; atomic.StoreInt32 (you could also probably not even have to use an atomic load in GetResult).<p>Of course the best option would be to benchmark (and I&#x27;m assuming the author did, given that the structures are performant), but I&#x27;m wondering if my &quot;gut&quot; is right and under what situations others have seen that would necessitate a lock vs. an atomic instruction (high contention on readers, few writers)?

Now someone will hopefully create &quot;type writers&quot; for gen [1] for compile-time type checking and convenience.<p>[1] <a href="http:&#x2F;&#x2F;clipperhouse.github.io&#x2F;gen&#x2F;typewriters&#x2F;" rel="nofollow">http:&#x2F;&#x2F;clipperhouse.github.io&#x2F;gen&#x2F;typewriters&#x2F;</a>

For an alternative to Futures, check out tv42&#x27;s &quot;topic&quot;:<p><a href="http:&#x2F;&#x2F;github.com&#x2F;tv42&#x2F;topic" rel="nofollow">http:&#x2F;&#x2F;github.com&#x2F;tv42&#x2F;topic</a><p>I used it here in my multiplexing serial-to-TCP adapter: <a href="https:&#x2F;&#x2F;github.com&#x2F;chrissnell&#x2F;tnc-server&#x2F;blob&#x2F;master&#x2F;tnc-server.go" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;chrissnell&#x2F;tnc-server&#x2F;blob&#x2F;master&#x2F;tnc-ser...</a>

Some of these sound really great. A major pain point with go concurrency is the absence of a fast lockfree map implementation that doesn&#x27;t destroy your GC times. The &#x27;ctrie&#x27; sounds very appealing; I&#x27;m curious to try it.

Has anyone used Ctries in any real scenario (has anyone implemented them in a language like C)? How do they fare as opposed to other data structures? Is the latency of CAS instructions insignificant?<p>I&#x27;m thinking of using it in our codebase, in theory it should speed things up quite a bit.

Nice work. It is a pity that Go has no generics, though. With them, data structures would be much more efficient and easier to work with.

Whoah.