17 ms·

Ten Years of Erlang

567 points by iamd3vil 7y ago

bfrog 7y ago
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.
- melling 7y ago
  If you search HN history, it appears Elixir seems to get much more buzz. Saw this from a few days ago: https://news.ycombinator.com/item?id=20357055 https://news.ycombinator.com/item?id=20357055 Elixir is just a slightly changed Erlang syntax?
  - sergiotapia 7y ago
    Elixir is a language that compiles down to bytecode that runs on the BEAM VM.
  - brightball 7y ago
    Cleaner syntax, macros and a whole lot of developer productivity focused tooling.
    - macintux 7y ago
      Disagree with “cleaner”.
      - y4mi 7y ago
        Disagree with "disagree" ...see where that leads us? Please actually voice reasons how it's not cleaner, as it's most definitely less verbose, And having less clutter is generally seen as cleaner
        macintux 7y ago
        It’s more verbose when defining functions, calling anonymous functions, and referencing atoms. Calling functions with and without parens makes for a less clean syntax. Less consistency (plus mandates the dot notation for calling anonymous functions).
        y4mi 7y ago
        > It’s more verbose when defining functions, calling anonymous functions, and referencing atoms. and we're finally finding out how both opinions are correct when people say that elixir code is cleaner, they're normally talking about the significantly reduced amount of code they have to write because of the macros. its not specifically about how they're defining a function or calling them anonymously while i cant say that i agree with atom reference, (its 1 char in elixir, two in erlang), you're definitely correct about that annoying idea they've had about dropping parenthesis on functions without parameters... that was just misguided i think.
        macintux 7y ago
        Using an atom doesn’t require any extra characters in Erlang. Update: just realized you mean the single quotes when you need an arbitrary atom name. Understood. I definitely wish Erlang had the same macro capability. I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.
        klibertp 7y ago
        > I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir. Please, don't use such an excuse for not trying out a language. :( The unpleasantness you speak about is akin to motion/sea sickness - the signals your brain receives disagree with the brain's predictions of what they should be. The discrepancy manifests as a feeling of unease at the very least, or you may throw up non-stop for 3 days on the deep end, but, eventually, the sea sickness disappears completely. I believe I experienced something very similar to this many times while learning many strange, exotic languages as a hobby. When the syntax or semantics were completely outside of what I already learned, I was irritated that "I don't even know how to ...something...". When the new language was close to what I already learned, I was irritated that "it doesn't work as it should" due to the differences. Basically, I experienced some kind of rejection reaction from my brain every time. But then, after a few days to a few weeks, that feeling faded and disappeared. There's a technique I thought up and used a few times which helped me with especially hard, complex, or simply exotic syntaxes. I'm not sure if it will work for everyone, but it helped me with Lisp and Prolog when I first learned them. What I did was to print several tens of pages of (syntax-highlighted and preferably heavily commented) example code and scatter them around the house at spots I was likely to look at. Next to the mirror in the bathroom, on the fridge doors, on my desk, and so on. I wasn't trying to actively read that code very much, just glanced at it from time to time, and sometimes tried to read a bit more when I was bored. When I returned to actually learning the language the next weekend (I think), it went much easier than before. I still wasn't able to write in the language, obviously, but reading - even if I didn't really understand more of it than before - stopped being a hassle, the feelings of rejection disappeared, and I was able to learn quickly from that point on. Well, that's just my theory based on personal experience, so it may be utterly stupid or just my imagination, so take it with a grain of salt. Still, I believe the feeling of unpleasantness from the syntax should be very easy to neutralize and as such it's not, IMHO, a good reason for "not getting into" a language which is otherwise interesting (whether Elixir is such for you is another matter).
      - jjnoakes 7y ago
        It'd be nice if dissenting opinions came with elaboration to continue the discussion instead of shut it down.
        njharman 7y ago
        The dissenting opinion that it has "cleaner" syntax came with no elaboration.
      - mrdoops 7y ago
        Syntax is a subjective concern for sure. My experience has been that Erlang takes a little more effort and time to read fluidly, but only when first learning. I think this is because Erlang uses visually subtle tokens for important language distinctions (upper vs lower caps and periods being the primary culprits). Now that I've spent enough time in the ecosystem reading Erlang isn't really a problem, but Elixir's syntax felt like it took less mental effort to read when starting out. I think Elixir making different token choices for these distinct ideas is the main reason for readability improvements. Especially since Erlang has less different tokens overall which you'd think would help reduce the noise.
  - yawaramin 7y ago
    Elixir has a homoiconic syntax and hygienic macros, like a Lisp. In fact much of the user-facing syntax of Elixir is just macro definitions. You can do a lot of things with it at compile time, and people take advantage of it to do really cool things like compile Phoenix routes down into a single static dispatching function so that requests can be routed quickly.
    - grzm 7y ago
      Could you expand on what you mean by Elixir being homoiconic? That doesn’t seem readily apparent to me, and is contradicted by posts such as http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were-homoiconic/ http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were...
      - yawaramin 7y ago
        Yup you're right, my bad–I mixed up homoiconicity and hygienic macros–apparently like many before me!
