Ten Years of Erlang

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.

It's a gem of an observation that newcomers to an environment often only make it to the first few rungs of the system complexity / actualization ladder. Once you look, you see this everywhere, and not just in IT but with any sort of design exercise or institutional process, any complex system that's full of Chesterton's fences, and people will either evolve to debate their rationale from a position of experience, or be selected (or self-selected) away into fresh environments where the novelty and discovery-until-discouragement can begin again.

It also shows that the first few rungs matter a lot; this is the territory of easy answers, where following a few simple rules leads to rapid productivity, and there will always be people for whom that level is good enough, either through carefully weighed decisions from limited information, or ignorance and deferment of future problems and their solutions. You can't solve everyone's problems for them, but you can try to evangelize, and you can try to build your system in a way that best practices can be incrementally adopted from existing fumblings. Anticipate that most of it will stay mediocre.

History is littered with systems that, in hindsight, seem to have offered sensible solutions to complex problems, yet didn't survive in the end. Much knowledge and wisdom is lost, and others independently discover it when trying to ascend an unrelated stack. Erlang/OTP is truly the sort of environment that masquerades as a programming language yet asks questions at a much higher conceptual level: what do we want systems as a whole to look like if we have to maintain them indefinitely? Its architectural innovations have been copied elsewhere, where they rarely form part of a coherent stack, but at least expose people to the advantages of its model. This may also be the most viable source of adopters of Erlang at higher levels: people who've sought out similar model for its benefits, and could thrive with an offering that pays attention to these concerns throughout.

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).

Not being facetious, but could the joy resemble the fun I associate with developing with Ruby?

Comparing Erlang to C# is a bit unfair. The latter is a general purpose language that can be used to build software on every layer of every platform. The former is a distributed programming DSL (an awesome one granted). There is 0 Erlang-native GUI libraries, there is no documented Erlang pipeline for iOS apps etc.