Toluu

Yariv's Blog

Adventures in Open Source Erlang

If I Were Building Amazon.com…October 11 2007

I would use ErlyWeb :) From Amazon’s Dynamo by Werner Vogel: “In Amazon’s decentralized service oriented infrastructure, SLAs play an important role. For example a page request to one of the e-commerce sites typically requires the rendering engine to construct its response by sending requests to over 150 services. ” Unless all 150 service requests are executed sequentially, [...]

ErlyWeb is Facebook-ReadyOctober 4 2007

In case you didn’t know, Bryan Fink of BeerRiot fame has created a Facebook library for Erlang called erlang2facebook. You can get it from http://code.google.com/p/erlang2facebook/. It is bundled with a complete Hello World Facebook app that is built with ErlyWeb, so you can hit the ground running with your Erlang Facebook development. I can think of [...]

Great Concurrency -> Better WebappsSeptember 26 2007

I’ve been asked a few times: Is concurrent programming really useful for web developers? Web servers already handle client requests in different threads/processes, so application code doesn’t need to use concurrency explicitly, right? My opinion is that althought it’s possible to write many database-driven web apps without using concurrency, concurrency can still be useful. Vimagi has some [...]

Introducing Vimagi.comSeptember 23 2007

I just launched Vimagi, my first ErlyWeb app: vimagi.com. Painting is fun. Sharing paintings with your friends is also fun. Painting together with your friends is a new kind of fun you can have on Vimagi. Give it a try and let me know what you think — I’ll appreciate the feedback. Note: Vimagi is in early beta. [...]

Erlang-Style Concurrency in Google GearsJuly 23 2007

I heard about Google Gears when it came out a few weeks ago, but only a couple of days I took it for a short test drive. I was surprised to see that Google Gears uses Erlang-style concurrency (well, sort of).

Google Gears supports asynchronous background processing using the WorkerPool module, which lets your Google Gears app execute multiple tasks concurrently without blocking the main UI thread. What I find interesting thing about WorkerPool is that threads only communicate by message passing and that there is no API for synchronizing access to objects that are passed around between threads. This is a departure from the traditional concurrency toolbox in imperative languages — using synchronized access to shared memory.

It’s so easy to use it’s almost… Erlangy :)

So how does Google Gears pulls off this feat of simplicity?

Google Gears only lets you send strings between threads. Since Javascript strings are immutable, there’s no danger in letting multiple threads share them.

This solution is clever, but it comes at a cost — you must serialize your objects before sending them between threads, which incurs a performance penalty (some extra coding, too). I don’t expect the performance penalty to noticeably impact most Google Gears apps, though, which are mostly offline adaptations of standard webapps.

Google Gears has managed to pull off easy concurrenc