top | item 31320552

(no title)

rkallos | 3 years ago

Chiming in with 6 years of professional Erlang experience. I'm somewhat familiar with Elixir, having worked on some Elixir codebases for a few months.

> The notion that to learn a language you also need to learn a second one is not great. [...] It's just bizarre.

I disagree. I don't think it's bizarre. I expect to sometimes have to poke around in C code when writing Erlang or Python. It's also fairly common for C/C++ developers to look at the assembly output of some piece of code using https://godbolt.org/.

> Reading the code is NOT an answer.

Again, I disagree, and I think this perspective is harmful to career development. Knowing how things work on a deep(er) level is a superpower. When you're writing Elixir, do you never open up a .ex file in the standard library to see how something is implemented? Are you not at all interested in what powers things like Phoenix.PubSub?

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

I suspect that a library ecosystem that doesn't require Erlang would be a huge effort to implement and test, and would wind up pulling in all of the ideas from Erlang that you haven't learned/mastered yet. A better alternative would be to accept the fact that Elixir builds on top of Erlang, and understand that a deeper knowledge of Erlang is going to help you improve as an Elixir developer.

> And where there are critical systems that use an Erlang library, perhaps rebuilding it in Elixir is in order?

I'm definitely biased, but I would be much less trusting of an Elixir copy of a 'critical' Erlang library. Many of the selling points of Elixir that lead to very concise code (read: macros, 'using', and others) are things that make it difficult for me to develop a deep understanding of a library. It's cool to use DSLs like Ecto and Plug, but I have a much harder time understanding those libraries as a result. Erlang's unambiguous syntax and its basic text-substitution-based macro system are much easier for me to understand, and while it takes more effort to write APIs and code that are as concise as what's available in Elixir, I know that I can open up an Erlang file and trust that much less is hidden from me.

discuss

order

No comments yet.