Erlang - Not just fault tolerant, but highly fault tolerant
drdobbs.com
drdobbs.com
When you're small, a language like Ruby or Python that's faster to develop in is more of an advantage.
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'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.
https://github.com/eventmachine/eventmachine
https://github.com/eventmachine/eventmachine/wiki/Code-Snipp...
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.
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.
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.
Shared state concurrency
Message passing concurrencyWouldn'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.