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

What can I only do in Erlang?

erlang.org

Post reply on HN
Print view View original

71–80 of 173 posts

Re: What can I only do in Erlang?

#71

Post by polskibus »

davidw wrote: post #6
willvarfar wrote: post #4

Curious how much people think Go will eat into Erlang? Many of the points made were about Erlang as CSP and that's Go-territory. Loïc Hogun (author of Cowboy, other projects) said: For me Erlang is first fault tolerant, then concurrent, then functional As Go gains libraries like groupcache will it become more and more go-to for networked and shared systems? Is Go moving up from concurrent to fault-tolerant in a real…

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 battle-tested Erlang really is when you need to persist your data (and not just transmit it over the network).

Re: What can I only do in Erlang?

#73

Post by Spearchucker »

bachback wrote: post #26
Spearchucker wrote: post #22

Earlier quoted context omitted.

Nobody needs reliable messaging: http://www.infoq.com/articles/no-reliable-messaging

Tell that people who are trying to build scalable network applications. Saltstack uses ZeroMQ under the hood and the biggest cloud computing operations in the world use it. That article reads like from a past age, where you didn't have startups scaling to millions of users based on cloud computing. HTTP was invented for retrieving hypertext documents. Not for connecting millions of nodes.

Scale covers lots of things, including statefull v. stateless and (appropriate to this discussion) asynchronous comms and the ability to queue requests. Scale in that sense is facilitated by retrying a remote call that failed - possibly because the server is at capacity. That implies store/forward, which is what the "queue" part of message queuing does. You can definitely use tools like ZeroMQ, MQ Series, MSMQ or WCF to achieve that. You can also use a database table with a flag indicating whether a message was delivered or not (ref. my link above).

Not quite sure what HTTP has to do with message queuing, other than being a protocol one might use. If scale is so important, perf is a concern, in which case UDP would be a consideration. Would I go down that road? Doubt it, because I suspect the acceptable answer lies somewhere between HTTP and UDP, and I also suspect that better gains can be made by optimising end-to-end throughout and solution design rather than worrying about the semantics of a protocol. What's the benefit, for example, of streaming data over a TCP connection when that data is XML? TLV or some other binary format will serve you a lot better.

Final words on scale - asynchronous delivery (such as message queuing) is one technique. Another is to scale servers out and/or up. Also, as already mentioned, server state and of course pipeline/routing efficiency. Whilst I stand by what I said, I've not had the opportunity to work at the scale you have, so I'd love to know what problems you've encountered when scaling to millions of nodes.

Re: What can I only do in Erlang?

#74

Post by mononcqc »

Erwin wrote: post #52
tegeek wrote: post #36

Earlier quoted context omitted.

When you say Erlang is slower than C++, You are right. It is also slower than Go. Ruby is also slower than C++ & Go, But Ruby on Rails is not only popular but a very productive web framework which can help you build your app with a productivity that C++ or Go can't match. When you write a high quality, fault tolerate system, the raw speed comes at the end. Erlang shines when you write a concurrent system plus its des…

The added fault tolerance of Erlang is not free - it adds complexity and overhead. Would you rather maintain an distributed Erlang system running 100s of tasks on 10s of machines, or a simpler C++ based system that due to performance can run on a single machine? Erlang may scale out, but does it scale down? This is similar to the ADA argument -- it's great and can be used to write safe software, but do you need safe…

A few points:

- A large system never runs on a single machine if you want any level of realistic fault tolerance. Two nodes is a bare minimum, 3 an acceptable one.

- The number of nodes will always depend on where your bottlenecks lie. Erlang developers would be rare and few to write CPU-bottlenecked code directly in Erlang. The usual approach would be to write your system in whatever is appropriate, and then too coordinate things with an Erlang layer.

- I would a hundred times more willingly maintain and debug a running Erlang system than a C++ one. I'm kind of sold on the idea though, and wrote http://erlang-in-anger.com to share my experience there.

Re: What can I only do in Erlang?

#75

Post by Spearchucker »

manishsharan wrote: post #67
Spearchucker wrote: post #22

Earlier quoted context omitted.

Nobody needs reliable messaging: http://www.infoq.com/articles/no-reliable-messaging

'Nobody ' is not quite correct. What you probably mean is not everyone needs reliable messaging. As a former TIBCO and MQ developer, I could not have done without them when developing trading applications.

"As a former TIBCO and MQ developer..."

I'm reaching here, please forgive (and correct) me if I'm wrong. This comment makes me think that you've not tried delivering the same functionality without TIBCO and MQS. I used to do a lot of MQS and MSMQ work, and have not encountered a scenario these products handle that I can't as described in my link above.

Re: What can I only do in Erlang?

#76

Post by lostcolony »

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…

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 going to need a lower level language. That's largely unavoidable. Erlang.org flat out states don't use it for number crunching.

I'd guess that 90% of what is programmed in the wild isn't that resource intensive. And given that, I'd go so far to say that most of what I've coded in Erlang is more performant than what I've coded in Java (haven't done enough C/C++ professionally to have useful data points). Why? Because the abstractions and conventions lead me to writing better code; the tooling lets me profile and find bottlenecks more easily, and even code I tweak for performance is oftentimes cleaner than it started, rather than more arcane.

Joe Armstrong, the founder of Erlang, is quoted in OTP in Action as (paraphrasing as I don't have it on hand) - "First, make it correct. Then, make it beautiful. Then, if you need to, make it performant. Chances are once you've made it beautiful you'll find it sufficiently performant". And that's been my experience with Erlang.

Re: What can I only do in Erlang?

#77

Post by tegeek »

louthy wrote: post #49
tegeek wrote: post #36

Earlier quoted context omitted.

When you say Erlang is slower than C++, You are right. It is also slower than Go. Ruby is also slower than C++ & Go, But Ruby on Rails is not only popular but a very productive web framework which can help you build your app with a productivity that C++ or Go can't match. When you write a high quality, fault tolerate system, the raw speed comes at the end. Erlang shines when you write a concurrent system plus its des…

> and Erlang is perhaps the most commercially successful functional language. Out of interest, what makes you say that? Looking at the TIOBE rankings (not that this is definitive), Erlang doesn't even make the top 20 languages, when F# and R do: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... Is there a reason you think it's more successful in the commercial world? (btw, I'm a fan of Erlang - unfortun…

Erlang is developed by the Ericsson as a product to use for themselves. Its not a research language like Haskell but developed for a niche and when I said commercial I meant that it is designed as a commercial product. I have seen more Erlang systems than any other functional language.

Just to mention one, RiakDB, a successful distributed software system is developed on top of Erlang. Actually I've yet to see any other product used by 100s or perhaps 1000s of developers developed on F# or Haskell. Not to mention, almost over 80% of telecom industry is running on Erlang.

Re: What can I only do in Erlang?

#78

Post by rakoo »

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…

I don't think your concerns are justified: the added-value of Erlang is not its speed but its reliability and its tooling to build large, stable softwares.

Try to look for something that works at scales you're interested in, break it down to its components and rearrange them into a simple architecture, then only can you consider performance. It turns out the lack of performance you feared at the beginning doesn't actually happen; in the meantime you'll have built a robust software (and, if you want to start the language, you'll have learnt a whole new way to program)

Re: What can I only do in Erlang?

#80

Post by amelius »

lostcolony wrote: post #76
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…

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 hurt if the message takes 1 or 2 seconds longer to reach its destination. However, for a webserver, every second it takes longer to load a webpage means that you lose customers.

Do you think that's a fair characterization?

Post reply on HN