What can I only do in Erlang? • Hacker News Board

Re: What can I only do in Erlang?

#81

Post by goshx » Fri, Nov 07, 2014, 2:43 PM UTC

baldfat wrote: post #69

Ixiaus wrote: post #47

Earlier quoted context omitted.

Huh? "Hardcore feel" is definitely there and the language is anything but "writing config txt files to some underlying system". I've built applications in the > 10k SLOC range that use a consensus algorithm for distributed computing and it was hard but made tremendously easier because of Erlang's built in primitives. No hardcore feel was lost at all and neither was it writing a config txt file... [EDIT] I would love…

Down vote = I don't agree with your statement normally here. Not that it might be a starting point on a conversation?

Interesting. I have always thought about the down vote as: I don't like your comment and I want to punish you for it.

You know, there is karma involved. If down votes are supposed to be used the way you describe, people that are intelligent and polite and educated on their answers, but share a different view than the majority here, should not be part of the community. Is that the intent?

Re: What can I only do in Erlang?

#82

Post by mononcqc » Fri, Nov 07, 2014, 2:43 PM UTC

amelius wrote: post #80

lostcolony wrote: post #76

Earlier quoted context omitted.

Which do you need sooner; fast? or correct and scalable? Erlang is built first for fault tolerance, not speed. The decisions that went into that make it also really, really good for concurrency and distribution (and so that's what it often gets touted for). The decisions that went into C++ were for speed, and compatibility with C (and all that entails). If you've got something truly resource intensive, yeah, you're g…

> Which do you need sooner; fast? or correct and scalable? Well, if I need all of these options, then Erlang is obviously not the way to go. In that case, Erlang might work as a prototyping language. My impression is, from what I've read here, that Erlang might be the preferred tool for situations in which latency is not of paramount importance. For example, when sending text-messages over the internet, it doesn't hu…

I've personally used Erlang in Real Time Bidding scenarios, where soft-real time constraints exist and is on the order of milliseconds.

It's a fine tool for this, too.

Re: What can I only do in Erlang?

#83

Post by segmondy » Fri, Nov 07, 2014, 2:43 PM UTC

amelius wrote: post #34

Erlang looks interesting. However, the only problem I have with starting in Erlang is that on the great computer language shootout, it shows that Erlang is about 10x slower than C++ on most examples. And about 3x slower than Go [1] I know that the problems on this website are not specifically "concurrent" problems, but still, even a distributed web-server must do some non-concurrent stuff at times :) Are my concerns…

So?

1) There are trade offs, sometimes you trade development time for execution time.

2) Erlang is "fast"/scales, ask whatsapp

3) A lot of people worry about execution but have enough spare CPU cycles to compute the universe.

4) Benchmarks mean nothing, you must figure out what is meaningful to you. You won't compare a ferrari and a minivan? Well, you could, but yet, find that a minivan is more practical for your daily needs.

Re: What can I only do in Erlang?

#84

Post by jerf » Fri, Nov 07, 2014, 2:44 PM UTC

amelius wrote: post #80

lostcolony wrote: post #76

Earlier quoted context omitted.

Which do you need sooner; fast? or correct and scalable? Erlang is built first for fault tolerance, not speed. The decisions that went into that make it also really, really good for concurrency and distribution (and so that's what it often gets touted for). The decisions that went into C++ were for speed, and compatibility with C (and all that entails). If you've got something truly resource intensive, yeah, you're g…

> Which do you need sooner; fast? or correct and scalable? Well, if I need all of these options, then Erlang is obviously not the way to go. In that case, Erlang might work as a prototyping language. My impression is, from what I've read here, that Erlang might be the preferred tool for situations in which latency is not of paramount importance. For example, when sending text-messages over the internet, it doesn't hu…

"In that case, Erlang might work as a prototyping language."

If you can write reasonably idiomatic Erlang from the get-go (design things in terms of gen_servers and such, instead of single-process monoliths), Erlang is a great prototyping language, because anywhere you send a message and receive something back is a point where you can drop in some other implementation of that particular bit without affecting the system as a whole.

You'll find in practice that the only time you'll be tempted to do that is if something is computationally expensive. Erlang is pretty darned good at reading from and writing to sockets in general.

Re: What can I only do in Erlang?

#85

Post by macintux » Fri, Nov 07, 2014, 2:50 PM UTC

lostcolony wrote: post #63

john2x wrote: post #46

I love Erlang (and it's younger sibling Elixir). I love reading about it. I enjoy following tutorials about it. I love its simplicity. But when I try to come up with scenarios/ideas where Erlang might be a good fit, I realize I'm not smart/motivated enough (yet?) to tackle such problems. Erlang isn't difficult. It's the problems it was designed to solve that are difficult.

You're probably thinking about it the wrong way then. It turns out that even in cases where you don't have some massively distributed, scalable needs, there are a lot of cases to use Erlang. While it makes insanely difficult problems tractable, it can also make moderately challenging problems simple (and it sometimes can make simple tasks irritating; see usual list of Erlang complaints). Just about any sort of web ba…

You're both right.

Absolutely, Erlang can serve well as a general-purpose language.

But there's no denying that it was designed to solve very costly, very difficult problems, and that remains its strength.

Re: What can I only do in Erlang?

#86

Post by amelius » Fri, Nov 07, 2014, 2:53 PM UTC

segmondy wrote: post #83

amelius wrote: post #34

Erlang looks interesting. However, the only problem I have with starting in Erlang is that on the great computer language shootout, it shows that Erlang is about 10x slower than C++ on most examples. And about 3x slower than Go [1] I know that the problems on this website are not specifically "concurrent" problems, but still, even a distributed web-server must do some non-concurrent stuff at times :) Are my concerns…

So? 1) There are trade offs, sometimes you trade development time for execution time. 2) Erlang is "fast"/scales, ask whatsapp 3) A lot of people worry about execution but have enough spare CPU cycles to compute the universe. 4) Benchmarks mean nothing, you must figure out what is meaningful to you. You won't compare a ferrari and a minivan? Well, you could, but yet, find that a minivan is more practical for your dai…

