[di4na]

Well elixir explicitly try to not move away from the erlang paradigm and to be fully and "naturally" inter-operable with it. It is far more integrated with erlang than Scala is with Java as an example.

It is basically erlang with better tooling and still an easy use of erlang.

[mononcqc]

We probably had our discussions about this before, tooling definitions diverge at times, and I have a vested interest in some of them, but I will just state my disagreement on the better tooling side of things ;)

[strmpnk]

To say a few things that Fred isn't saying here (these are my opinions not his):

- Early Erlang tools had a lot of issues when Elixir showed up but rebar3 made quick progress and is a very good set of tools integrated into one command-line interface

- rebar3 has supported creating releases for a very long time which Elixir's mix tool is just catching up to (sure distillery supported things but so did relx and half a dozen other Erlang tools)

- rebar3 has built-in support for things like dialyzer which still require extra work to use from mix

- rebar3's _checkouts feature is very nice and has no good mix equivalent

- rebar3 offers a declarative configuration setup which makes it easier for other tools to integrate their data and read other data w/o requiring plugins to be loaded everywhere (and this is to say it still supports scripting where needed, which will still result in a declarative output)

- rebar3's version resolution system is more practical and puts the final control of version selection in the developer's hands rather than strictly package manager metadata which can lag or suffer unfortunate problems from version operators and unfortunate problems that come up from blind-semver adoption (this is a longer topic so I apologize for the poor summary here but I do think there is a good argument for rebar3's approach)

- rebar3 works and upgrades independently from Erlang/OTP releases allowing more fluid iteration whereas mix is very much locked to Elixir

I participate in the Elixir community and every time I hear the tooling story I think about all of the things I miss from Erlang tools when using Elixir. It'd be more accurate to say that Elixir has revitalized Erlang with a bit of competition and some diversity in background.

Either way, there is room for improvements in both camps. I hope Elixir's mix catches up with rebar3 in some of these areas and I hope Erlang doesn't ignore some of the caveats that are still around as given facts of life (perhaps getting better support for the wider set of BEAM languages would be a start so each doesn't need its own tool).

[josevalim]

Very good summary!

One quick correction: the equivalent to _checkouts in Mix is to use path dependencies. I often use environment variables to control when to use one or the other and I like the fine grained control more. Here is an example: https://github.com/elixir-ecto/ecto_sql/blob/master/mix.exs#...

But in general yes, we are glad to borrow ideas from each other and we should continue doing it!

[strmpnk]

Thanks for this tip. I find myself a little more reluctant to rely on environment variables for this sort of thing but it'd be fair to say the same about filesystem state.

My only problem with this solution is that it changes the mix configuration itself (which is version controlled) which is fine if others are in need of similar overrides when working on the project. For one-off/local things, it can be a bit heavy for temporary overrides.

Still, it's a fair trade-off since it's a lot easier to code up logic like this with mix compared to rebar3.

[giancarlostoro]

I agree with the rest of his statement of how integrated Elixir seems with Erlang. I originally avoided Elixir cause I thought it was a hassle to install, but nowadays I can brew install on macOS, and on Linux I can leverage a sane package manager.

I am not entirely sure about tooling myself. I would love to see a serious IDE for Erlang, I wonder what the tooling looks like. I've mostly just used the Erlang terminal to learn.