giancarlostoro 7y ago
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. I wish the industry was much more Erlang friendly.
- di4na 7y ago
  Well elixir explicitly try to not move away from the erlang paradigm and to be fully and "naturally" inter-operable with it. It is far more integrated with erlang than Scala is with Java as an example. It is basically erlang with better tooling and still an easy use of erlang.
  - mononcqc 7y ago
    We probably had our discussions about this before, tooling definitions diverge at times, and I have a vested interest in some of them, but I will just state my disagreement on the better tooling side of things ;)
    - giancarlostoro 7y ago
      I agree with the rest of his statement of how integrated Elixir seems with Erlang. I originally avoided Elixir cause I thought it was a hassle to install, but nowadays I can brew install on macOS, and on Linux I can leverage a sane package manager. I am not entirely sure about tooling myself. I would love to see a serious IDE for Erlang, I wonder what the tooling looks like. I've mostly just used the Erlang terminal to learn.
    - strmpnk 7y ago
      To say a few things that Fred isn't saying here (these are my opinions not his): - Early Erlang tools had a lot of issues when Elixir showed up but rebar3 made quick progress and is a very good set of tools integrated into one command-line interface - rebar3 has supported creating releases for a very long time which Elixir's mix tool is just catching up to (sure distillery supported things but so did relx and half a dozen other Erlang tools) - rebar3 has built-in support for things like dialyzer which still require extra work to use from mix - rebar3's _checkouts feature is very nice and has no good mix equivalent - rebar3 offers a declarative configuration setup which makes it easier for other tools to integrate their data and read other data w/o requiring plugins to be loaded everywhere (and this is to say it still supports scripting where needed, which will still result in a declarative output) - rebar3's version resolution system is more practical and puts the final control of version selection in the developer's hands rather than strictly package manager metadata which can lag or suffer unfortunate problems from version operators and unfortunate problems that come up from blind-semver adoption (this is a longer topic so I apologize for the poor summary here but I do think there is a good argument for rebar3's approach) - rebar3 works and upgrades independently from Erlang/OTP releases allowing more fluid iteration whereas mix is very much locked to Elixir I participate in the Elixir community and every time I hear the tooling story I think about all of the things I miss from Erlang tools when using Elixir. It'd be more accurate to say that Elixir has revitalized Erlang with a bit of competition and some diversity in background. Either way, there is room for improvements in both camps. I hope Elixir's mix catches up with rebar3 in some of these areas and I hope Erlang doesn't ignore some of the caveats that are still around as given facts of life (perhaps getting better support for the wider set of BEAM languages would be a start so each doesn't need its own tool).
alberth 7y ago
Fantastic article; it paints a great picture of the journey taken & accomplished achieved. 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. 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.
- Jedi72 7y ago
  I work with Ruby and Elixir daily and Elixir is 10x faster. Phoenix recently added functionality to display response times in microseconds, partially as a showcase for its good performance. I dont doubt you can get more performance in C++ or something but its still lighting compared to Ruby.
  - strmpnk 7y ago
    I think this is a valid observation but the reason isn't necessarily that the Ruby language can't be used in a similar way, it's more so a death by 1000 cuts where Ruby encourages very small costs to be paid everywhere in return for a nicer programming experience. The issue becomes hard to fix because all of these small costs add up but none will show as up a single bottleneck in practice, making profiling a blunt tool for this kind of performance problem. Elixir isn't immune to this either but the functional aspects of design do help keep some of these choices local to the code that chooses to trade some time or memory away for other conveniences. An example I saw recently of this sort of adoption is map access, which is entirely okay if the trade-off is understood. I put in some time to show that much of the understanding of performance profile of the Access behavior gets colored by these expectations that the small things don't matter: https://lobste.rs/s/bctcke/performance_elixir_s_access_behavior#c_tolnwa https://lobste.rs/s/bctcke/performance_elixir_s_access_behav...
  - ngrilly 7y ago
    What Phoenix did to improve display response times that much?
tombert 7y ago
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. I have found that I like Lisp-Flavoured-Erlang (LFE) a bit more, since I still 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. 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. 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.
- unixhero 7y ago
  Not being facetious, but could the joy resemble the fun I associate with developing with Ruby?
  - tombert 7y ago
    I'm not super familiar with Ruby (had a bad initial experience with some awful Rails code and never went back), but maybe? From what I've read in blog posts, it feels like the coolness of Ruby comes from the feeling of "holy crap, something that would have taken me two days in Java/C/C++ took me an hour with Ruby" (hopefully I'm summarizing this more or less correctly). Erlang has definitely given that feeling to me. Distributed programming can be really, really hard, and gluing things together with sockets and whatnot can lead to a lot of really difficult bugs. Since Erlang embraces distribution and concurrency as part of its paradigm, it sometimes kind of feels like outright magic. Sometimes things feel like they went a bit...too perfect, like you missed something, when you really haven't. I'm not going to say that it fixes every issue with concurrency; you can still have race conditions and Mnesia and ets can be a bit finnickey if you're not careful, but I think I can honestly say that, for distributed apps, I can accomplish 20x as much as I could with most other platforms.
sergiotapia 7y ago
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). This ladder is a great blueprint, great article: 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
- PasserBy2020 7y ago
  Comparing Erlang to C# is a bit unfair. The latter is a general purpose language that can be used to build software on every layer of every platform. The former is a distributed programming DSL (an awesome one granted). There is 0 Erlang-native GUI libraries, there is no documented Erlang pipeline for iOS apps etc.
  - toast0 7y ago
    > There is 0 Erlang-native GUI libraries Have you seen ex11? [1], it's Erlang native, and at least 0.1 of a GUI library. X11 and Erlang actually go together really well, although a lot of important functionality for a real application is missing; I used this to display images generated by an Erlang application, and it felt a lot nicer to me than using wxWidgets; I added a few bits of functionality to the library while I was in there, and it wasn't that hard to turn the X11 protocol docs into Erlang code for the things I needed. I imagine if someone had a real need here, it wouldn't be that hard to get it into shape. Caveat: X11 is dying, etc. [1] The most active fork appears to be here https://github.com/skvamme/ex11 https://github.com/skvamme/ex11 -- it's been somewhat retargeted to mobile, but the examples for desktop should still work as well as they did.
  - bitwalker 7y ago
    > The former is a distributed programming DSL (an awesome one granted) I mean, that's a completely incorrect characterization of Erlang, regardless of how you feel about the comparison to C#. Erlang is just as much a general purpose language as C#, it is just a different paradigm, i.e. functional programming rather than (mostly) object-oriented. > There is 0 Erlang-native GUI libraries This isn't true at all. There is a tight integration with the wxWidgets framework (in fact, one of Erlang's handiest tools is built with it, Observer). Scenic, as mentioned elsewhere in the comments, is for Elixir (perhaps there is an Erlang-native API for it, not sure), but provides a native framework for OpenGL, and a UI paradigm that meshes nicely with processes and supervision. Of course, Erlang is not perfectly suited for all environments (e.g. iOS apps), but that is true of essentially all general purpose languages - there are some places where they aren't well suited or have flaky support. I wouldn't build an iOS app in C# either, it makes little sense to use anything other than Swift/Obj-C in that environment. Likewise if I'm primarily building Windows-based apps, I would use C# before I would reach for Erlang. But for backend services, infrastructure, networking, etc., it is extremely well suited, and I think the domains that it can provide a compelling solution for will continue to grow (e.g. embedded).
niftich 7y ago
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. 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. 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.
- chessturk 7y ago
  > people who've sought out similar model for its benefits, and could thrive with an offering that pays attention to these concerns throughout. I discovered BEAM while looking into a way to run concurrent, distributed Golang/gRPC services in a supervisor-worker set up. I've continued tinkering with OTP ever since. Edit: added quoted portion.
  - Jailbird 7y ago
derefr 7y ago
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. Rails is a killer-app for Ruby because it’s a framework; a developer who uses Rails in their project is inherently a Ruby developer. People learned Ruby to use Rails. 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.) Thus, these infra components becoming popular doesn’t cause there to be any more Erlang programmers than there were before. In that sense, I would say that Erlang has never 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.) 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. How does anyone learn Erlang, then? Well, usually, engineers are forced 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.
- seisvelas 7y ago
  I don't think this counts, but I imagine a significant portion of people learning today learn it because they are Elixir programmers.
  - derefr 7y ago
    It actually might. You can write Elixir for years without learning Erlang syntax, but if you’re a perfectionist, you’re gonna notice bugs in your Erlang deps just as much as in your Elixir deps, and you’re gonna want to submit PRs for them, and that leads you to learning Erlang. Also, IMHO, if you want to have a solid foundation when learning Elixir, it’s simpler to learn Erlang/OTP as a cohesive whole (from e.g. ferd’s Learn You Some Erlang book) and then “chase it” with an Elixir book; rather than trying to understand OTP through the lens of how it’s exposed in Elixir. Everyone in the elixir-lang Slack that asks how to get started learning Elixir, I tell them to learn Erlang first. So “being a simpler jumping-off point to Elixir knowledge” is also kind of a killer app. I would guess that this is only true in cases where there are killer apps for a secondary language on a runtime, but no killer apps for the primary language. Like, I wouldn’t say that Clojure is a killer app for Java. But then, is that because Java is already popular? Or is that because Clojure developers don’t necessarily end up knowing Java as well as Elixir developers end up knowing Erlang?
strikelaserclaw 7y ago
"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.
- tabtab 7y ago
  What's the common slang for that? "Buzzword Surfer"?
  - strikelaserclaw 7y ago
    middle manager?
    - tabtab 7y ago
      Most buzzword pushers are architects or similar in my experience. I suppose that's arguably "middle manager".
  - pickledish 7y ago
    I've heard it referred as a "magpie developer": https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/ though that's less for a competitive advantage and more because new tech is shiny
animesh 7y ago
This is how the page looked when Erlang posts caused HN to become slow. http://www.waybackhn.com/?date=2009-03-11 http://www.waybackhn.com/?date=2009-03-11
- dmix 7y ago
  That was my favourite moment in HN history. I believe it was even pg who started the whole “post erlang articles so HN appears boring” thing. Edit: yes of course, he mentioned it in the text post in your link but as a joke: https://news.ycombinator.com/item?id=512145 https://news.ycombinator.com/item?id=512145