> 2) Erlang is "fast"/scales, ask whatsapp

But whatsapp is not a latency-critical application.

Re: What can I only do in Erlang?

#87

Post by Ixiaus » Fri, Nov 07, 2014, 2:54 PM UTC

baldfat wrote: post #69

Ixiaus wrote: post #47

Earlier quoted context omitted.

Huh? "Hardcore feel" is definitely there and the language is anything but "writing config txt files to some underlying system". I've built applications in the > 10k SLOC range that use a consensus algorithm for distributed computing and it was hard but made tremendously easier because of Erlang's built in primitives. No hardcore feel was lost at all and neither was it writing a config txt file... [EDIT] I would love…

Down vote = I don't agree with your statement normally here. Not that it might be a starting point on a conversation?

Down voting is not for disagreeing, read the guidelines for HN. If you disagree, provide a comment as to why.

Down voting is for completely irrelevant comments, inappropriate comments, etc...

[EDIT] To be clear, I did not downvote you and I disagree with the down votes on your comment here, even though it's off-topic it's important to acculturate people that are accustomed to "downvoting for disagreeing". Which is why I'm commenting.

Re: What can I only do in Erlang?

#88

Post by Ixiaus » Fri, Nov 07, 2014, 2:59 PM UTC

amelius wrote: post #86

segmondy wrote: post #83

Earlier quoted context omitted.

So? 1) There are trade offs, sometimes you trade development time for execution time. 2) Erlang is "fast"/scales, ask whatsapp 3) A lot of people worry about execution but have enough spare CPU cycles to compute the universe. 4) Benchmarks mean nothing, you must figure out what is meaningful to you. You won't compare a ferrari and a minivan? Well, you could, but yet, find that a minivan is more practical for your dai…

> 2) Erlang is "fast"/scales, ask whatsapp But whatsapp is not a latency-critical application.

By latency, what do you mean? Erlang excels with Input/Output (the VM's I/O manager is well-tuned) and network applications.

I think WhatsApp is latency critical, no user ever said it's okay to have their message show up minutes after it was sent if both parties were on a good internet connection...

Re: What can I only do in Erlang?

#89

Post by Ixiaus » Fri, Nov 07, 2014, 3:01 PM UTC

polskibus wrote: post #71

davidw wrote: post #6

Earlier quoted context omitted.

If you dig around in HN's search there are a lot of good comments from people like jerf on the differences: https://news.ycombinator.com/item?id=5451916 https://news.ycombinator.com/item?id=7943248 But there are more here and there if you hunt for them. I think for things where they are sort of similar, Go will definitely be the more successful language because it looks so much more familiar and because it's moving f…

Whenever I think about Erlang's stability I recall the problems mentioned by CouchDB authors and RabbitMQ users. Apparently CouchDB hit some problems with low level disk access that they couldn't trace and that pushed them to migrate away from Erlang. RabbitMQ is allegedly dropping lots of messages for unknown reasons under heavy use. I do not have the links at hand for reference but such stories make me wonder how b…

The Riak guys have better experience here and I would argue that it's pretty well battle-tested when Apple is deploying hundred node Riak clusters for production :) (Riak is built on-top of Erlang)

Re: What can I only do in Erlang?

#90

Post by lostcolony » Fri, Nov 07, 2014, 3:03 PM UTC

amelius wrote: post #80

lostcolony wrote: post #76

Earlier quoted context omitted.

Which do you need sooner; fast? or correct and scalable? Erlang is built first for fault tolerance, not speed. The decisions that went into that make it also really, really good for concurrency and distribution (and so that's what it often gets touted for). The decisions that went into C++ were for speed, and compatibility with C (and all that entails). If you've got something truly resource intensive, yeah, you're g…

> Which do you need sooner; fast? or correct and scalable? Well, if I need all of these options, then Erlang is obviously not the way to go. In that case, Erlang might work as a prototyping language. My impression is, from what I've read here, that Erlang might be the preferred tool for situations in which latency is not of paramount importance. For example, when sending text-messages over the internet, it doesn't hu…

If you're just delivering content, not number crunching, I doubt your bottlenecks are CPU, and you shouldn't see Erlang take 10x as long. In fact, you'll probably deliver a better experience in Erlang, because of its approach to concurrency; your average latency will likely be a bit higher, but your extremes will likely be lower.

In fact, since you started with benchmarks, let's return to benchmarks (I find them to generally be useless, but you're looking at them, so why not) - http://www.techempower.com/benchmarks/

Compare CPPSP (the fastest! C++!) with cowboy (a popular web framework in Erlang). They're being run on the same hardware (so we're not talking about ability to scale across nodes even), serializing JSON.

Cowboy is about 1/4th the throughput (requests per second). Now let's look at latency. Cowboy took about 4 times the time, .8 ms on average per request to the CPPSP's .2. Great, C++ all the way, right? Err...no. Look at the max and standard deviations.

Cowboy had a max latency of 3.7 ms. CPPSP had a max of 134.6. Standard deviation of cowboy was .3 ms. Standard deviation of CPPSP was .5 ms.

So Cowboy is still really quite fast, more predictable, and has far smaller outliers. What are people going to be more likely to object to, waiting 3.7 ms, or 134 ms?

Couple that with the reliability Erlang provides, the ability to scale straight outta the box (so if you find you're hitting a throughput issue you have a clear path forward), and the joy of functional coding...and it's pretty compelling, to me at least.