Tooling fragmentation and separation of Elixir from rest of BEAM family

Before considering if we should merge the different tools or abandon one for the other you have to argue for what we would gain by doing so.

You have listed tools from the Erlang world that do the same things. For example relx and reltool, rebar3 and erlang.mk, and Common Test and EUnit. Have you looked at the historical reasons for why these different tools were created when similar tools already existed?

Rebar3 and erlang.mk have completely different premises, the authors of rebar3 wanted a build tool based on Erlang and the author of erlang.mk wanted a tool based on Makefiles, it would be impossible to merge those tools or use one over the other without giving up the original reason for creating the tool in the first place. Additionally, today most of the tools support building dependencies that use the other build tools, so not much is lost in terms of interoperability.

In ExUnit you use Elixir macros to write tests and you get features such describe, test tags, and setup blocks that you couldn’t write in Erlang in a similar way and you use a syntax that is natural to Elixir programmers. EUnit and Common Test also have different approaches to writing tests. What would be the benefit of using a single testing tool?

From this it sounds like you think most of tools that Elixir has added are not actually improvements (in the Elixir world) over the equivalent tools in the Erlang world. That is of course fine, but it’s a very different discussion than a discussion around fragmentation. I actually like that in the Erlang world there are multiple options for build tools, release tools and testing libraries. I hope that in the future we can get alternative tools to ExDoc, ExUnit, Distillery, and so on that explores new ideas so that we are not stagnant with the same tools and libraries forever.

9 Likes