Thanks for the review! I appreciate the feedback. One key piece that might have been unclear: since this code is part of a larger module (note package main), so

Thanks for the review! I appreciate the feedback. One key piece that might have been unclear: since this code is part of a larger module (note package main), some of its parts live elsewhere. If I were to publish this, I'd consolidate those parts and build some proper module isolation here. OnStore is there purely because one of my resources needs to notify another part of the program that it has been stored; if I ever clean this up for public consumption, I'd probably want to add both pre- and post-handler hooks (along with the ability to add more rules and change the defaults, as Angular's $resource gives the client). The advantage to the Storable is that other parts of the program can create and store those resources without needing knowledge of how keys are constructed. I also can't think of a way to do what empty() does without making it an interface function; "I need another copy of this unknown interface type" isn't something go has a clear solution for. Hypothetically, I could make empty() into a function that returns interface{}, take the key() suggestions you've given (though that leaks key-making knowledge), and then the whole thing would operate on interface{} type... Doable and more flexible, but not quite as clear on what resource will actually be stored and retrieved. Good tradeoffs. A bit of feedback on feedback: avoid adjectives like "dumb" and "stupid." The signal-to-noise ratio is too low on them, and it makes for a harsher community (as other commenters in this topic have mentioned on their experiences trying to get help).