[hebdo]

Varnish cache.

1) Configured via a special DSL (Varnish Configuration language) that gets translated into C, compiled and loaded into the Varnish process via a .so. Perfect combination of expressiveness and speed. You can even inline raw C code in it!

2) Heavy, good use of virtual memory. Varnish allocates quite a lot of gigabytes and leaves it up to the operating system to decide what should be in RAM and what should be on disk.

3) LRU garbage collection of cached objects requires a synchronized priority queue. Varnish people transformed the decades old idea of implementing a heap in an array that every CS graduate knows and came up with a faster, paging-aware solution (http://queue.acm.org/detail.cfm?id=1814327).

[amelius]

Nice, but they are solving a problem that is not all that hard. For example, I'd rather see a beautiful implementation of a concurrent garbage collector (which probably doesn't exist because it is almost impossible to achieve; a purely functional programming approach doesn't even apply here). Or how about a beautiful implementation of a web browser?

[nickpsecurity]

"Nice, but they are solving a problem that is not all that hard."

Apparently it was hard if it took that long to get a great, clean, FOSS solution to the problem.

[amelius]

Well, in any case, I've never heard of a government software project being overdue because their proxy cache contained spaghetti code :)

To be clear, I'm not trying to denigrate this project in any way. I'm just saying that the complexity of the problem should be taken into account here.

[inopinatus]

Maybe this will change your opinion. I recalling helping rescue a government software project that was horribly behind schedule. One of the many issues being an e-learning system for a state department of education. Their CMS (Blackboard) was fronted by a forward HTTP proxy/cache/load-balancer that was misbehaving but near-impossible to debug. Details a bit hazy now but I recall it being a hairball of poorly written java. I ripped that out and replaced it with Squid and some rewrite code.

HTTP intermediate services are easy to write, but operate in a hostile and chaotic environment; they are very very hard to make reliable, performant, interoperable, secure, forgiving, and compliant. To achieve that and still have elegant code is really something so yay Varnish.

I'm a bit of a fan of the Dovecot mail server source for similar reasons (but I'm biased, having made a small contribution and got into the authors file)

[jrochkind1]

Nice. I'm pretty sure that for any "a government software project being overdue because X", there is such an X... and someone on HN was there.

[Thirdegree]

The government should stop hiring HN programmers, that's clearly the problem!

[c_lebesgue]

I think the complexity of the problem actually speaks in favour of Varnish. The Unix philosophy of writing software is based on the principle of doing one, possibly small thing very well. And that's exactly what Varnish does: it is a reverse-proxy cache that can optionally do a bit of preprocessing on the incoming HTTP requests.

Besides, it's not trivial to write a high performance HTTP cache.

[amelius]

> Besides, it's not trivial to write a high performance HTTP cache.

Certainly true.

I guess that for me "beautiful code" invents some abstractions that transform a problem that initially seems dauntingly difficult into something that is easy to reason about. A proxy cache does not, for me, satisfy the first part of this premise, although I can imagine that the details of such a project take a lot of effort (hence "not trivial", but in a different way).

[qwertyuiop924]

>I guess that for me "beautiful code" invents some abstractions that transform a problem that initially seems dauntingly difficult into something that is easy to reason about.

Well then, look no further than any RDBMS.

Seriously, for as much as people sometimes rag on the relation model, it is amazing for its power and relative simplicity.

[nickpsecurity]

The complexity of the problem is significant enough that there's only two verified HTTP servers I recall and a specifying/verifying a web app was considered good work. The bugs, inconsistent perfirmance, and CVE's in various caches also suggests they're not dead simple.

They're certainly easier to write than a lot of software. Their simplicity is deceptive, though, when real-world isdues come into play. Esp if result is to be beautiful.

[imtringued]

Concurrent garbage collectors exist. It's nothing new or special. The problem is you need read barriers which means your garbage collector ends up slowing your entire programm significantly down. For some reason Intel and AMD decided it's not worth it to add hardware acceleration for read and write barriers so end up paying a lot of $ for custom designed processors from Azul if you truly need a concurrent garbage collector.

http://www.azulsystems.com/products/vega/processor