If I had to sum up the difference between Ruby and Erlang in a
sentence, it'd be this: Erlang makes programming harder, but
engineering easier, while Ruby makes programming easier, but
It took me a long time to appreciate the difference between
programming and engineering. The distinction is somewhat artificial,
but I think of "programming" as those times you just want to produce
some output of interest, and engineering is when you start to worry
about performance and resource consumption.
With most languages, engineering websites is difficult. You have to
worry about templates being slow, databases taking a long time, the
garbage collector running, and all of the side-effects on the system
that these events have. As a result you have to think very carefully
about caching strategies, I/O strategies (async vs. sync), and
manually invoking the garbage collector.
Erlang makes all that stuff easy. Templates don't need to be cached,
I/O is always async, and the garbage collector runs on one process at
a time so you're not going to see weird system-wide performance
spikes. As a result you don't have to waste brain cycles thinking
about the usual engineering problems, and can focus on the user
interface and business logic.
With Ruby, novice programmers are led to believe that engineering Ruby
must be easy because programming Ruby is easy. But the reality is that
engineering a Ruby application is basically the same as engineering an
application written in any other language (apart from Erlang). You get
some nicer syntax along the way, and a lot of libraries, but you still
have to worry about threads and rendering time and stack sizes and all
In a sense Erlang applications are practically engineered for you by
the guys at Ericsson. They made a large number of correct design
decisions that has resulted in a truly great platform to program for.
The trade-off with Erlang is that it's a functional language, which
requires more thinking to solve a particular logic problem, so
programming Erlang is harder than Ruby. (That and Erlang is slow at
crunching numbers.) But most of website development has nothing to do
with logic problems, let alone arithmetic, so you can get pretty far
with just sequential calls to APIs.
With CB I've tried to design a nice clean set of APIs that makes web
development in Erlang a lot of fun. You get the satisfaction of
knowing you're building an application on a rock-solid foundation, and
along the way you don't have to sweat over traditional engineering
problems. That's taken care of for you.
On Wed, May 9, 2012 at 3:01 PM, Ben G. <bng...@gmail.com> wrote:
> I have worked with tornado and node.js, which have the same operating
> Most of the advantages of CB are because of it's erlang foundation, so this
> comparison kinda ends up as a erlang vs. ruby debate.
> To the best of my understanding; tornado,node.js and goliath all run on a
> single thread. This is not scalability problem however, you just put a load
> balancer in front of it like nginx. Actually node.js doesn't even need that
> anymore. These systems scale fine, much more easily than your database will.
> I guarantee.
> The disadvantages of these systems are when one process starts blocking the
> others. You have to be very careful about writing your code with that in
> mind. You often may have to suffer through many nested callbacks or other
> ugly code.
> I guess goliath has it's own way of dealing with callbacks. But it's still
> nonblocking server underneath and subject to those quirks.
> Erlang doesn't suffer from any of those problems. You can write
> callback-free free code. The erlang VM uses all available threads much more
> intelligently. It was design for telecom where latency is important, so it
> takes care of it's own blocking issues auto-magically. There are some erlang
> server performance tests that outperform node.js(node outperforms goliath
> IMHO). All of that usually matters very little, in the real world you'll
> just add another server. Hardware is cheaper than developer time. But if
> speed does matter to you, do some tests for your scenario and don't take
> anybody's word about it(even though I already know CB will smoke the
> competition;p )Again, If all you care about is raw number crunching speed,
> then maybe you should be looking at haskell+yesod?
> I think the most important feature Erlang has is linked processes. You
> really can write code that will never ever have downtime. Write once and
> forget for 20 years. That's not something ruby(or any other language I know
> of) has an equivalent to. There's hook.io, but that's not half of what
> erlang offers out-of-the-box.
> CB and Goliath also have very different code libraries available. You really
> should be looking at what libraries your project will need as it might
> disqualify one or both of these frameworks.(e.g. websockets support)
> Personally, I would be choosing between node.js vs CB, not Goliath vs CB.
> Mostly because I think the maturity and support is much better than Goliath.
> but that's entirely IMHO
> On Tuesday, May 8, 2012 12:46:03 PM UTC-7, wulftone wrote:
>> Hey all,
>> I'm curious if any of you have any experience with the fairly new
>> Goliath framework (http://postrank-labs.github.com/goliath/) and how
>> their process compares to what Erlang and CB can do... or at least
>> provide some insights into things that CB does better, in your
>> I just implemented a site in Goliath and it was quite enjoyable
>> (though I know Ruby _much_ better than Erlang). I'm still working on
>> CB for another thing.. slowly.. : )