i too found the headline really confusing. at some* point, if you're designing something like a database you should just accept that you'll be building some am

i too found the headline really confusing. at some* point, if you're designing something like a database you should just accept that you'll be building some amount of core infrastructure (for example a cache) yourself. it seems strange to assume there is a widget in the exact shape you need with exactly the right interface and semantics floating around somewhere. to go a step further...efficient memory management is pretty key to cache behavior. you're generally using up a good fraction of available memory and have a really good idea what the lifetimes are (since thats your whole policy). that the GC might be a little slower to release than you might like shouldnt be a surprise at all. 'how we built a cache in go' is more apt than 'why didn't go have a cache that fit our needs already, bad go'