ErlyWeb storms the Bay (FP)

Yariv presented his work on a very scalable web framework, ErlyWeb, at tonight's meeting of BayFP.

It was interesting to see an Erlanger's take on this CRUDy world. Some personal highlights:

• He practiced the talk on his girlfriend, forcing us to "man-up" as Kurtis would put it
  
• Calls are handled through a pipeline (like HApps commands?)
• Controller functions with corresponding view functions (one-to-many)
• Component system for server-intensive components (think Amazon.com)
• Hot swapping support
  
• He simulated running 80,000 processes - how many can Apache do?
• He doesn't directly use Wadler's type annotation/checking tools
• Yariv doesn't really unit test
  

One thing he focused on in the talk was comet support, which is a Big Thing (tm) for AJAX/RIA folks. While some browsers explicitly support it and FRP has a story for how to code the client using it (with or without browser hand holding), it's a little ambiguous on how to write good server code to use it. Here Erlang steps in: lightweight processes with absolutely no shared memory can idle for as long as you want - no harm putting them on to disk, even. This really puts the ball back into the browser's court.

Web frameworks focus on being developer friendly, and while I don't traditionally put Erlang into that camp due to the preponderance of message channels, Yariv's examples impressed me. The presentation further pushed me to wanting to do a little hacking to get a feel for typical code in such systems, and then find message passing patterns that could benefit from sugar like automatic lifting in transparent FRP or how to interface with such a system in the client world.

Additionally, the story on hot-swapping was great. Whenever you write an infinite loop, you do so using recursion. If your loop gets a 'swap' command for the next iteration, instead of doing the normal recursive call to handle it, invoke yourself as a remote call, and voila, hot-swapping. You could write your comet code like this as well.

As a funny point, I'm trying to write up notes for a discussion section tomorrow on points-to analysis. Someone mentioned tonight that method lookups for objects masked by interfaces are not actually constant in Java - bingo, motivation :) [With some glossing over the rules to handle dynamic class loading]. Ras challenged me to show how a dynamic type analysis differs from a points-to analysis, so I'm still considering that one. Usability - perhaps in the guise of the minimum description length principle - sounds lame.