Wednesday, August 20, 2008

Ruby vs. Erlang vs. The People vs. Your Application

For the past six months or so I've been working on a somewhat under the radar service called Mumbl. Basically, mumbl is a micro-blogging service that solves the whole "Oh, we chose the wrong framework for the wrong platform and our db won't/can't scale" problems most of the bigger folks have. And for all I know they may well have already solved their issues as it seems to be getting better(?) as less and less downtime occurs. Good for them, the Mongolian Horde/money shovel approach to systems and development worked...for now.

Anyway, there's been a momentum gainer amongst Rubyists looking more and more at Erlang. Which, yea is great but I think one of the biggest problems with Ruby developers is that we (yes, I'm one too) don't just drink the punch if things "make sense", WE CHUG IT! We ask that it be hooked intravenously into our veins until it becomes a part of us on a molecular level.

So, having said that, why would someone that's vested deeply in Ruby, which preaches readability and quick, elegant solutions to common problems (whether it be via frameworks or gems) have any interest in Erlang? Erlang is based on ant-turd tokens, which aren't exactly easy to read. Erlang appears to also be fairly verbose in a sense that I can't see it "fitting" for your typical online applications and it certainly isn't the easiest thing to read. So please, if you need to undertake a project that would quite easily be completed using the rails/merbs/django's of the world out there - then utilize them! It's my opinion that Erlang is not a language for application that need constant adjustment, in this particular case applications for the online masses. Leave it to the back-side and you'll thank me on your wedding night!

This was touched on a little bit a while ago (the Erlang thing, not the back-side thing), I had to go dig up the post but you can see Damien Katz's blog entry about a few things he disliked about Erlang. See the comments of his posting for a real roller-coaster ride!

Anyway, getting back to the point here. I think we need to be careful when given the option of the punch, which really is true for anything. But something we, as developers should look at so closely is the separation of trendy with practical. I believe we can all agree that a readable/maintainable application layer with a concise entry point to a highly parallel back-end is probably the best way to go. Maybe not; well, let me try and convince you otherwise.

If you had to throw a jack of many trades developer into the mix of your application I described above how do you think he'd handle it? I think they would greatly appreciate the easy readability of the Ruby code over the Erlang. Once they ramped their way up gaining and understanding of the interfaces it would likely make their lives easier once they made it into the land of Erlang.

So please, let's keep it separate. And let's please, please stop creating half-assed Ruby implementations of things that really don't need it. This recent post on the register certainly struck a nerve with me. It was apparent they we are getting lazy and far too comfortable in our language to expand horizons and use the right tool for the right job. That tool doesn't need to take over completely, getting back to the punch-chugging I mentioned earlier. You need to find it's proper place in your application if it even fits at all, don't make a place for it. And certainly don't make a cheesy knock-off of it in Ruby so you get 1/2 points for utilizing some new (or trendy) methodology. that' feels better.


Jon Gretar said...

I quite like Erlang and I will use it propably quite a lot in the future...

However I would not think of using it for the same things as Ruby. I would use Erlang as the trusty thing in the background. I would use it for the part that calls for scaling and reliability. I would however use Ruby to do the front end.

Basically I would use Erlang as a replacement for both MySQL and ActiveRecord but leave it to Rails(or other framework) to do the actual talking to the user.

BradfordW said...

@jon Amen!

Filter said...

Everything I needed to know about Ruby I learned from the horde of companies walking away from it and starting over in something usable.

You don't see *anybody* saying "man this choice of Erlang really screwed me."

StoneCypher said...

"It's my opinion that Erlang is not a language for application that need constant adjustment, in this particular case applications for the online masses."

Uh, you don't know what you're talking about. That's the whole point of hotloading modules. If you had read the manual, or the thesis, or PE, you'd know that in fact Erlang is designed specifically to facilitate applications that change over time.

You just picked one of the fundamental design principles of the language and got it ass backwards.

Stick to blogging about languages you understand.

jamaal sibley said...

Erlang is pretty easy to read. Its modularity is also granular to the point of absurdity, so new programmers can play around with existing programs and see intelligible results without constantly breaking everything.

OTP is pretty tough to get a handle on, though. New guys will have an awful lot of trouble learning that for a while - but if they're modifying existing stuff rather than building new significant structure, they can just ape all of the other callback functions that wil already be there.

BradfordW said...

Hadn't checked on comments, I figured no one was still seeing this stuff. @StoneCypher - Thanks for at least informing (me) on why Erlang can handle that kind of stuff. I have a decent grasp on Erlang now and am quite happy with it. As for sticking to blogging and languages "I understand", c'mon did I really piss you off that bad with this post?

Oh well...comment noted.