<story><title>Ten Years of Erlang</title><url>https://ferd.ca/ten-years-of-erlang.html</url></story><parent_chain></parent_chain><comment><author>tombert</author><text>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.&lt;p&gt;I have found that I like Lisp-Flavoured-Erlang (LFE) a bit more, since I &lt;i&gt;still&lt;/i&gt; find the prolog-esque syntax a bit frustrating.  I&amp;#x27;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&amp;#x27;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.&lt;p&gt;This isn&amp;#x27;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.&lt;p&gt;If someone reading this hasn&amp;#x27;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&amp;#x27;ve built in C&amp;#x2F;C++, and it&amp;#x27;s incredibly satisfying to have something you built in a few hours have the ability to scale correctly.</text></comment>
<story><title>Ten Years of Erlang</title><url>https://ferd.ca/ten-years-of-erlang.html</url></story><parent_chain></parent_chain><comment><author>niftich</author><text>It&amp;#x27;s a gem of an observation that newcomers to an environment often only make it to the first few rungs of the system complexity &amp;#x2F; 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&amp;#x27;s full of Chesterton&amp;#x27;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.&lt;p&gt;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&amp;#x27;t solve everyone&amp;#x27;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.&lt;p&gt;History is littered with systems that, in hindsight, seem to have offered sensible solutions to complex problems, yet didn&amp;#x27;t survive in the end. Much knowledge and wisdom is lost, and others independently discover it when trying to ascend an unrelated stack. Erlang&amp;#x2F;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&amp;#x27;ve sought out similar model for its benefits, and could thrive with an offering that pays attention to these concerns throughout.</text></comment>