This is probably a bit off topic, but I notice that they implemented their own hashmap with pluggable hash functions. Awesome in theory (and practice), though I notice that the performance of their custom hash table is poorer than Go's built-in hash map (Go's hashmap takes 1/2, 3/4, and 9/10th the time of their hashmap for small, medium, and large keys, respectively - though this could be related to the updated aes hash in Go, and that my processor supports it).

While looking through the implementations, the Gnatsd hashmap implementation is a simple table with buckets, where as the Go hashmap also uses a table with buckets, though each "bucket" has 8 slots by default (and does subsequent chaining). Go's chunking of buckets helps caches work better, reduces random reads, and helps to minimize overhead (fewer pointers if you have fixed-size data). Read the first 83 lines of http://golang.org/src/pkg/runtime/hashmap.c to see what good structure design and experimentation gets you.

Does someone have an example where a 'go test --bench="." -gcflags="-B"' call in the gnatsd/hashmap path actually comes out ahead for the Gnatsd hashmap using a recent Go?

At first glance, NATS looks similar in goal to MQTT. Can anyone describe the differences?

  [1]: http://www.activestate.com/blog/2013/01/building-paas-ruby

at first I definitely thought this was related to the old gnu bug tracker.