I’m sure this has been asked elsewhere (but forgive me I could not find something that addressed this specifically)…
Why do Elixir functions usually take keyword lists as options? Why not maps? Keyword lists are problematic especially if you’d like to pattern match on a map key to route to different functions, for example. Is there a historical or performance-based reason why keywords are used over maps?
I find using keyword lists with Keyword.get/3 very handy because you can easily define a default value. Might be somehow possible with Maps too, I guess.
Yep, I think it’s a mix of historical and practical reasons (the latter including possibility of duplicated keys, and explicit ordering).
You are right that keyword lists are more inconvenient when using pattern matching. But then again, I think they make a good outside interface, and usually I validate and parse options into another data structure (like a map or struct) as soon as they get within the boundary of my module or library.
Elixir had an option to choose either keyword lists and maps for options. The reason why we chose keyword lists are because they preserve user ordering and they allow duplicate keys. We use both features in Elixir itself.
For example, in try/catch/after, we warn if you put after before catch, as that would read weird. Using maps would not allow us to warn in those cases, as you always have alphabetical ordering.
When you do import Keyword, only: [get: 2, get: 3], those are duplicate keys. Keyword.__info__(:functions) returns duplicate keys too.
In other words, there are scenarios where keyword lists can be useful and unifying opts under keyword lists is reasonable. Community projects, such as Ecto, leverages them too. Plus other benefits such as Erlang compat.