[chendies]

This is very impressive. I wonder what the server costs to run a website like Reddit would be if they hadn't used Python and instead used assembly, C or C++.

The benchmarks game [1] suggests that C++ can have a speedup of 10x to 100x for many toy benchmark programs and use far less memory. A highly optimized assembly version could add another factor.

While code closer to the metal would require higher investments in coding, it would be drastically easier to scale. And in the long run, server costs will dominate, so it would be beneficial to reduce those.

Who knows if Reddit would be cash positive if their codebase were written in a different language?

[1]: http://benchmarksgame.alioth.debian.org/u64q/cpp.html

[gtirloni]

They probably wouldn't be able to find enough assembly developers on any consistent basis (i.e. major risk)

[spc476]

Two stories. Years ago I wrote code to parse email messages in C. And by "parse email" I mean parse the headers into usable C structures. Looking back through git history, it appears it took me about a week's worth of coding to get all defined email headers parsed using 1375 lines of code. And I never did fine an acceptable structure to store the contents of say, the To: header (can't be an array since you can include named groups).

More recently, I re-approached the same problem, but this time using Lua (and LPEG). It's easily half the code (658 lines) and this time, it was rather easy to store the contents of the To: header (given the nature of Lua tables). And while I suspect the C version is faster (honestly, I don't know---I haven't actually measured it) the Lua/LPEG version probably does give it a run for its money (LPEG compiles into its own parsing VM). It took a days worth of work (plus a few bug fixes here and there).

I can't imagine doing this type of project in assembly language (and I did nothing but assembly work for ten years, mid-80s to mid-90s). It'll be largely the same as C (read byte by byte, jump tables etc.) but you also have the overhead of dealing with calling conventions---you either juggle parameters into registers, or spend half your time pushing data onto the stack. It becomes real tedious real fast.

Second story. At work, I was told to look into this SIP stuff. So I did. And I wrote code in Lua/LPEG to parse SIP messages (given that it's the same base format as email messages, why not use something easy write to play around with this stuff?). Pretty soon, it became the product (sigh---the prototype is the product, but that's a rant for another time) but it turned out to be fast enough to handle actual telephone network traffic levels. It also received an unexpected load test as fewer instances were running than expected, and a routing issue caused about 3x the expected traffic. All that and I've yet to profile the code [1].

So, would Reddit have more money with a different language? Well, it was rewritten once from what I understand, but I think that was from a language only a few have experience with to one that has a larger coding base. I don't think you'll find the number of programmers capable of out-writing a compiler with assembly that you will with PHP, Java, Python or Ruby experience, never mind the negative responses you'll receive from the anti-C crowd.

[1] To be fair, the code is only taking SIP messages, parsing for some expected information, repacking that up into another (proprietary) format to call the business logic component, which is written in C++ [2], taking the results and sending a new SIP message. So it's not doing that much overall.

[2] Because the developer thought he was programming this for a 1MHz 6502 with 16K of RAM, even though it's running multiple 64-bit SPARC [3] boxes with 24 or 32 cores and gobs of RAM but again, that's another rant.

[3] Because of telecom requirements for power; I suspect if we could have found x86 boxes that met the requirements, we would have used them.