What's all this fuss about Erlang? (2007) | Hacker News Reader

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

pragprog.com

39 pointsdlcmh42 comments

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

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.

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.

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

No, the real question is "how can I make my program scale". Scalability and performance are quasi-orthogonal concepts (quasi, because what matters to an end-user is overall performance, all things considered).

What is dishonest? Who is asking "how can I make my program go fast?". I've heard you ask that question. So you asked your own question, then claimed the other one was dishonest.

Ok anyway,now that you've asked the question, maybe elaborate a bit why you think your program is slow and how do you think you can make it "go fast".

it's no marketing trick. Here's the reality. Let's suppose you have a C program that can run 10x faster than an equivalent erlang program, and your erlang program scales by the core, then you need 10 cores to have your erlang program keep up with C. The idea is that it's far easier to scale up by cores in Erlang than in C. Parallelization is far harder with C than in Erlang, so you might find that even tho your C program runs 10x faster, given 1000 cores, you won't be able to scale it without a complete rewrite, whereas you can take the same erlang problem and with minimal modification have it run 100x faster than the C equivalent on your thousand cores.

Yes that sounds typical of scalable languages. There's a minimum working set where it starts to win. So for most startups, its premature to worry about scaling and C is a much better choice.

For most startups, it's premature to worry about maximizing single core performance, too. Write it in whatever language is best for writing it in. Worry about performance when you have to. If you never have to, that's a bit of a bummer, but it means you didn't do a bunch of wasted work.

Even Erlang can't promise linear scaling forever, because nothing can. We call things that can linearly scale indefinitely "embarrassingly parallel", and the point of the first word in that phrase is that it's so easy that it's embarrassing to claim to be good at it, because it's easy. So for the class of problems that Erlang can scale like that, well, so could C.

It's what I consider to be a core problem with the dynamic languages, which Erlang technically is... you take such a single-core hit that it's essentially impossible to gain the performance back on multithreading. It's one of the reasons to be taking a serious look at Go; while it is far from the first "modern threading" system, it's one of the first to be combined with simple near-C performance. (Emphasis carefully chosen.) Java arguably has some solutions though I've not yet taken a close look at Akka performance. Erlang doesn't have near-C performance. Haskell can only get near-C performance with a lot of work and care. (They're still working on it, but it's still non-trivial.) The scripting languages are laughably far away from near-C performance and you take such a performance hit that it doesn't matter how easy they make multiprocessing after that.

I've still used Erlang for things that are truly IO bound. It's great for that and a very solid VM. But don't fool yourself into thinking Erlang is a performance solution for anything else. (And I find people yell "IO bound!" a bit too readily sometimes. That's really in the class of things you should profile before being sure.)

It is for this reason that I decided to use Clojure over Erlang. I get close to Java performance, which is fast enough for me. I get parallelism in the core language and actors from Pulsar. I've still got LYSE4GG on my desk, read about half, but I doubt I'll use Erlang for anything other than ruminations on ideas.

>> so could C <<

For example: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

"Erlang FAQ 1.4 What sort of problems is Erlang not particularly suitable for?

The most common class of 'less suitable' problems is characterised by performance being a prime requirement and constant-factors having a large effect on performance. … Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages…"

http://www.erlang.org/faq/introduction.html#idp27238416

    Erlang is optimized for latency.
    OpenCL is optimized for t-put.
    Everything else (including C) is in between.

> Erlang is optimized for latency.

Too short: for latency with multiple simultaneous users. If you have a 'one shot' program or one user at a time, you'll probably get better latency with C than with Erlang.

More exactly latency of switching between concurrent activities, which might be handling user sessions, but might be something else too.

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.

I really like his minimalistic writing style. Wish other authors (especially americans) would follow his example. Not every simple fact needs an anecdote.

This! Some people love to write a thousand words to give you 10 words of actual information.

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?

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

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.

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.

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.

How comfortable are you with functional programming, and concurrent programming?

I ask because my experience (and as always, YMMV) was that in languages that had 'familiar' syntax, new paradigms and concepts were a lot harder to pick up. I tried to learn functional programming in Scala, but it didn't take; I could still write things in a Java like way, which was what I was accustomed to, and it took a lot of extra effort to try and write them idiomatically.

As a for instance, one of the most confusing (and thus, unused) structures in Erlang is the if structure. Why? Because it looks like something every developer already understands, while behaving in a completely different manner. That tinge of familiarity is a detriment for it.

I started learning Elixir a few months ago, and the few times I've had to dive into reading some Erlang source code to figure out an issue with a library I was using I've been surprised at how easy I find it to read. Even though the syntax is quite foreign, having learned the general ideas of pattern matching, etc. in Elixir makes it a lot easier to read Erlang code.

I don't think I'd ever set out to write a new project in Erlang: for me Elixir has all the advantages and none of the drawbacks. There's nothing you can do in Erlang that you can't do in Elixir, and you get the benefit of a much more expressive syntax and powerful metaprogramming. But there are a lot of quite mature Erlang libraries out there, and I don't see the point of replicating them all in Elixir, so I can see myself contributing patches to Erlang projects.

Have a play with both, stick with whichever one feels better to you. Since you're just learning, you want whichever one will make you more excited about learning, and make it quicker to pick up the concepts. Once you've got a solid grasp of it, you can familiarize yourself with the few syntactic differences and make a more informed decision about which one you want to keep working with.

I would suggest Erlang. I rather like the syntax. If anything, semicolons and C-like similarity is deceiving because other things don't work like C. There are probably more examples at the moment in Erlang. Watch some of the Erlang Factory talks, those are good.

Try http://learnyousomeerlang.com/ that is a fun and great resource. Joe's books are great.

But Elixir is fantastic too. You can call into Erlang from it. But it is still a bit new. Maybe spend a couple of hours with both or pick a small project and try to do it in both and see how you like the feel of both.

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.

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

Thank you - this looks like a great resource, and I'll definitely follow your advice.

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

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)

Not to nitpick but it seems like it's a doctoral thesis.

The syntax apparently borrows from Prolog, since the first version was built with Prolog, from what I've read.

Apparently http://delivery.acm.org/10.1145/1240000/1238850/a6-armstrong... , PLEX https://en.wikipedia.org/wiki/PLEX_(programming_language) .

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.

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

http://lambda-the-ultimate.org/node/2386

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.

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.

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.

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.

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.

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/) concept of "ownership" does something very similar to what you're suggesting.

in clojure there's something similar called transients http://clojure.org/transients

Reply on news.ycombinator.com