Comment by akkartik | Hacker News Reader

Comment by akkartik | Hacker News Reader

Parent Full thread

At the very least his point about continuation-based webservers is a good one.

I recently realized why the arc webserver needed to track IPs to ignore almost from day 1: everytime somebody requests a page, memory usage goes up. This includes crawlers, drive-by users, everybody. The standard way arc encourages webapps to be programmed (http://paulgraham.com/arcchallenge.html) is by leaking memory. Every load of the front-page creates 30 closures just for the 'flag' links. Ignoring IPs is just a band-aid to cover up this huge sink[1].

I've been programming in arc for 3 years and am still active on the arc forum. I love that arc is a small and simple language without lots of bells and whistles[2]. I really couldn't care less that it's 'not taken off'. But there's a different between toys that encourage exploratory play, and painting yourself into a corner design-wise. I now think of continuation-based webservers as an evolutionary dead end.

[1] Another ill-effect of the ip-ignoring is that every newcomer to arc who tries to run it behind a proxy server immediately runs into a gotcha: The arc webserver now thinks all requests are coming from the same IP address and so throttles everybody. http://www.arclanguage.org/item?id=11199

[2] If you spend any time with it it literally begs to be tinkered with. And the experience of programming in a language while referring to its compiler in another window is something everybody should experience.

I'm not sure what you mean by continuation-based. The Arc server can use closures to store state, but it doesn't use continuations.

Using closures to store state is like using lists as data structures: it's a rapid prototyping technique. You're in no way painting yourself into a corner, and the current news software is proof of that. You have a very old version of it. In the years since we released the version you have, we've gradually squeezed most of the closures out of the more common things, and we do have a proxy in front of the Arc server. That's how we manage to serve 1.7 million pages a day off one core.

I see. Yeah, I stand corrected.

I was conflating continuation-based and closure-based webservers because both allow straight-line code instead of explicitly managing url handlers.

And the traditional rhetoric in favor of this technique has come from Seaside, which popularized the name 'continuation-based' (http://www.linux-mag.com/id/7424; http://www.bluishcoder.co.nz/2006/05/server-side-javascript....)

I'd never seen anybody say this is just an early-prototyping technique. But searching found Patrick Collison concur: http://www.quora.com/Whats-the-best-continuation-based-web-f...

It was too harsh to say it paints us into a corner; it is possible to replace fnid links with new defops. I went back and looked at the frontpage when not logged-in, and saw that there are 0 fnid links in that common case. (One possible way to gradually use a second server would be to just serve the frontpage off it. You'd need to move to a centralized store for user/profile/story objects, but the fnids table could continue to live on one server.)

It also turns out that there's at least one company trying to scale continuation-based servers (http://bc.tech.coop/blog/040404.html). So it was overly harsh to call it a dead end.

PG: It could be instructive to be able to compare your new version with what is currently available.

His point on continuations is invalid.

"The problem: because closures can’t be stored in databases, you really have to use a hash table on your web daemon."

This is not true. Closures can be stored anywhere you want.

Yea, I think Gödel had something to say about this.

Reply on news.ycombinator.com