Using Erlang to Build Reliable, Fault Tolerant, Scalable Systems(ddj.com)
ddj.com
Using Erlang to Build Reliable, Fault Tolerant, Scalable Systems
http://www.ddj.com/hpc-high-performance-computing/220600332
7 comments
It is interesting to observe how people abuse words, to the points they become distraction. "Java stack", "Erlang stack", "Everything stack"; "by means", "using" became "via". Modern articles are "massively leveraged via stacks" it seems like.
This is one of the best discussion I've read about why Erlang is good for parallel processing ie, it lets you avoid threads and use messages and processes.
Nice that the article gives a good run-down of advantages and disadvantages.
Nice that the article gives a good run-down of advantages and disadvantages.
When I read Arun and Jebu's internal paper (at Y!) I just knew we had to publish it. I really enjoyed their lack of fanboy-ism.
Erlang, like all other systems, really works in some scenarios, but not in all of them. I enjoyed that they really broke that down instead of presenting Erlang as the next panacea for all ills.
Erlang, like all other systems, really works in some scenarios, but not in all of them. I enjoyed that they really broke that down instead of presenting Erlang as the next panacea for all ills.
It's funny how Erlang in particular attracts this type of comment, the one that qualifies its awesomeness. If an Erlang thread springs up, I can count on some variation of this comment within 2 or 3 posts.
I'm an Erlang fanboy with no misgivings. I think the things that Erlang does better than say, Python, it does so much better as to make Python disappear. And the cases where Erlang is clearly the right choice are a bit bigger than some people give it credit for.
Of course, I write Erlang professionally, so I would say that. But I can tell your right now that it's giving my company a competitive advantage.
I'm an Erlang fanboy with no misgivings. I think the things that Erlang does better than say, Python, it does so much better as to make Python disappear. And the cases where Erlang is clearly the right choice are a bit bigger than some people give it credit for.
Of course, I write Erlang professionally, so I would say that. But I can tell your right now that it's giving my company a competitive advantage.
Could I contact you (or you me, see profile) for some Erlang advice? I know next to nothing about the language but I suspect it'd be a good fit for something I'm working on and the input of someone who's used it in anger would be very helpful.
It's not Erlang it's anything.
A screw driver is a pretty multi-functional tool: you can undo screws with it, you can push the cork in a bottle of wine, I guess you could shank someone with it. However, that doesn't mean most of those uses are optimized.
I'd much rather read an article that says a screw driver is an awesome way of inserting or removing screws (much better than saw a hammer) than read one saying it's the right solution for every problem. Personally I open wine with a corkscrew, and no, I've never shanked anyone.
A screw driver is a pretty multi-functional tool: you can undo screws with it, you can push the cork in a bottle of wine, I guess you could shank someone with it. However, that doesn't mean most of those uses are optimized.
I'd much rather read an article that says a screw driver is an awesome way of inserting or removing screws (much better than saw a hammer) than read one saying it's the right solution for every problem. Personally I open wine with a corkscrew, and no, I've never shanked anyone.
It is also worth noting that for a lot of the things that Erlang is not good for it is relatively easy to use ports to call out to a pool of Python or Ruby processes to handle that specific task. The only caveat with this approach is that the task you are farming out should be relative "heavy" or the round trip times will eat up the benefit of this strategy.