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.

Keyword lists are very core to the Elixir syntax itself. For example

def the_answer do
  42
end

is syntax sugar for

def the_answer, do: 42

or even

def(the_answer, [do: 42])

which is basically 2 parameters passed to the def macro. The last one is a keyword list with a :do key in it.

This is why all your functions can take a keyword list without square braces as the last parameter – because the core language syntax uses that.

This is worth highlighting, it gives you a CLI-repeated-flag-like interface for options.

Elixir keyword lists are strict subset of proplists.

This could be done for maps as well TBH.

My reasons:

• Maps are way younger than property lists/keyword lists
• Keyword lists allow for duplicated keys which can be useful sometimes

Maybe not an exhaustive list, but some reasons:

• Erlang historically uses proplists. Not 100% the same but similar.
• The keyword syntax does have some nice sugar
• Elixir used to have HashDict instead of maps, so keyword lists might have been supported before maps were