Writing a library for use in both Elixir and Erlang

What is the best practice for implementing a library for use in both Elixir and Erlang? My goals include:

  1. minimize code duplication
  2. feels idiomatic to both Elixir and Erlang users
  3. no syntactic function call remapping like :lists.sort [3, 2, 1] or 'Elixir.String':downcase(Bin).
  4. integrates seamlessly with common package management and build solutions
  5. doesn’t break any features like maybe hot code reloading (or anything else, really)
  6. written primarily in Elixir because I like defmacro.

Without knowing better, the first strategy I’d probably try is implementing an Elixir library and making an Erlang wrapper. This seems good, except I’d have to manually keep the wrapper synced with the Elixir code. Are there recommended wrapper generators for this?

I’m not familiar enough with Elixir/Erlang/BEAM to know whether that approach might break any features. If so, would writing the library primarily in Erlang be any better?

I don’t have a specific project in mind yet. Just mulling over how I would approach this when the time comes. Thanks, everyone.

4 Likes

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 :wink:

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.

5 Likes

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
1 Like

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.

4 Likes

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? :slight_smile:

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? :slight_smile:

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.

1 Like

Fair point about it being just a top level module.

However I do think it might as well be considered a metaprogramming solution. calling defmodule inside a for is code generation. just because you haven’t created a new macro is a moot point

Oh it definitely is metaprogramming! It’s just simpler metaprogramming imo - no macros whatsoever. It’s easier to understand what’s going on you don’t have to know what to unquote etc. - it’s both easier to write and read imo :slight_smile:

However, as it’s fairly little code and the intent is rather obvious I don’t think it’s that big of a deal.