|
As the creator of Phoenix, I've never written an Erlang program fwiw. That said, I frequent the Erlang docs and most seasoned Elixir developers will do the same because the standard library is a wealth of features, and the documentation while not 2022 polished, remains a remarkable resource. > I don't know what a solution is, but perhaps a concerted effort to create a documentation and library ecosystem that never links back to Erlang would help. And where there are critical systems that use an Erlang library, perhaps rebuilding it in Elixir is in order? This would not be helpful. Erlang has over three decades of features, heritage, and libraries. Elixir helped usher in first class documentation as a core language feature, but that doesn't make rock solid Erlang libraries somehow things that should be avoided. Rewriting for rewriting sake is also not a good idea. One of the benefits of bootstrapping off an already amazing platform is exactly because you don't have to invent the universe. See Clojure and Java. In fact, Elixir has helped Erlang up its documentation game, and there is already work done to help the ecosystems share documentation tools. Both ecosystems work by rising together, not masking one or the other. We see this in tools like `telemetry`, documentation generators, and recently the Erlang Ecosystem Foundation:
https://erlef.org |
When writing Elixir, yes, you'll be exposed to Erlang syntax/docs sooner or later. But you're not writing Erlang, so you never need to learn how to:
Creating something functional from scratch in a language is 100x (1000x?) more challenging than learning how to roughly read it.I've been programming full-time in Elixir for a couple years. All told, I think I spent 3-5 hours one afternoon learning the basics of Erlang's syntax so I could better read the docs. Haven't had to think about it consciously since.