davidw 7y ago
Good observations. '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. A big thanks to Fred for his book, and the many hours he has spent helping people on the mailing list, IRC and elsewhere. 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.
peterwwillis 7y ago
Riak convinced me that any language pretending that it could magically create better products was full of shit. 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. 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.
- ulkesh 7y ago
  Agreed, mostly. Riak was used in one of the first implementations of AT&T Messages (Web) as a secondary-index and key-value store. It performed so horribly that the whole thing ended up being rewritten using Oracle. The truth is, Riak was designed for basic key-value storage. Everything else they added on worked pretty badly, especially their javascript integration. All that being said, I do not blame Erlang for Riak. I blame Basho. Their support was clueless, and their platform simply didn't perform as advertised.
loxs 7y ago
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.
arendtio 7y ago
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. Does someone know if this is an inherent Erlang problem or just due to some weird project setup in this case?
- mononcqc 7y ago
  Ejabberd runs with a lot of legacy. Essentially the first build tool that could pull deps in Erlang dates from 2007-2009, and it took another few years before more modern tools came to be in what their current form is. All these bigger projects tend to have a bit weirder idiomatic build setups because they had to haphazardly reimplement bits of (at the time) yet non-existing build systems by hand.
  - arendtio 7y ago
    Okay, but if I would start a project today, there would be better tools? Are those documented in the Erlang documentation or are there any recommendations on which tool I should use?
    - mononcqc 7y ago
      As one of its maintainers I’m partial to rebar3 (http://www.rebar3.org/ http://www.rebar3.org/) It’s become near-official for OSS Erlang work and the OTP team has moved the repo under their GitHub organisation (https://github.com/erlang/rebar3 https://github.com/erlang/rebar3) Erlang.mk tends to be the other option otherwise.
mrdoops 7y ago
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? 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. 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. 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.
- reallydude 7y ago
  > what could be changed in the ecosystem to support this goal? 1. Change the syntax. Elixir wasn't far enough. Not at all and BEAM doesn't need to know, so we have a chicken-egg problem of people entrenched don't want to spend time that will help the language and underlying strategies become more widely adopted. Perhaps this was the production feedback loop you were referencing. We still don't have a good methodology for measuring all sorts of things in software dev. 10 years, 20 years, the language may just never do more than incremental changes (like elixir). 2. Handling text is still awful in these languages.
sam0x17 7y ago
For what it's worth, I decided to pick up Elixir based on this post.
tabtab 7y ago
Functional programming has too long of a learning curve to the average programmer. A language should be judged by how long it takes average 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.) 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. I hate the rain the functional parade, but it's been tried and retried for many decades, but will just not 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. If you disagree, please reply instead of negativate me. I would greatly appreciate that.
- carapace 7y ago
  Hi there, I sometimes try to help normals relate to me by asking, "You know Sheldon Cooper from Big Bang Theory? I'm like a stupid, slighty-less-social-idiot Sheldon Cooper." I identify with Dr. Cooper. (BTW it sucks being like that. Don't ever think we do it because we like it. There are a few perks but it mostly sucks. Also, it's like living in "Idiocracy". I can't watch that movie because it's too painful. That's my life. From my point of view y'all are running around pouring Gatorade on the plants talkin bout "It's got lectrolites!" It's getting seriously scary now IRL too: where the fuck are all the fucking insects!? We should all be fucking terrified right now.) Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive. Also, FP is coming on stronger today than ever before. You are in actual fact just wrong.
  - tabtab 7y ago
    Re: "Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive." This is the theory that the elite are so productive that they can replace say 10 non-elites. The main problem with this is that most problems to be automated (or upgraded) are not well-defined. It takes iterative interaction with analysts, users, testers etc., and this is where probably 2/3 of the effort takes place. Communication and teamwork is more of a bottleneck than raw coding, and the Sheldon Cooper types rarely do well on that. If the requirements were clearly defined, the 10x-Elite Theory would possibly work in practice. But it's a rare day in May one gets a clearly-defined specification that doesn't shift around a lot. If you could find a domain having clearly-defined specs, then you could implement that 10x Elite Theory and crush the competition by cranking out software for a fraction of the traditional competitions' price. For example, make an office suite fully compatible with MS-Office, and charge 1/2 of what Microsoft does. You'd be a billionaire. (Past attempts were not sufficiently compatible, which may be a tall order because one has to mirror bugs in MS's software to be so.)
msie 7y ago
RIP Joe Armstrong
parentheses 7y ago
This is a fantastic article. A question for rubyists out there: what does the "ladder of ideas" for ruby look like?
perlgeek 7y ago
So, what's the quickest way to get into OTP? To me it looks like Erlang itself isn't all that interesting, and OTP is where all the fun and magic is.
- andrenth 7y ago
  There are some books focused on OTP: * Erlang and OTP in Action; * Designing for Scalability with Erlang/OTP: Implement Robust, Fault-Tolerant Systems; * Designing Elixir Systems with OTP (in beta).
butterisgood 7y ago
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. It was elegant and clear!
maddy1512 7y ago
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.
T3RMINATED 7y ago
one of the worst inventions in the 21st century, erlang.

567 points by iamd3vil 7y ago

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.

melling 7y ago
If you search HN history, it appears Elixir seems to get much more buzz. Saw this from a few days ago: https://news.ycombinator.com/item?id=20357055 https://news.ycombinator.com/item?id=20357055 Elixir is just a slightly changed Erlang syntax?
- sergiotapia 7y ago
  Elixir is a language that compiles down to bytecode that runs on the BEAM VM.
- brightball 7y ago
  Cleaner syntax, macros and a whole lot of developer productivity focused tooling.
  - macintux 7y ago
    Disagree with “cleaner”.
    - y4mi 7y ago
      Disagree with "disagree" ...see where that leads us? Please actually voice reasons how it's not cleaner, as it's most definitely less verbose, And having less clutter is generally seen as cleaner
      - macintux 7y ago
        It’s more verbose when defining functions, calling anonymous functions, and referencing atoms. Calling functions with and without parens makes for a less clean syntax. Less consistency (plus mandates the dot notation for calling anonymous functions).
        y4mi 7y ago
        > It’s more verbose when defining functions, calling anonymous functions, and referencing atoms. and we're finally finding out how both opinions are correct when people say that elixir code is cleaner, they're normally talking about the significantly reduced amount of code they have to write because of the macros. its not specifically about how they're defining a function or calling them anonymously while i cant say that i agree with atom reference, (its 1 char in elixir, two in erlang), you're definitely correct about that annoying idea they've had about dropping parenthesis on functions without parameters... that was just misguided i think.
        macintux 7y ago
        Using an atom doesn’t require any extra characters in Erlang. Update: just realized you mean the single quotes when you need an arbitrary atom name. Understood. I definitely wish Erlang had the same macro capability. I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.
        klibertp 7y ago
        > I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir. Please, don't use such an excuse for not trying out a language. :( The unpleasantness you speak about is akin to motion/sea sickness - the signals your brain receives disagree with the brain's predictions of what they should be. The discrepancy manifests as a feeling of unease at the very least, or you may throw up non-stop for 3 days on the deep end, but, eventually, the sea sickness disappears completely. I believe I experienced something very similar to this many times while learning many strange, exotic languages as a hobby. When the syntax or semantics were completely outside of what I already learned, I was irritated that "I don't even know how to ...something...". When the new language was close to what I already learned, I was irritated that "it doesn't work as it should" due to the differences. Basically, I experienced some kind of rejection reaction from my brain every time. But then, after a few days to a few weeks, that feeling faded and disappeared. There's a technique I thought up and used a few times which helped me with especially hard, complex, or simply exotic syntaxes. I'm not sure if it will work for everyone, but it helped me with Lisp and Prolog when I first learned them. What I did was to print several tens of pages of (syntax-highlighted and preferably heavily commented) example code and scatter them around the house at spots I was likely to look at. Next to the mirror in the bathroom, on the fridge doors, on my desk, and so on. I wasn't trying to actively read that code very much, just glanced at it from time to time, and sometimes tried to read a bit more when I was bored. When I returned to actually learning the language the next weekend (I think), it went much easier than before. I still wasn't able to write in the language, obviously, but reading - even if I didn't really understand more of it than before - stopped being a hassle, the feelings of rejection disappeared, and I was able to learn quickly from that point on. Well, that's just my theory based on personal experience, so it may be utterly stupid or just my imagination, so take it with a grain of salt. Still, I believe the feeling of unpleasantness from the syntax should be very easy to neutralize and as such it's not, IMHO, a good reason for "not getting into" a language which is otherwise interesting (whether Elixir is such for you is another matter).
    - jjnoakes 7y ago
      It'd be nice if dissenting opinions came with elaboration to continue the discussion instead of shut it down.
      - njharman 7y ago
        The dissenting opinion that it has "cleaner" syntax came with no elaboration.
    - mrdoops 7y ago
      Syntax is a subjective concern for sure. My experience has been that Erlang takes a little more effort and time to read fluidly, but only when first learning. I think this is because Erlang uses visually subtle tokens for important language distinctions (upper vs lower caps and periods being the primary culprits). Now that I've spent enough time in the ecosystem reading Erlang isn't really a problem, but Elixir's syntax felt like it took less mental effort to read when starting out. I think Elixir making different token choices for these distinct ideas is the main reason for readability improvements. Especially since Erlang has less different tokens overall which you'd think would help reduce the noise.
- yawaramin 7y ago
  Elixir has a homoiconic syntax and hygienic macros, like a Lisp. In fact much of the user-facing syntax of Elixir is just macro definitions. You can do a lot of things with it at compile time, and people take advantage of it to do really cool things like compile Phoenix routes down into a single static dispatching function so that requests can be routed quickly.
  - grzm 7y ago
    Could you expand on what you mean by Elixir being homoiconic? That doesn’t seem readily apparent to me, and is contradicted by posts such as http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were-homoiconic/ http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were...
    - yawaramin 7y ago
      Yup you're right, my bad–I mixed up homoiconicity and hygienic macros–apparently like many before me!

giancarlostoro 7y ago

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. I wish the industry was much more Erlang friendly.

di4na 7y ago
Well elixir explicitly try to not move away from the erlang paradigm and to be fully and "naturally" inter-operable with it. It is far more integrated with erlang than Scala is with Java as an example. It is basically erlang with better tooling and still an easy use of erlang.
- mononcqc 7y ago
  We probably had our discussions about this before, tooling definitions diverge at times, and I have a vested interest in some of them, but I will just state my disagreement on the better tooling side of things ;)
  - giancarlostoro 7y ago
    I agree with the rest of his statement of how integrated Elixir seems with Erlang. I originally avoided Elixir cause I thought it was a hassle to install, but nowadays I can brew install on macOS, and on Linux I can leverage a sane package manager. I am not entirely sure about tooling myself. I would love to see a serious IDE for Erlang, I wonder what the tooling looks like. I've mostly just used the Erlang terminal to learn.
  - strmpnk 7y ago
    To say a few things that Fred isn't saying here (these are my opinions not his): - Early Erlang tools had a lot of issues when Elixir showed up but rebar3 made quick progress and is a very good set of tools integrated into one command-line interface - rebar3 has supported creating releases for a very long time which Elixir's mix tool is just catching up to (sure distillery supported things but so did relx and half a dozen other Erlang tools) - rebar3 has built-in support for things like dialyzer which still require extra work to use from mix - rebar3's _checkouts feature is very nice and has no good mix equivalent - rebar3 offers a declarative configuration setup which makes it easier for other tools to integrate their data and read other data w/o requiring plugins to be loaded everywhere (and this is to say it still supports scripting where needed, which will still result in a declarative output) - rebar3's version resolution system is more practical and puts the final control of version selection in the developer's hands rather than strictly package manager metadata which can lag or suffer unfortunate problems from version operators and unfortunate problems that come up from blind-semver adoption (this is a longer topic so I apologize for the poor summary here but I do think there is a good argument for rebar3's approach) - rebar3 works and upgrades independently from Erlang/OTP releases allowing more fluid iteration whereas mix is very much locked to Elixir I participate in the Elixir community and every time I hear the tooling story I think about all of the things I miss from Erlang tools when using Elixir. It'd be more accurate to say that Elixir has revitalized Erlang with a bit of competition and some diversity in background. Either way, there is room for improvements in both camps. I hope Elixir's mix catches up with rebar3 in some of these areas and I hope Erlang doesn't ignore some of the caveats that are still around as given facts of life (perhaps getting better support for the wider set of BEAM languages would be a start so each doesn't need its own tool).

