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.
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.
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.
> 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.
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.
Ruby itself doesn't provide this power. The modules do.
In any event, "more power per line of code" is a terrible metric. According to such logic, the best possible programming tool in the universe would be one that implemented your plan with a single statement: readMyMindAndDoIt.
But, what if a competing programming tool provided the same brevity of expression, but its implementation of readMyMindAndDoIt performed an order of magnitude faster?
I've used both, and actually started using Erlang prior to Ruby. My name is in the 'thanks for previewing it' for the O'Reilly Erlang book for having had a good look through it before it was published.
I'm not making any claims about scientific metrics, I'm talking about what I've seen and the feel I get for both.
Think how much less boilerplate there is for a Ruby class versus an OTP server, just as one example.
Yeah, yeah, apples and oranges, but you can't both say how Erlang is "really object oriented" and then not compare what those "objects" look like in practice.
Also: I mostly say this stuff because I like Erlang and am a bit frustrated at not seeing it go farther than I think it could.
Our stats show that we write a supervisor or a server once in every 7.5 man-months of coding.
Yes, there is a small amount of 'boilerplate' in creating OTP structures, but you are not comparing like-with-like when you compare a Ruby Class to an OTP component.
If you compare a Ruby Class to an Erlang Module - (which is a much better comparison - our stats show 1 new module per man-month) then your boilerplate argument falls completely flat.
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.
"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.
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.
