7 ms·

Erlang - Not just fault tolerant, but highly fault tolerant

66 points by blhack 16y ago

aneth 16y ago
Wow - 1.7M lines of Erlang, the largest functional program ever written, with 9 nines (99.9999999%) reliability.
- deleted 16y ago
  [deleted]
  - artmageddon 16y ago
    "9 nines works out to 31 milliseconds of downtime per year. That's smaller than the acceptable drift of an atomic clock over the same period. You couldn't measure anything to that accuracy if you tried." Not to be pedantic, but are you using the right unit of time? Atomic clocks aren't supposed to lose more than 1 second of accuracy over a million years... maybe you meant micro/nano/picoseconds? 31millisecond drift(assuming it goes one way) per day = 1 sec error over approximately 300 days... Edit: Bah, the parent comment is gone. I'm leaving mine up anyway in case I'm wrong in my assessment.
davidw 16y ago
I think the "problem" is that most people just don't need that kind of thing until they get really big. When you're small, a language like Ruby or Python that's faster to develop in is more of an advantage.
- ak1394 16y ago
  It very much depends on a problem you're trying to solve. For a wide range of tasks Erlang is a very natural fit. In my last two projects (server monitoring solution and mobile twitter client) I used Erlang mostly to cut the development time.
- gordonguthrie 16y ago
  Erlang is real fast to develop in. We write a lot of Erlang (switched to Erlang from being a Ruby shop in 2004) and it is lovely, fast-to-build/debug/change. It is dynamically-typed (but you can do static analysis with Dialyzer to check that it is well behaved - sort of semi-typed, best-of-both-worlds). Although Erlang is not (usually) interpreted, you can hot load Erlang binaries into a running system in the VM which is super-cool and makes development an unalloyed pleasure.
  - davidw 16y ago
    Erlang is a nice language in many ways, but my own experience is that Ruby is consistently faster for getting things done: it packs more power per line of code for most things. Erlang's runtime is nicer, but like I said, that comes into play more once you've got popular, not when you're struggling to get traction and may need to change course quickly.
    - getsat 16y ago
      Agreed. If you're prototyping a network-facing application or even building an initial proof of concept, take a look at EventMachine. Lots of bang for your buck. https://github.com/eventmachine/eventmachine https://github.com/eventmachine/eventmachine https://github.com/eventmachine/eventmachine/wiki/Code-Snippets https://github.com/eventmachine/eventmachine/wiki/Code-Snipp...
    - jerf 16y ago
      It depends on what you're doing, really. If you write something in Ruby that then performs like a dog and you have to rewrite in Erlang to get to anything remotely "web scale", I hope you learned a lot about your problem domain in Ruby because otherwise that's a pretty big waste of time. I personally tend to use Erlang in the core of the product as the internal router and basic message bus, with the ability to "drop to" Erlang if I need to, but leave a lot of the business logic in higher-level languages in processes connected to the core. I don't necessarily want business logic in my Erlang, but I wouldn't even try to prototype a router-like program in anything but Erlang, because nothing is better at it than Erlang.
jamesgeck0 16y ago
The posted link is dead because it has a session id in it. Here's the article: http://drdobbs.com/201001928 http://drdobbs.com/201001928
aneth 16y ago
" Basically there are two models of concurrency: Shared state concurrency Message passing concurrency " Wouldn't the node.js style callbacks be a third type of concurrency? It's similar to message passing, but quite different from the user's perspective.
- oomkiller 16y ago
  He did qualify that statement with "basically" and if you think about it, a "callback" function really is just sending a message.
  - aneth 16y ago
    Yes, however at the implementation level, message based concurrency is shared memory concurrency (as I understand anyway.) Callbacks seem to me an entirely a different abstraction.

66 points by blhack 16y ago

aneth 16y ago

Wow - 1.7M lines of Erlang, the largest functional program ever written, with 9 nines (99.9999999%) reliability.

deleted 16y ago
[deleted]
- artmageddon 16y ago
  "9 nines works out to 31 milliseconds of downtime per year. That's smaller than the acceptable drift of an atomic clock over the same period. You couldn't measure anything to that accuracy if you tried." Not to be pedantic, but are you using the right unit of time? Atomic clocks aren't supposed to lose more than 1 second of accuracy over a million years... maybe you meant micro/nano/picoseconds? 31millisecond drift(assuming it goes one way) per day = 1 sec error over approximately 300 days... Edit: Bah, the parent comment is gone. I'm leaving mine up anyway in case I'm wrong in my assessment.

davidw 16y ago

I think the "problem" is that most people just don't need that kind of thing until they get really big. When you're small, a language like Ruby or Python that's faster to develop in is more of an advantage.

ak1394 16y ago
It very much depends on a problem you're trying to solve. For a wide range of tasks Erlang is a very natural fit. In my last two projects (server monitoring solution and mobile twitter client) I used Erlang mostly to cut the development time.
gordonguthrie 16y ago
Erlang is real fast to develop in. We write a lot of Erlang (switched to Erlang from being a Ruby shop in 2004) and it is lovely, fast-to-build/debug/change. It is dynamically-typed (but you can do static analysis with Dialyzer to check that it is well behaved - sort of semi-typed, best-of-both-worlds). Although Erlang is not (usually) interpreted, you can hot load Erlang binaries into a running system in the VM which is super-cool and makes development an unalloyed pleasure.
- davidw 16y ago
  Erlang is a nice language in many ways, but my own experience is that Ruby is consistently faster for getting things done: it packs more power per line of code for most things. Erlang's runtime is nicer, but like I said, that comes into play more once you've got popular, not when you're struggling to get traction and may need to change course quickly.
  - getsat 16y ago
    Agreed. If you're prototyping a network-facing application or even building an initial proof of concept, take a look at EventMachine. Lots of bang for your buck. https://github.com/eventmachine/eventmachine https://github.com/eventmachine/eventmachine https://github.com/eventmachine/eventmachine/wiki/Code-Snippets https://github.com/eventmachine/eventmachine/wiki/Code-Snipp...
  - jerf 16y ago
    It depends on what you're doing, really. If you write something in Ruby that then performs like a dog and you have to rewrite in Erlang to get to anything remotely "web scale", I hope you learned a lot about your problem domain in Ruby because otherwise that's a pretty big waste of time. I personally tend to use Erlang in the core of the product as the internal router and basic message bus, with the ability to "drop to" Erlang if I need to, but leave a lot of the business logic in higher-level languages in processes connected to the core. I don't necessarily want business logic in my Erlang, but I wouldn't even try to prototype a router-like program in anything but Erlang, because nothing is better at it than Erlang.

jamesgeck0 16y ago

The posted link is dead because it has a session id in it. Here's the article: http://drdobbs.com/201001928 http://drdobbs.com/201001928

aneth 16y ago

" Basically there are two models of concurrency: Shared state concurrency Message passing concurrency " Wouldn't the node.js style callbacks be a third type of concurrency? It's similar to message passing, but quite different from the user's perspective.

oomkiller 16y ago
He did qualify that statement with "basically" and if you think about it, a "callback" function really is just sending a message.
- aneth 16y ago
  Yes, however at the implementation level, message based concurrency is shared memory concurrency (as I understand anyway.) Callbacks seem to me an entirely a different abstraction.