Ten Years of Erlang




Now that's a tongue in cheek approach, and I don't think learning a piece of tech is endless suffering (at least, it shouldn't be). I just liked the pun. But to put it simply, there is often a more"core"track or sequence of topics you'd study learning the technology, creating a "ladder of ideas", where more worthwhile concepts are put higher and higher, but as they are harder to reach, fewer people actually make it there.

In Erlang, what I would consider the ladder might look like this:

  1. functional programming
  2. isolated processes and concurrency
  3. reliable concurrency (links, monitors, timeouts)
  4. OTP behaviours and other system abstractions
  5. How to structure OTP systems
  6. How to build releases and handle their life cycle
  7. How to never take the system down, and how to operate it

但是erlang对新手不友好,让它许多精妙之处没有办法展示出来,甚至很多killer apps使用的还是3-4层的思想

I think that for Erlang, the first three rungs were probably the easy ones to get into. The fourth one took a few years to develop and to be perceived as worthwhile. The fifth one is where things became extremely hard. Erlang's tooling and ecosystem was lacking. People in the Erlang community had self-selected to be those who could tolerate that barren environment, and as such were insensitive to the plight of newcomers. To keep this post short (well, long rather than absurdly long), my Erlang User Conference keynote is probably the most complete rant I have on the ecosystem: https://youtu.be/Z28SDd9bXcE

But all of this is to say: I think we, as a community, probably hamstrung ourselves by making it very difficult for people to go above the basic levels. Some of the lessons to be learned can't be rushed, and to some extent the blind were leading the blind because Erlang was so small that there were not enough people to share all the experience that was required. Things are easier today, and if you're getting in outside of a hype cycle, you're much more likely to be able to find good help because there are fewer people asking for it all at once.


It's probably not too important, in the grand scheme of things, whether you are using a language like Erlang or not. While I do feel it's under-used and under-rated, the biggest benefit of it is not in running a system that uses it. The biggest benefit comes from learning about the fundamentals of solid system design, and internalizing its lessons in a practical context.

One type of questions I heard a lot over the years have to do with finding guidance. How can I learn about designing protocols? Is there any good reading you'd recommend on building distributed systems? How can you go the extra mile to make something very robust and fault tolerant? How do I know that my design is modular and my abstractions aren't leaking? What is good error handling? What's a good way to know when optimization is premature? What does it mean to make something declarative?

We like short and digestible solutions like cookbooks and best practices, but most real answers turn out to be a variation of "I've learned over the years". I can honestly say that there has been nothing in my career that could ever compare to spending the time in the world of Erlang and absorbing the experience of its veteran community by osmosis. It's not a large community by numbers, but it's certainly rich by any other metrics. In a few years, I've gone from a junior developer to working in senior roles, speaking around the world, finding ways to teach that experience back, and I owe most of that to the community.