Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why The Cool Kids Don't Use Erlang

gar1t.com

Post reply on HN
Print view View original

41–50 of 128 posts

Re: Why The Cool Kids Don't Use Erlang

#41

Post by judk »

CmonDev wrote: post #37
kyberias wrote: post #31

A semi-interesting observation of the graph on one of the first slides: C# is highest on StackOverflow metric because the site has been historically concentrating more on Microsoft technologies. This also shows on how the different languages are separated by the diagonal line: technologies/languages closer to Microsoft are above the line and more "open" alternatives are under the line.

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

Because Joel Spolsky is a famous Microsoftie whose community and fan base originally skewed toward Microsoft.

Re: Why The Cool Kids Don't Use Erlang

#42

Post by CmonDev »

jeffdavis wrote: post #18
hershel wrote: post #11

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

Erlang allows the actors to be spread across physical nodes. It's like a cluster OS, not just a language that uses an actor model. Do any of the library actor models offer something like that?

Microsoft Orleans if you are ready to use a cloud.

Re: Why The Cool Kids Don't Use Erlang

#43

Post by vamega »

yummyfajitas wrote: post #30
waffle_ss wrote: post #17

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…

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.

Re: Why The Cool Kids Don't Use Erlang

#44

Post by readme »

CmonDev wrote: post #37
kyberias wrote: post #31

A semi-interesting observation of the graph on one of the first slides: C# is highest on StackOverflow metric because the site has been historically concentrating more on Microsoft technologies. This also shows on how the different languages are separated by the diagonal line: technologies/languages closer to Microsoft are above the line and more "open" alternatives are under the line.

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

Re: Why The Cool Kids Don't Use Erlang

#46

Post by judk »

waffle_ss wrote: post #17
hershel wrote: 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…

Is ConcurrentMarkAndSweep stop-the-world?

How hard are the limits of "soft" realtime?

Re: Why The Cool Kids Don't Use Erlang

#47

Post by yummyfajitas »

jeffdavis wrote: post #18
hershel wrote: post #11

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

Erlang allows the actors to be spread across physical nodes. It's like a cluster OS, not just a language that uses an actor model. Do any of the library actor models offer something like that?

In principle, transitioning from multithreaded to distributed with Akka is just a matter of configuration. I've never put this to the test, but akka does make this claim.

Re: Why The Cool Kids Don't Use Erlang

#48

Post by clubhi »

CmonDev wrote: post #37
kyberias wrote: post #31

A semi-interesting observation of the graph on one of the first slides: C# is highest on StackOverflow metric because the site has been historically concentrating more on Microsoft technologies. This also shows on how the different languages are separated by the diagonal line: technologies/languages closer to Microsoft are above the line and more "open" alternatives are under the line.

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

We have a niche site denier here folks.

Re: Why The Cool Kids Don't Use Erlang

#49

Post by judk »

rdtsc wrote: post #28
rational-future wrote: post #22

Earlier quoted context omitted.

>> JVM does global stop-the-world garbage collection Does it? Back when I was in HFT, we were definitely running a JVM with background thread GC.

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

Re: Why The Cool Kids Don't Use Erlang

#50

Post by rdtsc »

general_failure wrote: post #25
candoprog22 wrote: post #14

1. It is good the cool kids are not drawn to Erlang because then we would end up in the state Ruby and Node are now. 2. The biggest fail in IT - "I can't find experienced developers in Erlang/ ": Most employers are muppets. Rather than hire a decent developer and allow them to learn a new tech on the role, they scour the market for candidates that are probably just lying on the resume/CV. I have already seen resumes/…

What's bad about the state of node? Or are you saying Erlang is underdeveloped and you would prefer it that way. Because in my eyes, node is doing great.

I think, the implication was that it attracts a disproportionate number of inexperienced yet very vocal and immature crowds. It creates and unfriendly and unpleasant community.

Also the marketing innovation or advantage it proclaims -- "callbacks as a concurrency mechanism" are thought by some to betray a understanding of how concurrency can be handled in a sane way. So anything said or promoted afterwards is discarded just based on that assumption.

As an example it is like someone saying "oh we have this new awesome paradigm invented and it is a sorting algorithms and it compares every element to each other and swaps places". And everyone will say yeah cool that bubble sort or something like that. It is not very interesting. But you know with additional marketing and a vocal community one can grow and promote that idea despite the apparent flaws at its base.

Now node has very good qualities. It makes it very easy to get started, lots of packages. A lot of example. So those are probably things to look at and copy. And if you see that presentation (or watch the video) that is what the author drives towards. Simplicity. Easy to learn. And so on.

Post reply on HN