It is basically erlang with better tooling and still an easy use of erlang.
- 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).
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!
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.
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.