alberth 7y ago

Fantastic article; it paints a great picture of the journey taken & accomplished achieved. 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. 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.

Jedi72 7y ago
I work with Ruby and Elixir daily and Elixir is 10x faster. Phoenix recently added functionality to display response times in microseconds, partially as a showcase for its good performance. I dont doubt you can get more performance in C++ or something but its still lighting compared to Ruby.
- strmpnk 7y ago
  I think this is a valid observation but the reason isn't necessarily that the Ruby language can't be used in a similar way, it's more so a death by 1000 cuts where Ruby encourages very small costs to be paid everywhere in return for a nicer programming experience. The issue becomes hard to fix because all of these small costs add up but none will show as up a single bottleneck in practice, making profiling a blunt tool for this kind of performance problem. Elixir isn't immune to this either but the functional aspects of design do help keep some of these choices local to the code that chooses to trade some time or memory away for other conveniences. An example I saw recently of this sort of adoption is map access, which is entirely okay if the trade-off is understood. I put in some time to show that much of the understanding of performance profile of the Access behavior gets colored by these expectations that the small things don't matter: https://lobste.rs/s/bctcke/performance_elixir_s_access_behavior#c_tolnwa https://lobste.rs/s/bctcke/performance_elixir_s_access_behav...
- ngrilly 7y ago
  What Phoenix did to improve display response times that much?

