Why Elixir is warning me about not implemented behavior functions?

I’m also confused about warning (instead of error), especially when we have optional_callbacks
Maybe it happen historically.. It would be awesome if error raised

I think a compilation error would be overkill. Behaviours are a way to establish explicit contracts. It’s a best practice, not a prerequisite for compilation.

https://hexdocs.pm/elixir/behaviours.html

If a callback module that implements a given behaviour doesn’t export all the functions and macros defined by that behaviour, the user will be notified through warnings during the compilation process (no errors will happen).

Well, contracts are worth nothing if they are not enforced. I actually find this compromise rather surprising.

I don’t have insight into the why the core team chose that route. You’d have to ask them. I appreciate the flexibility, personally.

I don’t know the rationale, however to turn warning into error yourself you can pass --warnings-as-errors to mix compile, mix test and many other tasks.

Just my guess - not an official explanation.

I think the warning makes sense in the context of Elixir (or Erlang) being dynamically typed. If Elixir (and Erlang) was statically typed then an error would make sense.

Dynamically typed languages lend themselves to REPL-Driven-Development, i.e. you can build and exercise code in the absence of other functionality (to be added later) as long as your current runtime execution path doesn’t run off into the “other non-existent” parts of the code. With a statically typed language this is impossible - you would at least have to “stub out” all the other parts of the code - even if you currently do not plan to execute them at runtime (during development).

Now granted unlike JavaScript, Elixir (and Erlang) still needs to successfully compile before anything can be run - but to use XML terminology - successful compilation simply means the code is “well formed” but it doesn’t mean the code is “valid”. The fact that Elixir (and Erlang) requires compilation should never be mistaken for it being “equivalent to” statically type checked

By only issuing a warning, you are free in development to write and run tests for parts of the behaviour that do not rely on that particular callback. This would be especially handy for behaviours with a relatively large number of callbacks. So the warning lets you get the first tests to run much more quickly - without necessarily having to sketch out the entire behaviour implementation first.

Now deploying code with these type of warnings (or ideally any warnings) into production would be questionable.