Ten Years of Erlang

https://ferd.ca/ten-years-of-erlang.html

作者谈到了过去10年Erlang

学习技术就像是爬楼梯：你只有爬到了某一层理解了这层的思想，才能开始去领会上一层的思想。对于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.

对于erlang这么精妙的东西，你是否使用它可能真的不太重要。尽管现在erlang语言被低估或者是没有被有效使用，但是学习它的最大好处在于可以学习设计健壮系统基础知识，然后将这些知识在实践中内化。

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.