tombert 7y ago

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. I have found that I like Lisp-Flavoured-Erlang (LFE) a bit more, since I still 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. 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. 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.

unixhero 7y ago
Not being facetious, but could the joy resemble the fun I associate with developing with Ruby?
- tombert 7y ago
  I'm not super familiar with Ruby (had a bad initial experience with some awful Rails code and never went back), but maybe? From what I've read in blog posts, it feels like the coolness of Ruby comes from the feeling of "holy crap, something that would have taken me two days in Java/C/C++ took me an hour with Ruby" (hopefully I'm summarizing this more or less correctly). Erlang has definitely given that feeling to me. Distributed programming can be really, really hard, and gluing things together with sockets and whatnot can lead to a lot of really difficult bugs. Since Erlang embraces distribution and concurrency as part of its paradigm, it sometimes kind of feels like outright magic. Sometimes things feel like they went a bit...too perfect, like you missed something, when you really haven't. I'm not going to say that it fixes every issue with concurrency; you can still have race conditions and Mnesia and ets can be a bit finnickey if you're not careful, but I think I can honestly say that, for distributed apps, I can accomplish 20x as much as I could with most other platforms.

sergiotapia 7y ago

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). This ladder is a great blueprint, great article: 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

PasserBy2020 7y ago
Comparing Erlang to C# is a bit unfair. The latter is a general purpose language that can be used to build software on every layer of every platform. The former is a distributed programming DSL (an awesome one granted). There is 0 Erlang-native GUI libraries, there is no documented Erlang pipeline for iOS apps etc.
- toast0 7y ago
  > There is 0 Erlang-native GUI libraries Have you seen ex11? [1], it's Erlang native, and at least 0.1 of a GUI library. X11 and Erlang actually go together really well, although a lot of important functionality for a real application is missing; I used this to display images generated by an Erlang application, and it felt a lot nicer to me than using wxWidgets; I added a few bits of functionality to the library while I was in there, and it wasn't that hard to turn the X11 protocol docs into Erlang code for the things I needed. I imagine if someone had a real need here, it wouldn't be that hard to get it into shape. Caveat: X11 is dying, etc. [1] The most active fork appears to be here https://github.com/skvamme/ex11 https://github.com/skvamme/ex11 -- it's been somewhat retargeted to mobile, but the examples for desktop should still work as well as they did.
