I love Erlang, and am one of the very few people who (in the past) managed to find work doing it full time. The actor paradigm it provides is surprisingly simple and elegant to write an app, even on a single node, and of course making distributed apps is fairly straightforward as a result of it.<p>I have found that I like Lisp-Flavoured-Erlang (LFE) a bit more, since I <i>still</i> find the prolog-esque syntax a bit frustrating. I've been doing this stuff for like 6 years, and I still occasionally get tripped up on when to do a comma, semicolon, or period occasionally. While I'm not a huge fan of LISP-2 semantics, overall I find the syntax for LFE to be a lot more consistent than raw Erlang.<p>This isn't to crap all over regular Erlang though; Erlang was the first language I had seen that fully embraced pattern-matching, and I find that kind of pattern to be incredibly elegant.<p>If someone reading this hasn't tried out Erlang, do yourself a favor, download and install it, and build a simple TCP chat server. I can virtually guarantee you that it will be easier than anything you've built in C/C++, and it's incredibly satisfying to have something you built in a few hours have the ability to scale correctly.
It's a gem of an observation that newcomers to an environment often only make it to the first few rungs of the system complexity / actualization ladder. Once you look, you see this everywhere, and not just in IT but with any sort of design exercise or institutional process, any complex system that's full of Chesterton's fences, and people will either evolve to debate their rationale from a position of experience, or be selected (or self-selected) away into fresh environments where the novelty and discovery-until-discouragement can begin again.<p>It also shows that the first few rungs matter a lot; this is the territory of easy answers, where following a few simple rules leads to rapid productivity, and there will always be people for whom that level is good enough, either through carefully weighed decisions from limited information, or ignorance and deferment of future problems and their solutions. You can't solve everyone's problems for them, but you can try to evangelize, and you can try to build your system in a way that best practices can be incrementally adopted from existing fumblings. Anticipate that most of it will stay mediocre.<p>History is littered with systems that, in hindsight, seem to have offered sensible solutions to complex problems, yet didn't survive in the end. Much knowledge and wisdom is lost, and others independently discover it when trying to ascend an unrelated stack. Erlang/OTP is truly the sort of environment that masquerades as a programming language yet asks questions at a much higher conceptual level: what do we want systems as a whole to look like if we have to maintain them indefinitely? Its architectural innovations have been copied elsewhere, where they rarely form part of a coherent stack, but at least expose people to the advantages of its model. This may also be the most viable source of adopters of Erlang at higher levels: people who've sought out similar model for its benefits, and could thrive with an offering that pays attention to these concerns throughout.
Re: those infrastructure components written in Erlang not attracting Erlang users in any permanent way—it’s not so much that they have more users than contributors, but rather just the bare fact of them being infrastructure components. A black-box infrastructure component can’t be a “killer app” for a language.<p>Rails is a killer-app for Ruby because it’s a <i>framework</i>; a developer who uses Rails in their project is inherently a Ruby developer. People learned Ruby to use Rails.<p>But you don’t need to write a single line of Erlang to use CouchDB or Riak or Ejabberd. They’re self-contained. (And, in fact, scriptable in not-Erlang languages; CouchDB for example spawns and manages a JavaScript engine to run its “design documents” on.)<p>Thus, these infra components becoming popular doesn’t cause there to be any more Erlang programmers than there were before.<p>In that sense, I would say that Erlang has <i>never</i> had a true “killer app” yet. (Outside of a few specialized domains, like telecom and fintech, where the OTP platform itself is Erlang’s killer app.)<p>And even in the places where Erlang itself is a “killer app”, it’s also not so much a viral thing that the whole industry gets excited about; rather, Erlang is more of a “secret sauce.” Nobody’s learning Erlang in their basement because their friend told them it’d be the next big thing in their industry.<p>How does anyone learn Erlang, then? Well, usually, engineers are <i>forced</i> to learn Erlang at one job (where the system architect there decided on it); they get to liking it; and then, when they later become a system architect themselves in another job, and choose a stack, they choose Erlang, thus forcing a new wave of engineers to learn it.
I find the key point to language adoption is that self-selection that occurs. What type of person and their personality does an ecosystem attract and what is that type of person good at?<p>The BEAM ecosystem is all about fault-tolerance, distribution, and concurrency. These BEAM concepts could be described as "upper ladder" ideas: they require more prerequisite understanding of systems engineering to appreciate. Despite being a fallacy of composition, to compare a given Erlang vs Ruby/Rails developer may be useful to consider.<p>A person who invests in learning Ruby/Rails might be motivated to do so because of that bootstrapping mindset of MVP's and failing fast. Our average Rails developer might be rolling the dice for that "killer app" opportunity more often than our Erlang developer prioritizing concurrency and reliability. This may be because those BEAM features are more useful at a later stage of product development. So while the BEAM features are uniquely powerful if they require an upper-ladder understanding our MVP-developer doesn't yet have - they're unlikely to pick Erlang as tool-set to invest in.<p>If we accept that the BEAM is good at infrastructure and that doesn't result in as many opportunities for these hype-cycle-causing-killer-apps, than what could be changed in the ecosystem to support this goal? Can we get both the later stage benefits of reliability and concurrency in addition to the early-stage productivity benefits? Maybe this early-stage development focus is where Elixir will break out of the infrastructure-niche Erlang seems to be in. Can Elixir's tooling reach a short enough new-product feedback loop more potential killer-apps get deployed into production? I think as Elixir brings in some different personalities to the ecosystem we could see more killer apps but that idea -> production feedback loop seems to be the key component.
Here's to another 10 years of Erlang/Elixir. The programming stack for the boring software developer that wants to clock out at 5 sharp. It's fantastic I tell ya. I have been blessed with opportunities to work with Elixir fulltime and it's hands down the best experience I've had. Compared to C#, Rails, Nodejs, it's miles ahead. (Although C# with dotnet is coming up fast and _crazy_ compared to what it was 9 years ago).<p>This ladder is a great blueprint, great article:<p><pre><code> functional programming
isolated processes and concurrency
reliable concurrency (links, monitors, timeouts)
OTP behaviours and other system abstractions
How to structure OTP systems
How to build releases and handle their life cycle
How to never take the system down, and how to operate it</code></pre>
This is how the page looked when Erlang posts caused HN to become slow.<p><a href="http://www.waybackhn.com/?date=2009-03-11" rel="nofollow">http://www.waybackhn.com/?date=2009-03-11</a>
Good observations.<p>'Getting' OTP, and especially how to structure an application the right way is definitely tough, because there's not a lot out there like it if you come from the world of C or scripting languages. It's not just code organization, but thinking about how to structure all the processes so that things fail in a 'good' way, and you have everything talking in the right way.<p>A big thanks to Fred for his book, and the many hours he has spent helping people on the mailing list, IRC and elsewhere.<p>I miss my time working with Erlang. I think it's still an indicator of an environment willing to try new things, but like he writes, you have to be wary of the places that are 'serial early adopters' too; I've encountered a few of those in my Erlang career.
Fantastic article; it paints a great picture of the journey taken & accomplished achieved.<p>My personal take is that the next major milestone for Erlang/Elixir will be a significantly more performance BEAM. Be it JIT or reworked Hipe.<p>Elixir (& Phoenix) brought a ton of interest from the Ruby community. The only remaining aspect that would keep a Ruby developer using Ruby is the perf vs Erlang. Today, for many raw perf task there isn’t a meaningful difference in speed (note I’m not taking scalability). As soon as the speed difference becomes meaningful, Erlang will get another wave of people.
As someone who loves servers and back-end work, Erlang is amazing to me. I too read that book by Joe Armstrong, but I never really got to use Erlang for much since I don't get paid to use it. Recently I was trying out Elixir and going through the documentation and was pleasantly surprised how much of it is Erlang-like.<p>I wish the industry was much more Erlang friendly.
Interestingly enough I started using Erlang around the same time and while I've continued to use it for the project I started then on and off, I've not had a lot of reason to use it on other projects. I don't ever think it'll be as wide spread or as popular for many of the reasons listed. I do think it will continue to be a tool used to create great projects with very few hands. In the right hands and for the right projects it is an incredibly productive tool.
"But the vast majority of them will be a continuous flow of serial early adopters who surf from tech to tech, sniffing the best opportunity to gain a competitive advantage by being first to use a type of framework, language, or toolkit." - Oh god, that hit me so hard.
I was there. Had a full time Erlang job even before the line numbers in stack traces. Later migrated to more enterprise-y languages... and for me, the big missing thing in Erlang is the IDE. And a company (or a big community) that is dedicated to catering to the developers. This was never a thing in Erlang.
Riak convinced me that any language pretending that it could magically create better products was full of shit.<p>Riak is not great. It performs well, but doesn't scale well. It has tons of operational overhead, a lot of bugs (and it didn't help that a slowly disintegrating company left less time to fix those bugs "until next release"), and any changes to the cluster while it's being used heavily leads to instability/unavailability. And many of its features were not implemented great; the SOLR functionality is a pig, for example, and "enterprise" replication is flaky.<p>On our team, we had a few engineers who could write Erlang, but they slowly moved to other teams, so troubleshooting production issues became a black box of pain. I'm so glad the product we had using it was sunset.
Was a bit more than 10 years for me. I had coworkers struggling with netsnmp to build out a mock control plane for a new and exciting data center management platform. I whipped up a mocked out version with OTP in a really short time and eventually the mocked version was good enough to plug into the real backend so we shipped it.<p>It was elegant and clear!
I have never written a single line of Erlang, but I run my own ejabberd. However, looking at the package build scripts and build instruction, I have the impression that compiling a project like ejabberd can be complicated.<p>Does someone know if this is an inherent Erlang problem or just due to some weird project setup in this case?
I started learning erlang and was stuck at 2nd rung, problem with erlang is(at-least for me) that there are not enough projects/use cases to learn/build for practice.
So, what's the quickest way to get into OTP?<p>To me it looks like Erlang itself isn't all that interesting, and OTP is where all the fun and magic is.
Functional programming has too long of a learning curve to the average programmer. A language should be judged by how long it takes <i>average</i> programmers to become proficient in it, not the "Sheldon Cooper" types. In typical medium and large organizations, it's difficult keep being selective about programmer hiring. (There are org structural/political reasons that would take several paragraphs to explain.)<p>This problem existed since Lisp was invented. The benefits would have to be large to overcome the downsides of this learning curve, and so far they are not, except in certain niches.<p>I hate the rain the functional parade, but it's been tried and retried for many decades, but will just <i>not</i> fly in the majority of the real world. I'm just the messenger. The jet-powered chainsaw works wonderful in the lab, but actual lumberjacks either can't figure out how to start it or blow their arms off.<p>If you disagree, please reply instead of negativate me. I would greatly appreciate that.