

Erlang - Not just fault tolerant, but highly fault tolerant - blhack
http://www.drdobbs.com/architecture-and-design/201001928;jsessionid=DPXLN5AC1WZ2DQE1GHPCKH4ATMY32JVN

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

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

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

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

~~~
davidw
That sounds like a sensible way of doing things.

> I hope you learned a lot about your problem domain in Ruby because otherwise
> that's a pretty big waste of time.

The biggest problem most startups have is no market, not being "web scale".
You'll figure that out faster with Rails or Django as your web code. Clearly
there are some areas where Erlang is really, really unbeatable, but... my
whole point was that I see other people muscling into them, like node.js and
Scala. Are they there yet? No. But give them some time and momentum and
they'll get most of the way there; far enough for most people.

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

------
aneth
" 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
He did qualify that statement with "basically" and if you think about it, a
"callback" function really is just sending a message.

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