- bitwalker 7y ago
  > The former is a distributed programming DSL (an awesome one granted) I mean, that's a completely incorrect characterization of Erlang, regardless of how you feel about the comparison to C#. Erlang is just as much a general purpose language as C#, it is just a different paradigm, i.e. functional programming rather than (mostly) object-oriented. > There is 0 Erlang-native GUI libraries This isn't true at all. There is a tight integration with the wxWidgets framework (in fact, one of Erlang's handiest tools is built with it, Observer). Scenic, as mentioned elsewhere in the comments, is for Elixir (perhaps there is an Erlang-native API for it, not sure), but provides a native framework for OpenGL, and a UI paradigm that meshes nicely with processes and supervision. Of course, Erlang is not perfectly suited for all environments (e.g. iOS apps), but that is true of essentially all general purpose languages - there are some places where they aren't well suited or have flaky support. I wouldn't build an iOS app in C# either, it makes little sense to use anything other than Swift/Obj-C in that environment. Likewise if I'm primarily building Windows-based apps, I would use C# before I would reach for Erlang. But for backend services, infrastructure, networking, etc., it is extremely well suited, and I think the domains that it can provide a compelling solution for will continue to grow (e.g. embedded).

niftich 7y ago

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. 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. 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.

chessturk 7y ago
> people who've sought out similar model for its benefits, and could thrive with an offering that pays attention to these concerns throughout. I discovered BEAM while looking into a way to run concurrent, distributed Golang/gRPC services in a supervisor-worker set up. I've continued tinkering with OTP ever since. Edit: added quoted portion.
- Jailbird 7y ago

derefr 7y ago

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. Rails is a killer-app for Ruby because it’s a framework; a developer who uses Rails in their project is inherently a Ruby developer. People learned Ruby to use Rails. 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.) Thus, these infra components becoming popular doesn’t cause there to be any more Erlang programmers than there were before. In that sense, I would say that Erlang has never 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.) 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. How does anyone learn Erlang, then? Well, usually, engineers are forced 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.

seisvelas 7y ago
I don't think this counts, but I imagine a significant portion of people learning today learn it because they are Elixir programmers.
- derefr 7y ago
  It actually might. You can write Elixir for years without learning Erlang syntax, but if you’re a perfectionist, you’re gonna notice bugs in your Erlang deps just as much as in your Elixir deps, and you’re gonna want to submit PRs for them, and that leads you to learning Erlang. Also, IMHO, if you want to have a solid foundation when learning Elixir, it’s simpler to learn Erlang/OTP as a cohesive whole (from e.g. ferd’s Learn You Some Erlang book) and then “chase it” with an Elixir book; rather than trying to understand OTP through the lens of how it’s exposed in Elixir. Everyone in the elixir-lang Slack that asks how to get started learning Elixir, I tell them to learn Erlang first. So “being a simpler jumping-off point to Elixir knowledge” is also kind of a killer app. I would guess that this is only true in cases where there are killer apps for a secondary language on a runtime, but no killer apps for the primary language. Like, I wouldn’t say that Clojure is a killer app for Java. But then, is that because Java is already popular? Or is that because Clojure developers don’t necessarily end up knowing Java as well as Elixir developers end up knowing Erlang?

strikelaserclaw 7y ago

"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.

tabtab 7y ago
What's the common slang for that? "Buzzword Surfer"?
- strikelaserclaw 7y ago
  middle manager?
  - tabtab 7y ago
    Most buzzword pushers are architects or similar in my experience. I suppose that's arguably "middle manager".
- pickledish 7y ago
  I've heard it referred as a "magpie developer": https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/ though that's less for a competitive advantage and more because new tech is shiny

animesh 7y ago

This is how the page looked when Erlang posts caused HN to become slow. http://www.waybackhn.com/?date=2009-03-11 http://www.waybackhn.com/?date=2009-03-11

dmix 7y ago
That was my favourite moment in HN history. I believe it was even pg who started the whole “post erlang articles so HN appears boring” thing. Edit: yes of course, he mentioned it in the text post in your link but as a joke: https://news.ycombinator.com/item?id=512145 https://news.ycombinator.com/item?id=512145

