One thing I’d like to add here is that unifying tools is something you can easily do before you start, or as you break compatibility across versions. Otherwise, there is momentum in what a community does and uses, and frustrations in breaking such expectations.

I think Mix could have been adopted as a new Erlang build tool since it came out at the right time (rebar 2.x development had faltered), but just the fact that it required installing Elixir to build any Erlang project was enough to prevent it to be adopted on that side of the community—nevermind that the relationship between both communities was a bit less friendly back then.

Elixir was also able to historically adopt new ideas rapidly because it was (and possibly still is) a growing community: if only newcomers use the new stuff, they will still, in a short amount of time, drown out the old stuff by sheer numbers.

On rebar3’s side, we have what is essentially a stable community (some people leaving, some people joining), with a lot of history behind it: the rate of newcomers is not sufficient to drown out anything. Projects like ejabberd or rabbitmq are now over a decade old and still ongoing; they pre-date even the first rebar release, never really needed to adopt them either, and have their own distinct communities unrelated to the general language.

Even though the first stable Rebar3 version was released in March 2016 (we’re close to 3 years in!) there are still significant OSS projects that haven’t switched if only because if it ain’t broke, don’t fix it.

A scenario where today Elixir and Erlang were to merge efforts at the build tool level would in all likelihood see a much slower adoption curve. Mix is shipped with the language so the update is kind of friction-free, but licensing kind of makes that difficult for rebar3 where generations of various licenses and non-stdlib dependencies would need to be handed over to Ericsson to make it work. It’d be rather surprising to see any fast transition.

I feel like our current approach of slowly building on a common core while maintaining the specific per-community differences is likely the most practical way to move towards more common sets of tools.

A big challenge in unifying tools like mix and rebar3 is that they take a different approach to extensibility and configuration. Mix essentially lets you extend it by writing arbitrary tasks in arbitrary Elixir code that you evaluate within the tool.

Rebar3 aimed to have a declarative configuration format above everything and tries to actively restrict what you can do in its config files (there’s an escape hatch with rebar.config.script), and we aimed to make things extensible through the plugin system.

Mix supports semver and will, as far as I can tell, unify the dependencies and extension versions it needs. Rebar3 started in a world where a single lib would often have diverging git tags, app files, and documented versions; as such the dependency handling algorithm is based off a “distance from root” comparison (the version closest to the project root wins, with the assumption that more of its functionality is exercised). When it comes to plugins – and plugins include ways to load custom compilers and dependency fetchers – we instead handle sequences of loading and unloading dependency sets dynamically between libraries required for plugins and deps, so that they don’t clash.

That’s without mentioning the distinctions in profiles, configuration handling, releases, and so on. I think at this point the philosophies of both tools diverge enough that it would be extremely hard to unify them without breaking major parts of either ecosystem. It’s already a bit odd when it comes to dep resolving (we don’t have optional deps in rebar3!)

My prediction is that if we were to do it, we’d have to pick an intersection of features, and the rest would be best effort. So any lib from either ecosystem that uses a more advanced feature set from their build tool would be at risk of breaking.

I’m betting more on our ability to keep interoperating between mix deps and rebar3 deps as the way forward, since the bridge appears easier to gap here.

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.