Ah, yea, this is only useful if you have some hex dependencies that must be built with Mix.
Because I wouldn’t say that these are improvements, I wouldn’t say the opposite as well. These tools are different. What I would ask is that “why are these different?”, and if answer is “because tool XYZ doesn’t suit Elixir development because of X, Y, and Z” (where X, Y, and Z are different reasons than “because syntax is more familiar” or “because why not”) then I am ok with that. The statement about ExDocs is that I actually, with full honesty, can say that I like ExDocs much more than EDoc. I cannot say the same about mix vs rebar3 or config.exs vs sys.config.
But I am glad that people are discussing the matter. Not that I want to make people feel bad about their projects, I just want to be sure, that we will not diverge too much from the rest, instead I want to encourage people to provide solutions that will build whole community better and stronger, doesn’t matter about tooling.
What about if Elixir were a rebar3 package? It seems like it would give you full control of the install path of elixir - it would be in your deps.
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.
16 Likes