davidw 7y ago

Good observations. '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. A big thanks to Fred for his book, and the many hours he has spent helping people on the mailing list, IRC and elsewhere. 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.

peterwwillis 7y ago

Riak convinced me that any language pretending that it could magically create better products was full of shit. 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. 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.

ulkesh 7y ago
Agreed, mostly. Riak was used in one of the first implementations of AT&T Messages (Web) as a secondary-index and key-value store. It performed so horribly that the whole thing ended up being rewritten using Oracle. The truth is, Riak was designed for basic key-value storage. Everything else they added on worked pretty badly, especially their javascript integration. All that being said, I do not blame Erlang for Riak. I blame Basho. Their support was clueless, and their platform simply didn't perform as advertised.

loxs 7y ago

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.

arendtio 7y ago

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. Does someone know if this is an inherent Erlang problem or just due to some weird project setup in this case?

mononcqc 7y ago
Ejabberd runs with a lot of legacy. Essentially the first build tool that could pull deps in Erlang dates from 2007-2009, and it took another few years before more modern tools came to be in what their current form is. All these bigger projects tend to have a bit weirder idiomatic build setups because they had to haphazardly reimplement bits of (at the time) yet non-existing build systems by hand.
- arendtio 7y ago
  Okay, but if I would start a project today, there would be better tools? Are those documented in the Erlang documentation or are there any recommendations on which tool I should use?
  - mononcqc 7y ago
    As one of its maintainers I’m partial to rebar3 (http://www.rebar3.org/ http://www.rebar3.org/) It’s become near-official for OSS Erlang work and the OTP team has moved the repo under their GitHub organisation (https://github.com/erlang/rebar3 https://github.com/erlang/rebar3) Erlang.mk tends to be the other option otherwise.

mrdoops 7y ago

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? 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. 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. 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.

reallydude 7y ago
> what could be changed in the ecosystem to support this goal? 1. Change the syntax. Elixir wasn't far enough. Not at all and BEAM doesn't need to know, so we have a chicken-egg problem of people entrenched don't want to spend time that will help the language and underlying strategies become more widely adopted. Perhaps this was the production feedback loop you were referencing. We still don't have a good methodology for measuring all sorts of things in software dev. 10 years, 20 years, the language may just never do more than incremental changes (like elixir). 2. Handling text is still awful in these languages.

sam0x17 7y ago

For what it's worth, I decided to pick up Elixir based on this post.

tabtab 7y ago

Functional programming has too long of a learning curve to the average programmer. A language should be judged by how long it takes average 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.) 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. I hate the rain the functional parade, but it's been tried and retried for many decades, but will just not 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. If you disagree, please reply instead of negativate me. I would greatly appreciate that.

carapace 7y ago
Hi there, I sometimes try to help normals relate to me by asking, "You know Sheldon Cooper from Big Bang Theory? I'm like a stupid, slighty-less-social-idiot Sheldon Cooper." I identify with Dr. Cooper. (BTW it sucks being like that. Don't ever think we do it because we like it. There are a few perks but it mostly sucks. Also, it's like living in "Idiocracy". I can't watch that movie because it's too painful. That's my life. From my point of view y'all are running around pouring Gatorade on the plants talkin bout "It's got lectrolites!" It's getting seriously scary now IRL too: where the fuck are all the fucking insects!? We should all be fucking terrified right now.) Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive. Also, FP is coming on stronger today than ever before. You are in actual fact just wrong.
- tabtab 7y ago
  Re: "Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive." This is the theory that the elite are so productive that they can replace say 10 non-elites. The main problem with this is that most problems to be automated (or upgraded) are not well-defined. It takes iterative interaction with analysts, users, testers etc., and this is where probably 2/3 of the effort takes place. Communication and teamwork is more of a bottleneck than raw coding, and the Sheldon Cooper types rarely do well on that. If the requirements were clearly defined, the 10x-Elite Theory would possibly work in practice. But it's a rare day in May one gets a clearly-defined specification that doesn't shift around a lot. If you could find a domain having clearly-defined specs, then you could implement that 10x Elite Theory and crush the competition by cranking out software for a fraction of the traditional competitions' price. For example, make an office suite fully compatible with MS-Office, and charge 1/2 of what Microsoft does. You'd be a billionaire. (Past attempts were not sufficiently compatible, which may be a tall order because one has to mirror bugs in MS's software to be so.)

msie 7y ago

RIP Joe Armstrong

parentheses 7y ago

This is a fantastic article. A question for rubyists out there: what does the "ladder of ideas" for ruby look like?

perlgeek 7y ago

So, what's the quickest way to get into OTP? To me it looks like Erlang itself isn't all that interesting, and OTP is where all the fun and magic is.

andrenth 7y ago
There are some books focused on OTP: * Erlang and OTP in Action; * Designing for Scalability with Erlang/OTP: Implement Robust, Fault-Tolerant Systems; * Designing Elixir Systems with OTP (in beta).

butterisgood 7y ago

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. It was elegant and clear!

maddy1512 7y ago

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.

T3RMINATED 7y ago

one of the worst inventions in the 21st century, erlang.