3 ms·

The State of Caching in Go

27 points by mrjn 8y ago

skywhopper 8y ago
Great article on the technical challenges of meeting their tough list of requirements. But the headline made me think this was going to be about a glaring gap in the Go ecosystem but I can’t tell if that’s true from what they wrote. Only one library was mentioned as a theoretical solution. Are there others?
- convolvatron 8y ago
  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'
  - jzoch 8y ago
    While I agree with you I do find it prescient that a "get things done, production" language like go doesn't have more super solid cache libraries. I guess the community hasn't felt the need to take it further than that but I'd figure companies like Google would have open sourced whatever they use at this point
  - Scarbutt 8y ago
    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. He found one for Java.
- tveita 8y ago
  Not as much "glaring" as a bit conspicuous given the stated strengths of Go. I feel like there's an underlying phenomenon here, many people like to talk about performance but don't actually need it. So any time you do need performance you need to sort through the popular "high performance" implementations and figure out which ones actually perform well in production.

27 points by mrjn 8y ago

Great article on the technical challenges of meeting their tough list of requirements. But the headline made me think this was going to be about a glaring gap in the Go ecosystem but I can’t tell if that’s true from what they wrote. Only one library was mentioned as a theoretical solution. Are there others?

convolvatron 8y ago
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'
- jzoch 8y ago
  While I agree with you I do find it prescient that a "get things done, production" language like go doesn't have more super solid cache libraries. I guess the community hasn't felt the need to take it further than that but I'd figure companies like Google would have open sourced whatever they use at this point
- Scarbutt 8y ago
  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. He found one for Java.
tveita 8y ago
Not as much "glaring" as a bit conspicuous given the stated strengths of Go. I feel like there's an underlying phenomenon here, many people like to talk about performance but don't actually need it. So any time you do need performance you need to sort through the popular "high performance" implementations and figure out which ones actually perform well in production.