Writing a library for use in both Elixir and Erlang

I don’t have any other certain answer than the wrapper solution (which would of course work, but as you say be a bit annoying to maintain). However, it feels like this should be possible to solve by some kind of compile-time transformation of module / function names, so that you could compile to two different outputs from the same source.

That being said, it looks like it could be done using defdelegate in a compile-time-dynamic fashion, eg:

I won’t say much about if it’s a good idea or not, but at least it works for this simple example

What I saw frequently in Erlang codebases using Elixir is the use of macros to alias elixir modules into something more consumable. You could provide an erlang header file that would provide some of those macros, eg:

-define(string, 'Elixir.String')
# later in code
?string:downcase(Bin).

On the other hand, I don’t see anything wrong with calling erlang-style modules from Elixir. You could use those:

defmodule :foo do
  # ...
end
# use in elixir
:foo.bar(1, 2, 3)
# use in erlang
foo:bar(1, 2, 3).

In general I would say that a wrapper is the worst approach - it doesn’t add any significant value and has considerable downsides and risks regarding it getting out of sync.

I didn’t know about Erlang-style module support in Elixir. Thanks for mentioning it!

So if @jmitchell would like to be able to call Foo.bar nicely from both Elixir and foo.bar from Erlang, would this be an acceptable approach to expose the api for both ?

defmodule Foo.Impl do
  defmacro __using__(_) do
    quote do
      def bar(), do: # ...
     # more of Foo public API
   end
  end
end

defmodule :foo do
   @moduledoc "For use from erlang"
   use Foo.Impl
end

defmodule Foo do
   @moduledoc "Alchemist way"
   use Foo.Impl
end

This seems great btw. I implemented this in benchee now and we’ll see how it turns out but it was super easy to do and even the doc generation etc. is alright. I have yet to really try this under erlang but I see no problems coming my way… thanks a lot @vic!

So, @josevalim came around and suggested another way to do this which I like better as it is simpler:

elixirdoc = """
...
"""

erlangdoc = """
...
"""

for {module, moduledoc} <- [{Benchee, elixir_doc}, {:benchee, erlang_doc}] do
  defmodule module do
    @moduledoc moduledoc
    # all defs here without using
  end
end

It is implemented in this benchee PR.

This feels like an odd solution because it seams like a load of code is being duplicated.

However I am super happy that this problem is being tackled. Just need to wait and see how macros can be useful to erlang.

do you mean the old solution, the new one or both?

Imo no code is duplicated, depending on the meaning of “duplicated”. I.e. no code in my files is duplicated, I just have to change a thing in one place and it changes everywhere I want it to change. So that’s no duplication for me.

If we are talking about compiled duplication, sure there is. For my understanding of use it is the same for both solutions though (I might be wrong). Also, does it matter? It won’t impact the compiled size to a meaningful degree. If we were on a JITing VM we could argue that they are JITed which might be suboptimal. Alas, we are not. Also, the interfaces are meant to be used as either or (elixir or Erlang) so someone using both would be unlikely.

Or am I missing some other duplication?

The duplication I was talking about here was the compiled duplication. I was curious if the compiled artifact was twice the size.

I have tried another solution in this PR. comments/criticism welcome.
https://github.com/CrowdHailer/raxx/pull/112/files

Not sure about the compiled artifact size but as it’s just one top level module that does a bunch of delegates to other things I don’t think the size impact (even if it duplicates all that code) is worth worrying about as I’d say it’s maybe ~1% of the overall code size.

I like the solution because it’s very simple and uses the simplest constructs to make it work - i.e. no macros.