From what I can gather, Registry is a way to localize keys to make using OTP stuff a bit easier. This is especially important when you want to use a binary key for a GenServer or Agent instead of an atom or setting it to {:global, key}.
That said, and I’m chalking this up to my own ignorance, it seems to be HIGHLY unintuitive to use. In my mind Registry is basically a supervised key/value store (like a map, but backed by an ets table) where the key responds to a {pid, init_value} tuple (or list of tuples if :duplicate is used). So when we have a function called keys, it makes sense that I’m looking for the keys within that Registry, especially since Registry.count/1 takes in the name of the Registry and returns the number of keys… Instead, we’re expected to also pass along the pid, to get the key(s) associated with it? If I’m using Registry as a way to make GenServer or Agent easier to use (not having to know the pid to pass along), why do I need to know the pid to pass along?
Similarly, Registry.values requires the registry name, a pid, AND the key? Does Map.values/1 require anything other than the map?
I understand there needs to be a difference in usages based on :unique vs :duplicate, but that seems like it could be solved via pattern matching. I like the idea of Registry, but it seems VERY clunky to use for what it’s trying to do. Am I just super ignorant of the underlying mechanisms? If so, I’d love some clarification so I can better understand where I’m falling short.
I think the part you’re missing here is that it’s generally expected that both ends – registered processes and processes interested in registered processes – know what keys they’re interested in. That would be the very same as with other registries – local atom names or :global.
Registry.keys and Registry.values are not meant as general tools to finding all keys or all values that are currently registered – besides the fact that this could potentially be quite an expensive operation. They’re much rather helpers for figuring out how a process in question is related in the registry, but you generally wouldn’t used them to interact with registered processes.
Registry.lookup, Registry.match, Registry.select are the APIs you’re expected to use to query the registry (in order of complexity).
I think one other use case that you are missing is the ability to use multiple Registries, which would require knowing the registered name or pid of that individual Registry. So the design of Registry is specifically to allow multiple Registries.
I think the confusion comes from the documentation:
A local, decentralized and scalable key-value process storage.
If it’s a key-value storage mechanism, it feels like it should behave a lot like the other “go-to” key-value storage mechanism. But I see how having to concatenate the partitions (if partitioned) would be very expensive if keys or values was used a lot.
I guess I have a sweet tooth and would prefer a bit more syntatic sugar over the Erlang abstractions.
Since it’s a key-value storage mechanism, it feels like it should behave like one. Map.keys/1 and Map.values/1 are trivial to use because I just pass in the map I want. It seems like Registry.keys should take in the name associated with the registry created in the supervisor, so Registry.keys(MyApp.GroceryRegistry) should return all of the keys available that have been registered either through Registry.register or {:via, Registry, {MyApp.GroceryRegistry, [name]}.
Instead, to get the available keys, we have to use the Erlang match pattern syntax on a function named select. If it’s a key-value store keys should return the list of keys and values should return the values.
That said, as LostKobrakai mentioned, it’s more about process discovery and use and those processes will know about each other. It’s not supposed to be used EXACTLY like a Map.
It is a key-value process storage. So you can think of it having three dimensions (key, value, pid), instead of two, and, it also allows duplicate keys with a single process. The process bit is crucial, it is not simply a key-value storage. If that’s your goal, :ets tables are most likely a better choice.
If that’s your goal, 
