Erlang vs Elixir on module API definition

Even when I don’t code that much on Erlang (almost zero), I would have to say that I love the fact that I could open a file and see at the top of the file the public API in contrast with Elixir modules where you can’t see what is being exposed and you need to search for non private function declarations.

I would argue that defp should make things public instead of making things private.

I would prefer to follow the Erlang behavior. It is so much clear to find the public API.

I am curious about your thoughts about this, and especially from the Core team.

Am I the only one who think that?

1 Like

This seems largely orthogonal.

First class docs for erlang modules handle this pretty well for me. I generally start from the docs on a given module, and then if I need to dig into the code I can.

Really there’s trade offs either way. If I’m looking at a function in erlang I have no idea if I can actually call that function just by looking at it, I have to go and look elsewhere.

I’m not on the core team, but surely this ship has sort of sailed?


Only on the first glance.

grep for defp is much easier than grepping for "def ". The same is true for most editor searches I think. Also it could even happen that one need to grep for def( as well. So if defp where actually defining public/exposed functions it would be easier to find.

But as you already said, I tend to start with the documentation, because def only makes not a public function. It could still be @doc false and therefore has to considered private.

1 Like

No, I agree with you here. It is easier to see the public API at the top of the file. But I will admit that I am biased. :wink: