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

21–30 of 128 posts

Re: Why The Cool Kids Don't Use Erlang

#21

Post by alttab »

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/…

Interestingly enough, in both the start up and corporate world I've seen hiring when the developer has NO skill in the language. This was true about Java, this was true about Ruby. This was true about python...

I think what would be a more interesting analysis is what cohort pre-selects themselves to functional languages, or projects where that technology is used? Out of all the software today, where is the most prominent functional code use and why?

Re: Why The Cool Kids Don't Use Erlang

#22

Post by rational-future »

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…

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

Re: Why The Cool Kids Don't Use Erlang

#24

Post by crdb »

Joeboy wrote: post #6

I would think that the "Hard to find developers" takeaway was a pretty good incentive for developers to start learning erlang.

We hired a team of 10 Haskellers in 3 months with over 100 people doing our application task. It's really not hard to find developers, the market (at least for Haskell work) has plenty of supply and little demand. So, "learning Erlang/Clojure/Haskell" is a bad strategy if you just want to be employed, unless you are good enough to pit yourself against people with decades of experience, who write large amounts of open source code, who have built several projects in a host of other tech stacks and who can afford and are willing to take a (so far, up to 3x) pay cut to work full time in the language they love and helped build.

I suspect the problem is the two most popular ways of hiring developers in tech companies (tapping your network, and recruiters) fail hard at finding functional programmers, unless you yourself are a functional programmer.

Re: Why The Cool Kids Don't Use Erlang

#25

Post by general_failure »

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.

Re: Why The Cool Kids Don't Use Erlang

#26

Post by waffle_ss »

rational-future wrote: post #22
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…

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

Were you paying huge money for Azul? http://www.azulsystems.com/zing/pgc

Re: Why The Cool Kids Don't Use Erlang

#27

Post by crdb »

rwmj wrote: post #9
Joeboy wrote: post #6

I would think that the "Hard to find developers" takeaway was a pretty good incentive for developers to start learning erlang.

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…

This would be a valid reason: http://paulgraham.com/pypar.html

I agree with you that whilst familiarity with a rare, powerful language might be a signal of quality, lack of familiarity with rare languages does not imply the reverse.

Re: Why The Cool Kids Don't Use Erlang

#28

Post by rdtsc »

rational-future wrote: post #22
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…

>> 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 engineering. Each little process lives in its own memory heap. Then pauseless garbage collection become trivial. It has many other really cool and unique features (hot code reloading, inter-node distribution, ability to load C code, etc etc...)

Re: Why The Cool Kids Don't Use Erlang

#29

Post by lelf »

decentrality wrote: post #15

What I would like addressed by someone from Erlang is the reality of Celluloid in Ruby, and do honest comparisons. http://celluloid.io Otherwise, the speaker seems like a good representative, but the presentation is so verbose it makes me want to concurrently handle his thesis asynchronously in parallel threads and remove the human... in jRuby, using Celluloid.

It's different game. Nothing is shared (think: one gc per thread), can run 10M+ threads on one cpu and effectively schedule all of them (it has one-of-a-kind scheduler counting reductions, you cannot cpu lock even if you want), really transparent distributive programming, state of the art introspection: "login" to remote process on different node, see how many messages in the mailbox of some process, hot (= replace running code) code reloading etc.

Edit: Essentially: some actor library for language X is not even remotely (if any) erlang. Maybe cloud haskell some day will be there, but its all introspection parts is basically nonexistent right now.

Re: Why The Cool Kids Don't Use Erlang

#30

Post by yummyfajitas »

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…

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 means Erlang will also need some sort of concurrent garbage collector - does Erlang's version not stop the world, or at least the messaging subsystem?

Post reply on HN