7 ms·

What's all this fuss about Erlang? (2007)

• dasmithii 12y ago
  Was Erlang designed in light of any ancestor languages? Or is it fairly original - create from scratch? I'm interested in the language design process.
  • rheese-archer 12y ago
    You can read about it in detail in Joe Armstrong's master thesis. I would recommend it be read from cover to cover: http://www.erlang.org/download/armstrong_thesis_2003.pdf http://www.erlang.org/download/armstrong_thesis_2003.pdf
    • dasmithii 12y ago
      Thank you - this looks like a great resource, and I'll definitely follow your advice.
    • signa11 12y ago
      also, might consider reading this seminal paper from jim-gray (tandem computers) "Why Do Computers Stop and What Can Be Done About It?" http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf edit: if you look at the timelines, the thesis was presented in 2003, and is the result of stuff that started off in 1981. pretty cool (fwiw)
    • adamnemecek 12y ago
      Not to nitpick but it seems like it's a doctoral thesis.
  • davidw 12y ago
    The syntax apparently borrows from Prolog, since the first version was built with Prolog, from what I've read.
  • leoc 12y ago
    Apparently http://delivery.acm.org/10.1145/1240000/1238850/a6-armstrong.pdf http://delivery.acm.org/10.1145/1240000/1238850/a6-armstrong... , PLEX https://en.wikipedia.org/wiki/PLEX_(programming_language) https://en.wikipedia.org/wiki/PLEX_(programming_language) .
  • rdtsc 12y ago
    Try to find some of Joe Armstrong's talk on the history. It is pretty interesting. Unlike some academic languages, this one was created by a company with a few set of well defined goals. On of the top ones was high concurrency and fault tolerance. I think they have succeeded and later on, it turns out those same features came to be very useful for concurrent writing large concurrent and fault tolerant services. So in way it was created from scratch. It has a Prolog like feel but that is superficial only. Prolog was used as the original implementation platform. It is also interesting they didn't explicitly indent to make a "functional" language or use "actor programming" or "CSP" and so on. Those things fell out of the original requirements of fault tolerance and concurrency.
• davidw 12y ago
  There was some hype about Erlang 6/7 years ago, too, but it didn't seem to be enough to give it much momentum: https://news.ycombinator.com/item?id=300485 https://news.ycombinator.com/item?id=300485 http://lambda-the-ultimate.org/node/2386 http://lambda-the-ultimate.org/node/2386
  • jhancock 12y ago
    Seems to me erlang adoption has been chugging along just fine (with or without HN posts). There are some high-profile startups using erlang: WhatsApp and I think Facebook Chat is/was. There has been progress in cleaning up syntax, library and package management cruft that have helped ease adoption. Elixir (a new lang built on erlang) seems to be coming along well. For most types of webapps, erlang has all the batteries included. The problem is that for many mainstream types of webapps, getting v1 out the door quickly in Rails/Django works well. I think that may be part of the adoption problem...if the problem domain doesn't clearly require erlang to get v1 out the door, many will use Rails/Django and never look back.
    • davidw 12y ago
      Yeah, it's slowly and steadily coming along. But it seemed at a certain point a few years back that there were people beating the hype drum, and nothing much seems to have come of it: the slow steady growth continues.
  • DesiProgrammer 12y ago
    Not all business applications need Erlang. Thousands of concurrent users requirement is mainly for gaming,chats type applications.For vast majority of 'real world'applications:java,Microsoft,Python,Ruby fulfill the needs. OOP is not going away.Scala,Clojure have their advantages.
• kornakiewicz 12y ago
  Quick question: If you recommend to start learning Erlang now, it's better to play with normal one (I actually don't like syntax since I'm used to semicolons and other C-influenced stuff) or Elixir, which looks pretty neat?
  • loxs 12y ago
    Both. Elixir is the future, but mostly, you write the same thing with a different (better) syntax. No way you will write Elixir without understanding Erlang
    • coldtea 12y ago
      Is that so, or is that old wives tales? Because in most "layered" languages, you can go quite far without understanding the base language, as long as you understand the semantics of the higher level language. I don't need to know Java to write Scala for example -- I just need to know the relevant semantics of Scala's object system and interoperability.
      • thisishugo 12y ago
        The semantics of Elixir are a superset of the semantics of Erlang, so by learning the former, you're learning the latter anyway. Plus, you'll be calling a lot of Erlang libraries from Elixir, so understanding how Erlang works is extremely beneficial to using Elixir.
    • mononcqc 12y ago
      I don't see Elixir being the future, or ever killing Erlang entirely. I do prefer Erlang's syntax to Elixir's too (along with a bunch of other stuff). I expect what is going to be more of a dynamic where Elixir will grab a bunch of new developers, some of which will go to the Erlang side of thing eventually, whereas Elixir had its jumpstart by draining some of the Erlang developers who were unhappy with the language. If Elixir does catch on, it could have a spectacular rise, but I'd only expect it to trickle more people into Erlang, which already had its newcomer wave many years ago and has stabilized since then.
• renox 12y ago
  > Here’s the good news for Erlang programmers: Your Erlang program should just run N times faster on an N core processor I hate this kind of marketing trick. So let me add: And here's the bad news, your Erlang program can be much slower than a C program on one core: for example in the alioth 'benchmarks' Erlang run between 3X and 30X slower than a C program on one core ( http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=hipe&lang2=gcc&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... ) so you may have to throw MANY core at it before the Erlang program is faster than the C program. So beware! YMMV. That said, I hope that Elixir will improve Erlang's adoption as the high availability feature are the big deal IMHO.
  • brickcap 12y ago
    Well I think he was just comparing it to the corresponding erlang programme on a single core. I don't see Joe saying anywhere that it will run N times faster than a c program.
    • renox 12y ago
      Which is why this is dishonest.. The real question is 'how can I make my program go fast?' answering about a different question is a marketing trick.
      • lostcolony 12y ago
        "Here’s the good news for Erlang programmers: Your Erlang program should just run N times faster on an N core processor" isn't dishonest. He's clearly speaking to Erlang programmers. What would be dishonest would be "here's the good news for C programmers: Your C program should just run N times faster on an N core processor if written in Erlang". To your point though, Erlang gives you scalability. Yeah, on a single core, the C program will be faster. On multiple cores, multiple processors, multiple -machines-, idiomatic Erlang should scale. C code will not. You have to tear it apart, rewrite it, figure out a distribution model, code that or find a good library, fix the bugs in your own code or work around the caveats of that library, etc etc.
      • 12y ago
• unterstrom 12y ago
  I really like his minimalistic writing style. Wish other authors (especially americans) would follow his example. Not every simple fact needs an anecdote.
  • goshx 12y ago
    This! Some people love to write a thousand words to give you 10 words of actual information.
• damienkatz 12y ago
  Former serious Erlanger here. Lots of comments about performance and scaling in this thread. If you are writing a system for internal use, it's simple scalability and robustness make Erlang an excellent choice. Engineers are expensive, machines are cheap. However, if you are writing something that needs massive scalability, the number of machines necessary and the management of it all starts to eclipse engineering cost. Then you need to drop down to a lower level language, or at least something more runtime optimized (like java) for the heavy lifting. Then the costs and frustration of debugging across two languages becomes burdensome. If you are building a competitive commercial product that will be deployed to many customers, the economics start to swing away from Erlang. Customers don't care you needed 1/3 the engineers and testing (or whatever) to get it working. They don't care about how much time and money you saved writing it. They care their EC2 bill is low, or the number of machines in their data center is reduced. A competitor who writes in C might have longer time to market, but they will clobber you when customers see they need 1/4 the machines to support the same workload. Erlang will NEVER be fast. The reason has little to do with the language semantics, and everything to do with it's lack of widespread adoption and therefore lack investment in compilers, runtimes and debugging tools, etc. It's slow because the syntax is ugly and thwarts adoption. If you are a badass VM/complier/JIT/etc engineer, you'll apply your skills to something like Javascript, Java, Python, Ruby, etc and affect a much larger audience. Also the lack of adoption makes Erlang a hard sell in a corporate environments. Sure you might get something up and running much faster, but if your erlangers leave, finding replacements engineers to maintain the system will be tough. I've lived this. I wish I were wrong about it, but 9 years of watching Erlang on the verge of mainstream has jaded me.
• bsaul 12y ago
  The line "erlang has no mutable data structure" made me think about something : Couldn't you imagine a language with data structure that are mutable from within a same single thread only and requires message passing when communicating between threads ? Now that i think of it, I wonder if golang isn't doing just that.
  • keyneus 12y ago
    Go allows pointers to be sent over channels, so it's up to you to make sure you send copies of data to prevent problems. So no, I'd say Go isn't doing that; or rather, it does require message passing but there's a huge loophole which means you basically can share mutable state unsafely. Rust, on the other hand, is much closer to what you're describing.
  • rssaddict 12y ago
    I'm not too clear on the details since I don't know the language, but I think that Rust's (http://www.rust-lang.org/ http://www.rust-lang.org/) concept of "ownership" does something very similar to what you're suggesting.
  • marianoguerra 12y ago
    in clojure there's something similar called transients http://clojure.org/transients http://clojure.org/transients