Live data from Hacker News

Why The Cool Kids Don't Use Erlang

gar1t.com

51–60 of 128 posts

Re: Why The Cool Kids Don't Use Erlang

#51

Earlier quoted context omitted.

Because Akka can't magically patch over the JVM's shared memory model: http://doc.akka.io/docs/akka/snapshot/general/jmm.html#jmm-s... And because the JVM does global stop-the-world garbage collection, which makes soft real-time implausible because of the unpredictability of GC affecting your actors. Erlang has per-process heaps. Basically the Erlang VM was created for this use case while the JVM was not, and its not…

Java/Scala do allow you to do bad things. So add the following to Hershel's question: "Assume developers are non-malicious and will only pass immutable objects across actor/future boundaries." Also, I'm not that familiar with Erlang's memory model, so I might be wrong on this. But as far as I'm aware the memory for a message in Erlang is shared between threads - it's only local variables that use private memory. This…

> But as far as I'm aware the memory for a message in Erlang is shared between threads - it's only local variables that use private memory

No, the messages are truly copied: http://jlouisramblings.blogspot.dk/2013/10/embrace-copying.h...

edit: the exception being large binaries apparently

Re: Why The Cool Kids Don't Use Erlang

#52
post #43

Earlier quoted context omitted.

Java/Scala do allow you to do bad things. So add the following to Hershel's question: "Assume developers are non-malicious and will only pass immutable objects across actor/future boundaries." Also, I'm not that familiar with Erlang's memory model, so I might be wrong on this. But as far as I'm aware the memory for a message in Erlang is shared between threads - it's only local variables that use private memory. This…

That's exactly right. Erlang has per actor heaps, and it's garbage collector only stops the actors that are being garbage collected. This is highly concurrent and is a great property to have when you're trying to keep your response times low.

[deleted]

Re: Why The Cool Kids Don't Use Erlang

#53
post #44
post #37

Earlier quoted context omitted.

How can an open free Q&A site be concentrated on something? It simply reflects what people want and need.

Because early adopters of the website were prominent Microsoft developers. Such as Jon Skeet. This caused network effects. To suggest just because a door is opened that every developer has an equal chance of walking through is absurd. This is not evidence that the general software community wants or needs c# more than any other thing. For many developers more traditional channels of q and a are still popular, such as…

Jon Skeet is a Google developer. Well early Git adopters were Linux developers. Does it mean that GitHub is not really mainstream apart from a narrow group of people?

Re: Why The Cool Kids Don't Use Erlang

#54
post #9

Earlier quoted context omitted.

I don't get this thing about having to find developers in a particular language. I work on a lot of OCaml programs, and have used and hired developers to work on the same programs. None of them had OCaml experience before, but they just learned it as they went along (because they are intelligent programmers). I actively don't want someone who only knows one language. Also we're using RabbitMQ (written in Erlang). At…

There's something worth talking about, which is that a sophisticated and ingenious mess is orders of magnitude more costly than a simple minded mess. My experience with brilliant functional programmers is that it's hard to know whether you're getting someone who can use it as the best tool for a job in a simple, elegant, and maintainable way, or a cargo-cultist who delights in sophistication and cleverness and purity…

Sometimes it's near impossible to tell the difference between the two.

Re: Why The Cool Kids Don't Use Erlang

#55
post #53
post #44

Earlier quoted context omitted.

Because early adopters of the website were prominent Microsoft developers. Such as Jon Skeet. This caused network effects. To suggest just because a door is opened that every developer has an equal chance of walking through is absurd. This is not evidence that the general software community wants or needs c# more than any other thing. For many developers more traditional channels of q and a are still popular, such as…

Jon Skeet is a Google developer. Well early Git adopters were Linux developers. Does it mean that GitHub is not really mainstream apart from a narrow group of people?

> Does it mean that GitHub is not really mainstream apart from a narrow group of people?

Does git even work well on Windows yet?

Re: Why The Cool Kids Don't Use Erlang

#56

Earlier quoted context omitted.

Because Akka can't magically patch over the JVM's shared memory model: http://doc.akka.io/docs/akka/snapshot/general/jmm.html#jmm-s... And because the JVM does global stop-the-world garbage collection, which makes soft real-time implausible because of the unpredictability of GC affecting your actors. Erlang has per-process heaps. Basically the Erlang VM was created for this use case while the JVM was not, and its not…

Java/Scala do allow you to do bad things. So add the following to Hershel's question: "Assume developers are non-malicious and will only pass immutable objects across actor/future boundaries." Also, I'm not that familiar with Erlang's memory model, so I might be wrong on this. But as far as I'm aware the memory for a message in Erlang is shared between threads - it's only local variables that use private memory. This…

> But as far as I'm aware the memory for a message in Erlang is shared between threads

Yes and no. Some large binaries (a specific Erlang data type, that can say represent a packet or block of data from disk), will be shared and reference counted when passed between processes instead of copied. They are immutable just like most datatypes in Erlang. These binaries have a specific GC algorithm that it just might take longer sometime for them to be reclaimed. But it seems all that could presumably be done via atomic updates to counters and references.

In general most messages are copied on send. So implementation wise GC is very simple then. On another level because data in Erlang is immutable, the fact that messages get copied is also an implementation detail! One could conceive another implementation of a VM that only passes references and immutable data on message send (well minus when it sends it to another machine, of course). But that would make GC a bit more tricky just like in case of those binaries.

Re: Why The Cool Kids Don't Use Erlang

#57
post #49
post #28

Earlier quoted context omitted.

Only Azul's JVM has managed to create a pause-less garbage collector. They use some pretty cool tricks. It is really a fantastic piece of technology: http://www.azulsystems.com/zing/pgc Even just marveling at the complexity and how they got it working. Otherwise, besides those tricks, how would you do it when you have multiple threads accessing objects on a shared heap? Erlang's VM is another even wonderful piece of…

A few simple ways: put shared data in PermGen, and rollover to a new process when memory gets low (erlang-style but at OS-level).

Well I wouldn't say "roll-over" to the new process is exactly simple but it is a good trick though. Forking has its interesting dark cases that have to be handled. Inherited file descriptors, what happens to threads, signals and so on.

Re: Why The Cool Kids Don't Use Erlang

#58
Meta but I really wish we could ban the phrase "cool kids" from the programming community. It has a terrible connotation (high school cliques). And it feels out of place, especially when we're talking about something like practical choices about what programming language and tooling we choose. Even when talking about "trendy" languages and frameworks it's a poor choice of words because no one really make these choices to be "cool" and it would actually be interesting to take time to better understand what drives adoption (which, to be fair, is what the speaker of this talk is actually doing with his real work, he just choices a grating title). To be cool people wear trendy clothes, listen to particular music, etc. with the intent of signaling to other "cool" people. People make choices about programming languages & tooling because they've heard something good about the language, it seems to solve a problem you have or it's new and presumably someone else thinks it solves an existing problem in the programming ecosystem.

Re: Why The Cool Kids Don't Use Erlang

#59
post #9

Earlier quoted context omitted.

I don't get this thing about having to find developers in a particular language. I work on a lot of OCaml programs, and have used and hired developers to work on the same programs. None of them had OCaml experience before, but they just learned it as they went along (because they are intelligent programmers). I actively don't want someone who only knows one language. Also we're using RabbitMQ (written in Erlang). At…

There's something worth talking about, which is that a sophisticated and ingenious mess is orders of magnitude more costly than a simple minded mess. My experience with brilliant functional programmers is that it's hard to know whether you're getting someone who can use it as the best tool for a job in a simple, elegant, and maintainable way, or a cargo-cultist who delights in sophistication and cleverness and purity…

As it's all open source, I guess you can look at the code and judge whether it's a mess or not.

https://github.com/libguestfs/libguestfs

https://github.com/rabbitmq/rabbitmq-server

Re: Why The Cool Kids Don't Use Erlang

#60
post #11

Since there are actor libraries like akka targeting the JVM and claiming to offer similar benefits, why should someone prefer erlang?

Because Akka can't magically patch over the JVM's shared memory model: http://doc.akka.io/docs/akka/snapshot/general/jmm.html#jmm-s... And because the JVM does global stop-the-world garbage collection, which makes soft real-time implausible because of the unpredictability of GC affecting your actors. Erlang has per-process heaps. Basically the Erlang VM was created for this use case while the JVM was not, and its not…

The metronome GC from ibm is predictable (not hard real time though).
Post reply on HN