Hacker News new | past | comments | ask | show | jobs | submit login

I might get a few details wrong; but HN certainly was inspired by reddit.

Reddit was originally written in Lisp. Paul Graham had actually written an article about how Lisp was his secret weapon when building his Yahoo-acquired Viacom. Reddit was one of the first YC companies so I assume their language choice was inspired by this.

Soon after launch reddit had performance issues and was rewritten in Python. This improved the site stability but angered one of reddit's original user base of Lisp fans. Around the same time Paul Graham started hyping a new Lisp dialect he was writting called arc [1]. It's what powers HN.

Arc stores the stack and a set of continuations for each possible client action in memory on the server. These are referenced on the client by a fnid. This is actually the source of the next-page errors you'll see here; continuations are purged in least recently used fashion so as HN outgrows its single server the lack of memory makes sessions expire more quickly.

I believe both HN and reddit (which had a second Python-based rewrite) are now open source. There is nothing stopping Paul Graham from using reddit's source code; but I believe the arc code is leaner. HN runs on a single piece of hardware to this day.

1. http://en.wikipedia.org/wiki/Arc_(programming_language)




> Soon after launch reddit had performance issues and was rewritten in Python.

The reason was explained here:

http://blog.reddit.com/2005/12/on-lisp.html

I quote:

Emacs and SLIME are a killer combination, but I develop on a Mac, and reddit.com is a FreeBSD box. On my Mac, my choices of threaded Lisp implementations was limited to OpenMCL, and in FreeBSD it's CMUCL. Because of the low-level socket and threading code we had to write, reddit would not run on my Mac, and I was always tethered to our FreeBSD development server. Not being able to program offline is a pain.

If Lisp is so great, why did we stop using it? One of the biggest issues was the lack of widely used and tested libraries. Sure, there is a CL library for basically any task, but there is rarely more than one, and often the libraries are not widely used or well documented. Since we're building a site largely by standing on the shoulders of others, this made things a little tougher. There just aren't as many shoulders on which to stand.

Back in 2005 Common Lisp had a fragmentation problem: not all libraries would work on all implementation/os pairs and not all implementations would work on all operating systems (in fact iirc no open source implementation would work on windows, freebsd, linux and mac)


Thanks for the details - am clear now :-)


I always wonder how HN works without cookies. Can you share some insights on that?


HN does actually use a cookie called "user" when you login to keep you logged in. But for page to page state it uses an id in the url. That's why a lot of the internal links have a "fnid" in them and why you can't share those urls.


Like 'almost' said; it does use cookies to remember you between session. In practice they are not strictly needed.

In a traditional web server the request comes in, some operations are performed to product an output, and the server discards all state. When the next request comes in the server handles it from scratch; authenticating sessions, loading objects in to memory, etc.

In arc, when a link or action is generated the interpreter (I think) the stack is captured an serialized. This, and he closure that the link would execute, is referenced by a unique fnid. When the user clicks on a link the server restores the previous stack and executes the closure as though the response and new request cycle never happened.

This makes it very easy to write web applications; you can concentrate on the exact flow you want rather than creating a bunch of separate-but-linked controllers that have to duplicate a lot of logic. On the down side it does violate the stateless nature of the web. I can't take a link and sharers with you. URLs become meaningless; instead of pointing to a resource they become merely a way to communicate state back to the server.

As a disclaimer: I haven't actually built anything in arc. I have peeked at the HN source code though. I do believe that it does use the traditional-style request handling for some parts where storing the stack causes issues or is unnecessary (e.g. A link from homepage to article uses a traditional stateless URL).


it DOES work with cookies. At this moment I have a cookie from ycombinator called "user".




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: