Why did OKCupid write their own web server? | Hacker News Reader

Why did OKCupid write their own web server?

answers.onstartups.com

154 pointsmhp104 comments

My only real complaint about the nature of HN is the (as perceived by me) strong anti-C++ bent, like the ones in these comments, from what seems like people who don't have lots of experience using it in the work place. Am I imagining this anti-C++ bias? Am I wrong and all the people bashing C++ have tons of C++ experience?

I'll be the first to point out the numerous flaws C++ has but it just feels like folly to make fun of the ugly chick at the party without realizing everyone at the party is covered in warts... (The is a metaphor for all programming languages having problems)

With a tiny team of very smart programmers, starting from scratch, C++ can certainly be made to work.

I wrote a web server in C from first principles back in 2001* for many of the same reasons that OKCupid seem to have done - and with a team of one good programmer that worked out really well.

* http://web.archive.org/web/20070705191513/http://www.annexia...

C++'s reputation was negatively affected by Microsoft's studied dominance of university CS curricula. Back in the VB days C++ was the step up and I still see it in job ads on par with Java (Sun's side of the curriculum equation), though by now I merely read it as a veiled call for university graduates who learned programming only in school, coderbots.

"Coderbots" - Why be so derogatory? There's no need to be. Who knows, maybe someday you will meet someone who only learned programming in school who is faster than you.

There's more to writing code than writing it fast.

Oh, there are lots and lots of people faster than me! My use of the term is more in line with how they were used rather than anything having to do with the core of their being.

Negative. C++ had the reputation of "computer science educated" back when the average CS grad could barely spell Microsoft.

Rather than "Microsoft ruined everything", nearly the entire commercial software industry standardized on C++, and entry-level "coderbots" was who they wanted to hire out of school.

C++ lost its sex-appeal because its simply more interesting to do web startup things than to be a junior coder at Big Software Inc.

(I'm a recovering C++ dev).

C++ has problems unique to C++: a deceptive illusion of abstraction (what Spolsky would call "leaky" abstractions) makes a bunch of idioms in the language dangerous, including virtually all "smart" pointers, iterators, exceptions, allocators, and arrays. It is uniquely difficult to write reliable code in C++.

Add to that the superficial but more practical and common complaints against C++: the ghastly compile times, the header file dependency hell that forces every class into a kabuki dance of "pImpls" and nested classes, the error messages rendered in ancient Sumerian... you know I could go on, but you get the idea.

C++ is just not a very good language. C is a fine language. If you are building a system for which C's abstractions are inadequate --- and I'll stipulate that such systems exist --- you're better off with C and a very good glue language (Lisp and Lua are two good, popular choices) than you are with a uniform C++ implementation.

"C++ is a powerful language with flexible solutions to problems that other languages don't have."

"C++: An octopus formed by nailing extra legs to a dog"

> C++ is just not a very good language. C is a fine language.

This is the attitude that I really, truly do not get.

If I want a linked list or any other common data structure in C++, I include the appropriate STL header and declare an object with the template syntax. It's two easy lines of code. If I want a data structure in C, I have to write it myself. From scratch. Every time.

C++ is a powerful high-level language. C is a low-level language where everything is explicit; I know this is "elegant" to many programmers, but really, I'm just trying to get things done, and C++ has served me far better in that practical role than C ever could.

I don't love C++; it has tons of flaws (many of which disappear if you use shared_ptr for everything). But I loathe the tedium of working in C.

> If I want a data structure in C, I have to write it myself. From scratch. Every time.

http://library.gnome.org/devel/glib/2.28/ makes C development much more pleasant. You could make the same argument against C++ if you didn't have STL.

When C was invented, half of all coding was systems programming. C does a great job of addressing that need, that's why it's a fine language.

The fact that C is not great for GUI apps does not diminish C's quality for what it is, it's just not designed for that level of abstraction.

C++ on the other hand, attempts to be designed for that level of abstraction, and so in fact you are better off writing most types of modern apps in C++ than C in absolute terms, but when compared against other languages designed for the same paradigm it falls down due to complexity overload. That doesn't mean you can't do great work in C++, but you have to really know what you're doing, which parts to avoid, etc. C++'s strength is being both fast and powerful, but most of the time you don't really need both those qualities. Game programming is a notable exception.

The "which parts to avoid" conundrum shows up as every outfit that uses it in any serious way has a different set of "which parts to avoid".

It is just a mess.

The comparison isn't between straight-C vs. straight C++. It's between C with a good glue language (say, Python or Lua) vs. straight C++.

If I want a linked list in Python, I do:

  frobs = ['foo', 'bar', 'baz'].

The equivalent C++ is:

  vector<string> frobs;
  frobs.push_back("foo");
  frobs.push_back("bar");
  frobs.push_back("baz");

The reason people like these multi-language solutions is that Python or Lua is much, much more productive than C++ (as in, many times more productive), and yet the most programs have only a very small core that needs to run fast. You can write that small core in heavily-optimized C, making it quite a bit faster than kludged-together C++, and then write everything else in Python. And the total complexity of the system is still much less than if you'd just used C++ to start.

This is not a linked list, it's a dynamic array.

http://en.wikipedia.org/wiki/Linked_list#Linked_lists_vs._dy...

That's a pedantic comment to make, given that Python doesn't care about the difference. Ruby calls the same thing an "Array".

Well you've clearly never had to worry about memory paging and the cost of indirection, like I have (actually from memory I think you must have at some point?). The difference is real and significant. Try writing a particle system using a linked-list over a vector, the speed difference will be crippling. I really feel that most of the hatred for C++ stems from people not understanding why such complexity exists in the language.

The point is that you don't have to worry about the difference in Python, because you don't use Python for the parts where performance matters. If you've got a million instances in your collection, you probably want to write your data structure and key traversal functions in C. Python has a sequence protocol, so you can easily wrap it to operate on it just like a native list (which is really a vector), but the operations that need to be fast should be in heavily-optimized C.

In every system I've written, there's been a large chunk of code that runs on startup, or implements a feature that only 1% of users care about, or performs setup for one of these expensive operations but itself only touches a few data items. This usually consumes about 90% of the code but only about 1% of the runtime. Heck, probably 50% of my code never makes it to production at all, because it's exploratory or analysis code that's intended to define the problem, not implement the solution. Why not write it in a language that makes you really productive, and spend the time saved to optimize the hell out of the remaining 10%?

The performance difference between a vector and a list has nothing at all to do with what we're talking about. Stop picking random things in the discussion to nerd out about. We get it, you're awesome. The point is that in Python the distinction isn't made.

Python has a linked list type (collections.deque), but their standard list type is a dynamic array/vector and so has entirely different performance characteristics. Treating it as a linked list could screw you. I don't think that's pedantic at all.

...which is why both the Python and C++ examples used a vector.

The post I was replying to said "If I want a linked list or any other common data structure in C++". The discussion is about how easy it is to use basic data types, not about what those data types are.

No, it does. There's a type in Python called "deque" that more closely resembles the performance characteristics of a linked list.

I agree that this is not the main point of the discussion, though.

Noob here. Where does ObjC fit into all this? I know it's primarily used in Mac development, but is there any language-specific reason it's excluded from these debates?

Imagine the good high level language, like Lisp or Lua, stepped into the teleportation chamber from _The Fly_ with C.

It is not a terrible language to write in, once you get over the verbosity; it is not, for instance, the waking nightmare that C++ is. But as a deployed system it is the worst attributes of C and of interpreted languages: a complex runtime in which many (probably most) of the errors that can creep into deployable Ruby code can bite you even though your code passed both compilation and static analysis.

Its high-level constructs for the most part share the same reliability issues that C++ has; exceptions, for instance, are not really any safer there than in C++.

Blocks are nice, but I say that having only used them within the past few months. It could just be that the zombies haven't eaten their way to my particular shelter yet. They may, for instance, turn out to be horrible to debug.

Imagine a variant of C or C++ that you have to unit test as vigilantly as Rails code, and you're not far off the mark.

The retain/copy conventions are inconsistent for Blocks. But once you're aware of those, I haven't seen any major issues in using/debugging them.

C is a good statically-typed language, but it's a bit basic.

ObjC is a good statically-typed language.

C++ is half a dozen good statically-typed languages, all fighting for supremacy like a ham actor's "multiple-personality-disorder" shtick.

ObjC can use both static and dynamic typing.

ObjC isn't statically-typed. Static typing informations only allows the compiler to warn the programmer about type mismatch. From the official docs:

"Statically typed objects have the same internal data structures as objects declared to be of type id. The type doesn't affect the object; it affects only the amount of information given to the compiler about the object and the amount of information available to those reading the source code."

Objective-C is a good statically typed language? I must admit that this is new to me...

How exactly is Obj-C "good"? Is it safer than C? Perhaps less verbose? Or maybe it's easier to use - libraries aside? Is it better because it runs on more platforms? Because it's standardized?

If all else fails, I think it must be the way that it manages to merge two completely different programming paradigms by just stapling them one onto the other.

In C++0x it is

    std::vector<std::string>> frobs = {"foo","bar","baz"};

> The comparison isn't between straight-C vs. straight C++. It's between C with a good glue language (say, Python or Lua) vs. straight C++.

You can use several glue languages with C++ rather more easily and powerfully than C. See chaiscriptor QTScript. Also luabind and perl and python C++ bindings. Introducing scripting glue languages into the equation only further strengthens C++'s advantages.

> The equivalent C++ is:

The new initializer syntax is widely supported enough now. You can write:

std::vector<std::string> frobs {"foo", "bar", "baz"};

And even if you don't have a newer compiler you can use boost assign. http://www.boost.org/doc/libs/1_46_0/libs/assign/doc/index.h...

Everybody here knows you can bind to C++ instead of C. What they're saying is, if you have Lua or Python, C is virtually certain to be enough; the higher-level architecture/object graph stuff is better dealt with in Python anyways.

This claim sure doesn't jive to me. I got a simulation that does millions of GIS calculations involving entity tracks and regions. Moving the object graph into Perl or Python would take six hour runtimes into weeks. And writing it in C would be sheer torture.

Perhaps, but I don't think the situation would be as awful as you suggest.

It is possible to write significant revenue-producing commercial software using Lua for control logic calling compiled modules, and expect it to perform every bit as fast as a similar app written 100% in a compiled language.

I'm surprised no one has mentioned Lightroom yet.

http://www.sauria.com/blog/2008/10/09/lua-in-lightroom/ http://en.wikipedia.org/wiki/Adobe_Lightroom

Umm, I regularly do what you described (glue language + low-level language) with C++ and Tcl. This is more productive than C and glue language.

I absolutely LOVE not having to reinvent wheels like hash tables. Recently, boost added an interval data structure. I just wrote a few lines to expose those functions as Tcl commands. Whammo, I could prototype all I wanted in Tcl!

Good C programmers also do not reinvent the hash table wheel.

Yes, but each programmer has his own hash table wheel, which is most probably an undocumented, unholy mess of #defines, void*'s and function pointers.

Is it still a glue language if you have more glue than material? :P

I also find it very hard to believe that using two programming languages can be easier than using one. This affects team core skills, build systems, testing, debugging(!)... pretty much everything is the more complicated the more languages you use.

If you have more glue than material, you're doing it right. Most projects are like that - that's the whole reason you're using a scripting language, so you can get the productivity benefits for the ~90% that doesn't need to be performance critical.

And it's true that the more languages you use, the more complicated things become - but C++ itself is really at least 4 languages glued together (C, object-oriented C++, template metaprogramming C++, and the STL; citation: "Effective C++") and they often don't play well together, so switching down to Python + C, you cut that in half.

STL is great. I like STL so much that, after moving from my startup (where we did C++) to a friend's (where it was all C), I backported a void*-specialized version of STLport's <map> and <vector> libraries. It took a couple hours. The pain of C++ isn't worth the benefit of the STL; fortunately, you don't have to suffer C++ to get access to its better libraries.

It is flat-out not true that you need to write data structures in C each time you use them. The programmers that do this are, in my limited experience, uniformly bad. I wouldn't even write a linked-list for fear of screwing up a corner case on deletion. There are libraries for everything, and they're plenty fast. They're just less pretty looking.

Assuming you can use STL. Many projects can't use STL because of its reliance on C++ exceptions (cf. Mozilla or Google's C++ style guides). If your legacy code or some third-party library is not exception-safe, then you can't create reliable C++ software using the STL.

OT: Zed Shaw's Tir framework

C was a great language when it was created, considering the requirements and constraints of that time. In 2011, it is unexcusably unsafe and lacking in abstraction power - C99 included.

Almost every type of operation in C is predisposed to HUMAN error (the worst kind of error) - I/O, strings, creating a data structure, declaring a variable, calling a function even basic maths can fail in unintuitive ways. [1]

No matter how many glue languages you use, C is not going to become safer or easier to use. Furthermore, C's abstractions are inadequate for most things, even the things that it's traditionally known for,such as the Linux kernel. Take a look and see how many wheels have had to be reinvented for the kernel or any large C project.

But... you probably already know all of this. It's just that you're so comfortable with it that you're willing to forgive all of its sins.

[1] https://www.securecoding.cert.org/confluence/display/seccode...

We're not discussing C vs. Lisp. We're discussing C vs. C++.

Besides tptacek's reply, see also Yossi Kreinin's C++ FQA (Frequently Questioned Answers):

http://yosefk.com/c++fqa/faq.html

Subjectively I don't feel HN as particularly anti-C++, it's more that people are younger and started programming in languages like Python and Ruby so they don't have a pro-C++ bias. If anything I feel that many people on HN are anti-Java. Personally I'm thankful for Java's existence because it managed to replace C++ in a lot of places.

The C++ FQA is pretty impressive in its detailed and thorough dislike for C++. I'm not sure if I know of anything else quite like it in that regard. The only thing that comes to mind as being close is the UNIX-HATERS Handbook.

The Unix Haters really liked Unix; the book was an act of love. Yossi clearly wants to stab C++ in the eyeball with a fork.

Sure, but the original commenter wondered whether people who dislike C++ know C++ well. Yossi no doubt knows C++ pretty well.

I take it that you haven't actually read the Unix Haters handbook. They clearly have no love for Unix.

"Each graft of a new subsystem onto the underlying core has resulted in either rejection or graft vs. host disease with its concomitant proliferation of incapacitating scar tissue. The Unix networking model is a cacophonous Babel of Unreliability that quadrupled the size of Unix’s famed compact kernel. Its window system inherited the cryptic unfriendliness of its character-based interface, while at the same time realized new ways to bring fast computers to a crawl. Its new system administration tools take more time to use than they save. Its mailer makes the U.S. Postal Service look positively stellar."

Yeah, you're right, now that I think about it, they were definitely all Win32 people. <groans>

Seriously, can you give me any example of their love of Unix. They strongly preferred Lisp machines. Please don't make up random "facts".

It is irritating to find false statements being upvoted just because noone bothers to double check them.

Yes, the whole labor of hate argument was discussed in the foreword (written by Donald Norman):

“Sure, we love your foreword,” they told me, but “The only truly irksome part is the ‘c’mon, you really love it.’ No. Really. We really do hate it. And don’t give me that ‘you deny it—y’see, that proves it’ stuff.”

Norman remains suspicious, but the preface claims: "We have all experienced much more advanced, usable, and elegant systems than Unix ever was, or ever can be."

Personally, I imagine for many of the participants, it was a labor of hate, not of love. We could chalk up any ambiguous love to Stockholm Syndrome.

Ritchie's anti-forward is the best:

I have succumbed to the temptation you offered in your preface: I do write you off as envious malcontents and romantic keepers of memories. The systems you remember so fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture, they are fertilizing it from below.

Your judgments are not keen, they are intoxicated by metaphor. In the Preface you suffer first from heat, lice, and malnourishment, then become prisoners in a Gulag. In Chapter 1 you are in turn infected by a virus, racked by drug addiction, and addled by puffiness of the genome.

...

You claim to seek progress, but you succeed mainly in whining.

Here is my metaphor: your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy.

I know multiple people who contributed to the book personally. I think you're missing part of the joke. But I concede, I don't know all or even most of them, so perhaps many of the Unix-haters secretly do pine for Mac OS 9.

First you claim, apparently the book was an act of love, which it clearly isn't. It is as scathing as the C++ FQA. The book has a dozen authors from respected institutions and you claim to know people who contributed to the book personally but the only apparent alternative OSes you think they could have used are Windows and OS 9. I don't have too much data right now, but it certainly looks like you are making "facts" up as you go along.

I think it is very unlikely that I am making anything up as I go along to impress an anonymous stranger on Hacker News, but you can of course think whatever you'd like.

My strong anti-C++ bent comes from having used in in demanding production situations for 12 years. It is a beast. When Scott Meyers of http://www.amazon.com/Effective-Specific-Addison-Wesley-Prof... fame reads a book on C++ template programming and is surprised, no, astonished! at some of the things done there, and attempts to write auto_ptr and fails at least twice.

It takes way to long to learn (probably 2 years for a developer working with it 8 hours a day), and the grown ups don't like it either: http://www.amazon.com/Coders-Work-Reflections-Craft-Programm...

This isn't even an ugly chick.

Just saying that this thread has been fascinating and illuminating for a novice C++/C programmer like myself. It reads like a decent article comparing the two languages, though I'm no expert and can't judge for sure.

This is why I read HN.

  If you are an expert in the intricacies of C++, please
  consider this knowledge a kind of martial art - something
  a real master never uses.

http://yosefk.com/c++fqa/why.html

There are anti-C++ bias in HN. More people here are working on the Web related projects where C++ is not popular.

The questioned is phrased very much in the now e.g. Isn't the technology stack basically a commodity at this point? and

And the answer highlights why you should never retrospectively "judge" design choices several years after the fact.

I've had an opportunity to chat with some people tangentially related to OKC and I think that they have definitely done some very cool stuff. There are some things that the OKWS architecture does very well. As I understand it, there is a bit of "Rails envy" but they seem to copy good ideas very quickly. That being said, I think that if they were to start again, they would try and use commodity technology.

But, these guys are really fucking brilliant and productive. Immensely... I feel like a chump in comparison.

Yes. How often do I say, "I wish this thing ____" or.. "oh that's just not possible." They just decided to write a bunch of c++ to make it possible. Awesome!

Well these days writing an http server in C++ is about 30 lines of code using POCO or boost.asio. If your business model was "serve a shit-ton of dynamic requests super cheap" it might make just as much sense as ever to build the whole thing in C++ embedded directly in a C++ webserver.

If only writing a web app was that simple. ASIO is simply a socket library.

It comes with an http server implementation. POCO has a more full featured one.

It does? Wow, I haven't looked at it in a while then... Can you point me to a link?

We've actually had this conversation before. It sounds ridiculous, but the story is actually a little different: OKWS was built prior to OKCupid, and they inherited it. See http://pdos.csail.mit.edu/~max/docs/okws.pdf.

That doesn't sound like the answer the founder of OKCupid posted here: http://answers.onstartups.com/questions/21323/why-would-okcu...

Well, I wasn't there, so I don't really know. But here is the previous thread, where I joined in dismissing the premise: http://news.ycombinator.com/item?id=2078210.

See the two responses for details.

I could swear I remember, back when they were TheSpark, them claiming that the TheSpark ran on a custom webserver written in C++. That would be consistent with the idea that OKWS was done as Max's Harvard thesis project and then inherited by TheSpark and OKCupid later.

There are a variety of reasons why startup founders may want to bend the truth with their public statements.

OKCupid is the only web site I can think of that has a regular, not occasional, pattern of being very slow and simply not responding to an unusual number of requests. Hitting F5 to reload a page just to get it to show up instead of the Firefox server unavailable message is a regular part of my usage of the site.

Even though all sites have bugs, broken links, what have you, I don't know any other site that's given me such an expectation that it will be unresponsive for a significant number of page views for any given session over a long term period. Even the sites that started development circa 2003.

Sounds like you have never experienced Facebook like I do. I only spend about five minutes on it daily and it is all reloads and multiple clicks.

It may sound glib, but I would expect that you've described their ideal user behavior.

Damn!

We rarely get complaints such as this one. Would you mind helping me debug it?

How?

Send an email to userfeedback@okcupid.com, subject: gdulli, and I'll ask you to visit a few links. Thanks a lot, I really appreciate the help!

I get similar issues (long page loads, extremely large lag in chat and questions), while via 3G in Poland. It's not solely 3G's fault, because many other sites (including FB chat) work ok, but it's clearly triggered by a specific environment.

With landline connections OKC works very well :-)

Every time I had problems with okc it was due to broken transparent caching on wireless, cellular, or satellite networks.

Once in a while I find Chromes rendering engine slow down trying to render multiple OKC pages at once. Similar to trying to view TechCrunch only not nearly as bad.

Have you never used reddit?

That's a great example for comparison. Sometimes reddit goes down completely, maybe more often than most web apps. But it's still uncommon enough that I think of reddit as a site that "works" and I go into a session expecting it to go smoothly.

I don't think I've ever seen OkCupid down completely, not that I use it nearly as often as reddit. But I've never seen reddit have the behavior that while it's up, I can expect one of every 5-20 page views or posts to time out or fail on the first load/submit but succeed on the second or third. And this is consistent enough with OKCupid that I think about a usage session as something I'll have to be in the mood to fight with.

I see the "you broke reddit", "reddit is under heavy load" and "there doesn't seem to be anything here" messages nearly every day.

I've used okc for years and have never noticed this.

I can only speak for myself, but I've pretty much never seen OkC perform like you're describing, and I've maintained an intermittently active account since '04.

"general rpc servers for solving specific problems using in memory data structures (e.g., who qualifies for a match search given dozens of constraints and millions of users; what your match score is with 10,000 qualifying people, given you've all answered hundreds of different questions each on average) ... Great tech is available now, serving is cheaper, and you probably don't have the computational workload OkCupid does."

I know people who have used OKC before. OKC users in my social class (male, white, educated) ignore the match percentages, because the SNR is really low. They just plow through all the search results of people to find good pictures and interesting profiles.

So, I'd speculate that match-percentages are a marketing thing, and that they know they made a weak business decision which required lots of computation and now they're stuck with it.

I'm probably wrong. Maybe the long-tale users pay attention to match-percentage.

I don't ignore the match percentages at all. Obviously they aren't perfectly correlated, but they're pretty solid. People with very low match numbers are basically 100% duds.

You probably are wrong, and you imply you've never used okc. Match percentages matter to me highly since they certainly indicate users I'd get along with, based on my interactions with other users. Their data also show that messages response rates correlate strongly with match percentages.

I signed up for OKC, lurked for a while, and then sent a message to the person at the top of my match list.

We're still together, five years later.

I'm probably an outlier, but hey--match percentage works some of the time!

I think of the match percentage as the equivalent of having HR look at tech resumes before forwarding them on to me; it's not perfect, but it saves me from reading through completely irrelevant profiles.

If you have a small team and everybody has much C++ experience you can pull this off. Otherwise one person who doens't have the discipline to do the manual memory management right can crash the whole server. Don't try it at home ;) use an VM-language instead which can recover from such errors.

(I wrote some C++ webapps myself)

Manual memory management is for the birds. Use something like Boost's shared pointers and you never need to worry about it.

You can also often make clever use of RAII and STL container classes and do memory management that way.

That's not entirely honest.

A) You still have to worry about it when interfacing with libraries that use plain pointers

B) Shared pointers incur runtime penalties (larger data pushes things off the cache, spurious inc/dec-refs messing said cache. If you don't care about that, why do you use a language like C++ in the first place?

C) Reference counting is a poor form of automatic memory management, you still have to worry about cycles, and use weak references or such to break the cycles.

I'd think they'd begin transitioning to a higher level language now that there are many options available. It's gotta be a burden at this point to be (1) maintaining their own web server and (2) developing new features in C++. I'd way rather use ruby/python (or even .Net) and fall to C++ for the really performance intensive stuff.

(Disclaimer: I interviewed @ OKCupid in 2007)

I remember this coming up at reddit a few months ago[1]. At the time I downloaded and read the paper on the design[2]. It all made sense to me because my own thinking had been heading in the same direction.

OKWS is less a web server than it is an architecture of servers. It's the difference between sendmail and qmail/postfix.

It has nice security and performance properties because each service is run as a separate user, with a separate process. Logging is handled by an independent daemon. Request demultiplexing is handled by a simple daemon that binds to port 80. Actual HTTP parsing is handled by a shared library that services link to.

[1] http://www.reddit.com/r/programming/comments/exkk3/ok_webser... [2] http://pdos.csail.mit.edu/~max/docs/okws.pdf

Any languages could possibility be made to work. They did make it to work with things like SFSLite[1] which looked like coroutines or fibers (actually Stratified JavaScript, but that is not something common) would solve for async callbacks. However, those are something that is acting as extensions to the core language.

One of the biggest problem C++ has is the fact that core language has too many stuff but still lacking things that people really want to use. It's certainly workable, and the results are fast since it is compiled very well. However 'workable' does not mean 'a pleasure to work'.

[1]: http://www.okws.org/doku.php?id=sfslite:tame2:tutorial , http://www.okws.org/doku.php?id=sfslite

I imagine one big downside of this custom stack is that they will have a hell of a time doing any sort of integration with Match.com.

Hiring and training is also probably more difficult, though that has got be a huge boon to OKCupid engineers since Match cannot afford to lose them.

Ha, it gets better: the web server "was partially funded by the DARPA Composable High Assurance Trusted Systems program."

http://www.okws.org/doku.php?id=okws:sponsorship

Wait, the OKWS web site runs on apache?

That was explained in a FAQ previously on the site. OKWS is meant for serving highly dynamic content, while they feel Apache is better at static and more modest dynamic content. Their original philosophy was that segregating dynamic and static serving improved security, stability, and speed, though that's mostly been nullified by cheaper hosting.

Reply on news.ycombinator.com