I tried to learn Erlang for a month and failed

It is a truth universally acknowledged, that a bored programmer in possession of free time, must be in want of a new side project.

The project that I settled on was to learn Erlang and top it off by building an app. I had no reason for choosing Erlang except that it was a reasonably well-established functional programming language. I estimated that it would take around a month for me to be comfortable with the language and build something that I could show to the world.

This is a story about why I gave up on the side project halfway.

There are countless chasms on the path to mastery that one must leap over to progress further. However, sometimes they are simply not worth the effort.

The first week of learning went very well. The syntax was unlike anything I had seen before. My brain expected certain symbols to be followed by others, like an opening curly bracket after a closing parenthesis or a right arrow. Another example would be the dot . commonly used as a property accessor. With Erlang, all those rules went out the window. Erlang uses the same symbols but in totally different combinations. It made my palms stretch in new directions as I typed. And the absence of looping constructs made my brain stretch in new directions. Even the most trivial examples in the tutorials exposed my inability to think recursively. Erlang does not have for or while keywords. Writing recursive functions is the only way to emulate loops in Erlang. I grew more comfortable with using recursion as I progressed through the tutorials. I count that as my biggest win from this excursion.

// a function in JS
function foo() {
	  console.log("hello world");
}

%% a function in Erlang
foo() ->
    io:format("hello world~n").

The prospect of writing code that was visually closer to mathematical functions was enticing, but my enthusiasm waned soon after. When you stray away from mainstream languages, the availability of tutorials, blog posts, and learning resources drops significantly. Erlang suffered from the same problem. The book I was following was severely outdated, and I had to modify the code samples replacing the deprecated functions with newer alternatives. Erlang’s documentation not being the easiest to go through added to my misery. Fixing outdated code is not an effective technique for learning a new language quickly. Doubts that I was wasting my time already starting to creep in, and OTP was the straw that broke the camel’s back. The book I was following went way too deep into OTP way too quickly. At this point, I decided to switch to a different book and come back after I was a bit more comfortable. But that never happened. Every book or tutorial that I found had the same problem. It felt like everything up to that point was only done so that they could showcase the gen_server and OTP. In Erlang’s world, gen_server is what you call a “behaviour” that is fabled to bestow godly powers upon your code, making it fault-tolerant and whatnot. If my opinion feels unfounded and unjust towards an otherwise brilliant piece of software, I can assure you that most books did worse. I had to check Stack Overflow to figure out what a “behaviour” is. In one of the examples, we wrote a module -module(example_server) with a start_link() function and added a behaviour -behaviour (gen_server). Behaviours work like frameworks where you relinquish control over the flow of the program, example_server:start_link() was never called in the program explicitly. That was something the gen_server would do. The effort required to figure this out didn’t dishearten me, but the fact that I had to figure it out myself did. All of this, along with minor inconveniences, such as figuring out umbrella projects, made me give up on learning Erlang entirely. I am no stranger to monorepos or workspaces, but there is a time and place for everything. You wouldn’t want to read about Gradle in an introductory book on Java.

I was more interested in the FP aspect of Erlang and less in fault-tolerance and concurrency. Distributed applications aren’t special anymore; they are the norm. Erlang has lost its novelty. We are already writing fault-tolerant and distributed applications with or without Erlang. And it’s not the only language that supports message passing and communicating sequential processes. I wanted an accessible, practical, and independent functional programming language. Erlang failed by not being accessible. But I am more disappointed with the books and learning resources and less with the language itself. I might have had a different opinion had the tutorials focused more on the core language and less on showing off the “greatest hits” of the ecosystem.