10 ms·

Web programs written in C++ are no big deal

118 points by sciurus 15y ago

rubashov 15y ago
This plus something for disk persistence is totally sufficient for writing web apps in C++: http://cgi.sourceforge.net/ http://cgi.sourceforge.net/
- akkartik 15y ago
  Disk persistence was actually the question I came to this thread with after reading the article.
krf 15y ago
qDecoder by Seungyoung Kim (www.qdecoder.org) is a terrific open source library for using CGI with C and C++. A lot of us did what this article mentioned - but probably in the 1990s when desktop programmers were moving to the web. Most probably settled on Perl after trying C and finding development was much faster with Perl.
_delirium 15y ago
I agree they're not a big deal per se, but I do find them clunkier. Facebook seems to agree, and argued that it was worth expending the considerable engineering effort it took to write a whole new PHP runtime, just to avoid the obvious alternative, writing more of Facebook in C++. Though Google does write a lot of its backend stuff in C++ successfully, so culture and what kind of web software you're writing may be part of it.
- alexchamberlain 15y ago
  No, Facebook had LOADS of PHP code thst sas failing terribly. It was easier to write a PHP compiler that a rewrite in C++.However, now they have control of the compiler, they can probably slowly replace the PHP with C++.
gaius 15y ago
Ah, you kids! Back in the '90s, we thought nothing of building websites in NSAPI.
hackermom 15y ago
For those who never dealt with the server end of the web in the mid-to-late 90s I can tell you that native executables for CGI was at that time not the least rare or uncommon.
- biasedstudy 15y ago
  Having a lightweight, standalone executable with quick start up time is still a major win.
  - cageface 15y ago
    What about caching database connections? Opening a new connection on every request can be very slow, particularly for Oracle.
    - javadyan 15y ago
      One may consider using FastCGI to avoid the costs associated with starting a new process with each request.
akkartik 15y ago
Perl and python and ruby aren't just easier because they have more libraries. They're easier because they have hash literals, a more flexible module system, etc. (ahem, implicit/dynamic type checking) I agree that the reliance of rails apps on gems is unfortunate. They're rediscovering DLL hell for themselves. But the original DLL hell was all C++ apps. You can shoot yourself in the foot with over-reliance on libraries in any language.
- NathanWong 15y ago
  It's not clear that this comment is addressing any real issues. Firstly, std::unordered_map is officially part of C++ now, and it's been available in all major compilers for a long time. Secondly, there's no substantial evidence provided to support the claim that the module system in a dynamic language is "more flexible" - anytime you want to include someone else's code in your source tree in any language you can just drop the source in as though it was your own. Whether there's a "package manager" to hide the references for you is beside the point; it's not as if the concept of shared libraries is lost upon C and C++. And "ahem" does not establish a valid argument as to why dynamic type checking is "easier" (whatever that even means). In fact, I believe a strong argument could be made that dynamic type checking is the worst aspect of dynamic languages, and the interest that Haskell has been brewing up lately would tend to support this. Static type checking brings bugs to the forefront when the developer is in the room instead of the user. One could argue that runtime reflection provides more flexibility and thus makes dynamic languages "easier", but it's a stretch to extend that to dynamic typing. I'm unsure of how DLL Hell would even apply to a SaaS application, unless we're referring to completely different things; you have complete control of your application's environment in a web app. If there's a package already installed that you don't want or something is missing, you remove it or install it. With the prevalence of virtualization and virtualization-as-a-service, there's no reason to be trying to run two different applications that require different dependencies on the same virtual box.
  - akkartik 15y ago
    It sounds like you're claiming C++ is as convenient as a 'HLL'. If so, I think the divide is too great for us to talk across. I've worked in C++ for ten years, but I think scripts in perl or python are more convenient for many tasks. I haven't met anybody who disagreed about something so basic, so I'm not sure how to respond. I use unordered_map all the time, but I wouldn't claim it's the same as support for literal hash-tables in the language. Implicit typing is useful if I am happy to allow my tasks to die at runtime because I screwed up. After all, C++ apps often segfault when I screw up.
boneheadmed 15y ago
I have to say that I like the perspective. I think that a good programmer should be able to use virtually any good language to create anything. In particular, it seems worthwhile, if for example one is well versed in say Ruby, to learn C to get at the root of what is occurring "under the hood". I really enjoy Ruby, but I'm learning C to fully immerse myself in what is occurring with the bits and bytes (or at least the bytes).
drivebyacct2 15y ago
Why C++? Go (golang.org) is too much fun!
- drivebyacct2 15y ago
  I wish I could edit this comment, I think more explanation would have helped. Go is low level (originally marketed as a systems-level language), but it really is truly fun to use and it has whole swath of really comprehensive libraries for throwing together web apps very quickly. (SPDY, WebSockets, and much more, but I appreciate those features out of the box)
tptacek 15y ago
Writing C++ code that works reliably in a benign setting is not a big deal. With the right libraries, it is almost as easy and perhaps only a little slower than writing in a high-level language; you can't, for instance, really believe that everyone who writes a popular iOS application is a solid bare-metal C programmer. But writing reliable C++ code that works under adversarial conditions is very hard; hard enough that the best C programmers in the world have track records like "only one theoretically-exploitable memory corruption vulnerability in the release history", and quite a few people who set out with "no vulnerabilities" in their project charter end up with way worse records. I've found over the last couple years that one way to get C/C++ code fit into a web application is via "nosql" databases, particularly Redis; let something like Ruby/Rack or Python/WSGI or Java Servlets soak up the hostile HTTP traffic, and use it to drive an async API over Redis. The less C/C++/ObjC code you have talking to an adversary, the better off you are. I'm a C/C++ programmer; C is my first language, from when I was a teenager. I respect C programmers. But if I was interviewing a developer and they told me their gut was to write a C program to do something a Rails program would normally do, and it wasn't an exceptionally specific circumstance, I would think less of them.
- bri3d 15y ago
  In this worldview, wouldn't the C programmers writing your language runtime have the same poor track record when it comes to security? And wouldn't the runtime itself be a substantially higher-value target for attackers? I, too, would look at someone strangely if they told me they were going to write a C application where I'd use a Rails one, but security certainly wouldn't be the first reason on my mind. As a postscript, I really like the idea of putting C/C++ apps behind a message bus, as decoupled from the web end as possible. I've had great luck using C++ for performance-critical services behind a Rails frontend talking to Redis (I've also used AMQP via RabbitMQ, but I found that to have a high enterprise brokered pain to value ratio).
  - tptacek 15y ago
    They do have a poor track record with the language runtime. You should be concerned about the quality of your language runtime. MRI, for instance, has had many memory corruption flaws that were plausibly exposed to hostile input. When security is a priority, I advise using JRuby (it helps that JRuby is better than MRI anyways). But either way: language runtimes for mainstream languages are high-priority targets. Your C code is not. You will not learn the worst problems in your C code until long after it's been deployed.
alexchamberlain 15y ago
THANK YOU! I totally agree that it is not unreasonable to write websites in C/C++. I've just started looking into writing Nginx modules, which are generally written in C. Now that I've started to understand it, I can write secure content handlers in a reasonable time and reasonable effort, whilst being able to use the exhaustive libraries on offer, as well as my experience with the language. Couple this with great performance, and I can't justify writing apps in PHP anymore. We're moving more and more processing to the client , as we have realised that networks are pretty slow. Well then, how do you justify writing slow code behind the slow network? I highly encourage the author to look at writing Nginx modules, possibly not on a hackathon, since you get security and fantastic performance for free!
petercooper 15y ago
[..] I haven't had a reason to touch them. The few times I've seen or heard about them, it's all been linked to frothy people clamoring for the latest shiny thing. Avoiding a technology by applying a frivolous standard like this is a good way to miss out on useful learning experiences. "Doing" is great, but stretching your boundaries and trying new things outside of your comfort zone is an essential part of being a well rounded programmer.
- rachelbythebay 15y ago
  Ah, you grabbed onto the second sentence while dismissing the first. I avoid them because I haven't had a reason to bother. The task could be accomplished some other way, and was. I've used plenty of things used by "foamers" out of necessity. I don't enjoy it, but it does get the job done.
  - petercooper 15y ago
    I've used plenty of things used by "foamers" out of necessity. I don't enjoy it, but it does get the job done. An unpleasant subset of a technology's userbase has no relationship to the usefulness or learning experiences relating to the technology and is of no relevance to the well-rounded, life-long learner. Being distracted by the who in technical pursuits is a burdensome impediment against learning the valuable whats and whys.
    - rachelbythebay 15y ago
      You have to work with the 'who' to actually get anywhere with some of this stuff. And some of these communities are less than friendly. Some of them are outright hostile. Does that help?
      - kragen 15y ago
        Also, the other users of Ruby are the ones who wrote the libraries you get to use in a Ruby program. Which is pretty relevant to the person in a nearby thread who implicitly equates using the Linux virtual memory system to using Rubyful Soup.
jacques_chester 15y ago
The big reason for avoid C++ is to avoid bugs and security issues. In particular, overflow attacks. That the language requires constant, conscious diligence to achieve a security baseline that comes for free in other languages is wasteful. Then there's the library/tools situation. I did all the work for my honours dissertation in Ruby in part because the Ruby ecosystem is vast and vibrant (sometimes inconveniently so). I imagine that the C++-for-the-web ecosystem is going to be a bit more spartan.
- VikingCoder 15y ago
  > That the language requires constant, conscious diligence to achieve a security baseline that comes for free in other languages is wasteful. For extremely expensive values of "free."
  - jacques_chester 15y ago
    Could you elaborate?
    - VikingCoder 15y ago
      No language exists yet that is aware of all security issues. No matter what language, library, framework, toolset you use, you need to be aware of multiple vectors of attack. Claiming that some languages solve these problems for you, for free, is disingenuous.
      - jacques_chester 15y ago
        That's not what I claimed. I pointed out that languages with safe string handling and memory management have a higher security baseline. As in, what you start with, for "free". Achieving comparable string and memory security in C/C++ is an expense. You must take active steps to prevent those exploits; and even then human error means that you will have a higher risk than the "free baseline" languages.
pshc 15y ago
* Dismissing newer technologies as "shiny" instead of evaluating their merits * Language hipsterism * Being disturbed by modular code * Dismissing high-level code that might have leaky abstractions * Plain CGI * Being turned off by callbacks and reinventing the wheel instead * The usual silliness about all tools being capable and therefore equal (they're all Turing complete, yes, but we still want to know which ones are more productive for some use case.) This is grumpy posturing and C++ is now blub. Am I being trolled?
- Rusky 15y ago
  Dismissing newer technologies as "shiny" instead of evaluating their merits I would think it's more about trying not to dismiss older technologies just because of the merits of something newer. Being disturbed by modular code The C++ code described in the article sounded pretty modular to me...
- baddox 15y ago
  I think the point about reliance on and obsession with modular code is a valid one, even though it's so entrenched in programming culture now. Donald Knuthe makes a similar (much less inflammatory) argument here (Ctrl-F "black box"): http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856
- uiri 15y ago
  Just wondering, what exactly is wrong with plain CGI?
  - javadyan 15y ago
    I assume he's implying that CGI is slow.
  - iso8859-1 15y ago
    With CGI, you do your own data persistence. It leads to gigantic blobs. Also, you spawn a process for each request. http://stackoverflow.com/questions/424839/what-were-the-main-disadvantages-of-cgi-bin-based-web-development http://stackoverflow.com/questions/424839/what-were-the-main... As I see it, it's the old low-level vs high-level discussion all over again. I'm sure you have seen it before. Low-level programmers argue that they have control and know how everything is working. High-level programmers argue security, problem isolation, modularity (i.e. not only using your own code!), readability, maintainability.
pnathan 15y ago
I left C++ a few years ago. It's not that it's a "bad" language, for a certain value of bad. It's just bloody inefficient to get things done in! Coding in it requires girnormous amounts of text shovelling, typing attempts to be strict, template meta-programming requires hand-coding type inference schemes, and on top of that, the library/package management is a nightmare. Well, I didn't think these harsh things when I 'left' C++, but as I worked with more high-level languages, I realized that I was doing more, with less code and dynamic duck-y typing, and with nice libraries only a `cpan` away. So when I hacked together a C++ program a year or so ago, I got punched in the face by all these issues. It was a pain. So I said, okay, this is stupid. I need to use C for low-level work like drivers, and use Common Lisp for other things. Like what everyone else does[1]. Fundamentally, C++ has a number of flaws, of course - that's typical for a pragmatic language - but the key flaw in my opinion is that it's a pain to get higher-level stuff done in until you build the libraries that other language constructs/libraries give you out of the box. [1] For a very small subset of everyone else.
- o2sd 15y ago
  I am currently writing part of a web application in C++, the other part of the web application is being developed by another programmer in Ruby On Rails. In a single request, the RoR part 'does' about a two dozen 'things', which takes it around 2 seconds to complete. The C++ part 'does' around 1.2 million 'things' which takes it between 0.1 to 0.2 seconds to complete. Building the the component that does 1.2 million 'things' is simply impractical in Ruby. Admittedly, very few web applications have this type of requirement, but perhaps in the future many more will. The two dozen or so 'things' the RoR does would take a LOT of code in C++. Well, compared to RoR it would be a lot of code. And the 1.2 million 'things' that the C++ application does would be absurdly difficult to program in Ruby, and as mentioned, would take an absurdly long time to execute. So at the risk of sounding cliché, perhaps it is less a matter of Ruby vs C++, and more one of using the right tool for the job. Once that decision has been made, programmer productivity has more to do with the programmer than the language. I am extremely productive in C++, even though I have to write a lot of code to be productive. If I was a LISP expert, I would be ridiculously productive, but only after 10 years[1] of learning and gaining experience in LISP. Most projects don't have 10 years for you to become productive in the language of choice. [1] Yes, I am exaggerating. It would only take 9 years to become highly productive in LISP.
alttag 15y ago
Heh. I used to work for a company that used C (not C++) for its large web site. They ran the entire site from a monolithic C file. To say again, the code for the entire web site (including product listings, shopping cart, coupons, etc.) was in one .c file. To make things more "interesting," it was, at the time controlled by a single developer who didn't work on site and wouldn't let anyone else touch his code. This barrier was backed up, as I understood, by both tradition and management. The initial decision for C was, I think, the correct one. The site had been around from the early days of the web, and speed was important. However, the architecting and personnel decisions didn't keep up with the company's growth. Another consequence, though, was switching to CSS (which came along later) from, for example, spacer gifs, took a great deal of developer time and testing, as did adding new features. It's the trade-off I think we all understand well today: fast code or fast developers. It was interesting to see the changes while I was there—the site began (slowly) to get recoded in Java, and broken into more manageable chunks at the same time. So far as I know, the whole thing is now in Java.
- alttag 15y ago
  Oh, and to make things even more fun, much of the data passed around between back-end processes and vendor apps was done in XML at the time ... and the XML parsing library they used for C was a bit buggy... No one (w|c)ould fix it, which broke some edge cases. Fun times. Also, if I had to guess, I suspect another factor in the transition was that C programmers were getting more expensive and harder to find.
  - iso8859-1 15y ago
    Using a buggy XML parser has little to do with C...
puls 15y ago
Why must the standard of discourse always be "I'm right and you're wrong?" It seems to me that more often than not in this technological day and age, the situation is much closer to "I'm right and you're also right, and between our two positions there's probably something for both of us to learn."
- mattgreenrocks 15y ago
  Intellectual honesty is not a strong feature of the Internet. I point this out whenever possible, but nobody seems to really care. The medium selects those who are both loudest and have an adequate factual basis. Peppering statements with "In my limited experience," makes you seem meek, unfortunately. Blame the culture of needing traffic and thriving on controversy. It feels like it is a race to the bottom. :(
  - sanderjd 15y ago
    This is not limited to the internet. We learn as children that persuasive writing is weakened by statements such as "I believe", "in my opinion", or "in my limited experience". (I believe that) it is true that such statements weaken writing, and that it should be the reader's job to determine which content is editorial and subconsciously insert the "in my opinion"s where appropriate. Having said all that, it does seem hard to find intellectual honesty on the internet, but I had more trouble finding a decent newspaper in London so it's not an isolated problem.
  - _delirium 15y ago
    I had an interesting discussion about that with some professors as well. It might not be as bad as on the internet, but it does happen, in both research and instruction, to some extent. One prof I know pretty well, who's a good teacher, was lamenting that his students seem to actively want him to be definitive and un-nuanced. His tendency, which he has to work against a bit, is to qualify statements by noting where his views aren't shared by everyone in the field, where he's speculating past the established results, where he's pretty confident of an approach but there are arguments for alternative approaches, etc. But students tend to interpret that as weak and muddled, and prefer profs who "tell it like it is", even if that means in a fairly biased and opinionated way. It seems they particularly like it when you make black-and-white statements that would be controversial, roughly equivalent to "there's a debate on this but you don't need to know about the other viewpoint because it's wrong".
16s 15y ago
I've used C++ with cgi for years too! Glad to see others do it too. Makes for blazing fast web apps and I'm just more comfortable working with it.
sfgfdhgfdshdhhd 15y ago
if your website looks like a unit test, maybe you shouldn't dish out advice on web programming. that's awesome that you know about cgi though
madaraz 15y ago
There is a reason that NO major web application you name is written in C++, Gmail, Facebook, Google Docs, YouTube. There are major advantages to writing web applications in a higher level language and almost no advantages to writing them in C++.
- javadyan 15y ago
  I doubt that the parts of YouTube responsible for video-related heavy-lifting (transcoding, detecting copyright infringement, etc.) are written in a dynamic language like Python, Ruby or PHP or even a managed language like Java.
  - radarsat1 15y ago
    I always imagined that they just patch together a bunch of calls to mplayer and ffmpeg using a bit of shell script.. ;)
    - javadyan 15y ago
      Maybe, but this won't do when you actually have to do algorithmic processing of the video (which I think Youtube does after all).
    - javadyan 15y ago
      and by "algorithmic processing" I mean detecting when the video contains a pirated song, for example.
      - alexchamberlain 15y ago
        I'm sure you could script that out to somone else... :oP
  - hlfcoding 15y ago
    YouTube optimizes their Python with psyco: http://www.slideshare.net/didip/super-sizing-youtube-with-python http://www.slideshare.net/didip/super-sizing-youtube-with-py...
mwd_ 15y ago
Choosing a good language for your project is all about understanding trade-offs and the overall space of languages. It's hard to do this if you only know C++ and view everything else with suspicion. The comment "...back to programming languages, one thing that always bothers me is why new ones keep appearing" sounds like it was written to satirize that sort of perspective.
reactor 15y ago
http://www.treefrogframework.org/ http://www.treefrogframework.org/ might help.
overgard 15y ago
Here's the thing, writing a web app in C is like using a flame thrower to light a candle. Yeah it's possible, but it's dangerous as hell at best and it doesn't really gain you much. And this distrust of other's libraries is odd. You're already running on an OS that's providing millions of lines of code to you in the form of api's and services, and using a compiler that's going to do all sorts of modifications to what you've created at the machine code level. You're already well into trusting a lot code that's not yours. But something that's a million times easier (parsing HTTP headers), and now they're worried about other peoples code? Seriously?
- joe_the_user 15y ago
  Being in the process of writing a c++ web client, I am strongly inclined to agree with your assessment of c and web apps. The one thing is, if someone does write c web apps - having your own set of libraries can be useful exactly then. The web has all these crazy encodings and protocols and knowing exactly which way your library does them is really useful when you use a language with no safety net or safety switch or anything. Spent the afternoon figuring out, sort-of, the url encoding of reddit's "api" and how it interact with Qt's QURL class.
- udp 15y ago
  > using a compiler that's going to do all sorts of modifications to what you've created at the machine code level You do know that the compiler isn't allowed to change the behaviour of your code, right? (If it did, it would be a bug in the compiler, and C compilers are pretty damn mature.)
lrobb 15y ago
The reaction to this piece is interesting... I was sort of "ho-hum" about it, but I've written many a "web-app" in c/c++ - cgic on linux, isapi on windows... not to mention socket servers with thread pools implementing custom protocols... I don't say that because I think it makes me special -- it's what we ALL used to do because that's the only thing we had. After you've done that for a few years, you become VERY efficient at banging out code.
ComputerGuru 15y ago
Does anyone know a real (not proof of concept) FastCGI C++ library/framework?
- sciurus 15y ago
  http://news.ycombinator.com/item?id=3449294 http://news.ycombinator.com/item?id=3449294
- obtu 15y ago
  Wt (I haven't used it): http://www.webtoolkit.eu/ http://www.webtoolkit.eu/
jQueryIsAwesome 15y ago
Some of her points are vague and unclear: > that somehow you would need to abdicate almost all of your code to modules where you just hope they work Well, you are using jQuery, jQuery UI, jQuery Player and jQuery Scroll-into-view in your example project, that is actually a big pile of modules if you ask me.
jterenzio 15y ago
> At some point, you just have to shut up and make stuff. Amen.
scscsc 15y ago
I find it ironic that the author says that you should just shut up and make stuff without taking his own advice (the part about making stuff will probably follow soon). Having written a C(++) web-app (using CGI), I'm ok with writing in C++ (it's not that bad), but the advantages of using a language more suited for web development are not negligible. The author would probably find this out the hard way (if/when (s)he gets to making stuff).
- obtu 15y ago
  Here's the followup: http://rachelbythebay.com/w/2012/01/10/cpp/ http://rachelbythebay.com/w/2012/01/10/cpp/ It's a round-up of her recent blog posts about super trunking scanner, which scans airwaves and displays the info it gleans to a web ui.
racER 15y ago
Well, I can't see any specific advantage on using C/C++ as backend of a plain old CGI API. Personally I'd use PHP or something like that, which integrates tighter with the web server. Using C on CGI is propably not very much faster compared to an optimized PHP environment with precompiled (cached) p-code. > "C programs are suspectible to memory corruption." (tptacek) Yes, they are, because in C you can do memory corruption, in many other languages you can't (even if you'd want to). But where do these corruptions most likely occur, when speaking in context of web applications? Yes, in I/O and string operations. And all these can be mitigated with somehow "safe" classes - by these I mean not a home-brew string-class, but something like STL (which has proven stability). However, is memory corruption the only security risk? In my opinion, an average C/C++ programmer creates more secure code than an average PHP programmer - just because a C programmer is used to the intrinsic security issues, while the PHP coder won't produce an buffer overflow by not validating input, but leaves eg. XSS or SQL injection holes. Writing a web application in C without preparing for safe I/O & string operations is as bad as writing dirty script code in PHP/Perl/Ruby/... At my company we've written a really big web application (a hosting control panel) completely in C/C++, but for other reasons than execution speed: the runtime dependencies of a sellable web application are pure horror. Neverending CPAN-depencencies in Perl, incompatible function changes in PHP, and so on. With a monolithic app (web server & application logic all-in-one) you just need a libc - that's all. Easy to roll out, and thus easy to sell. :)
albertsun 15y ago
OkCupid is written in C++ http://www.okcupid.com/about/technology http://www.okcupid.com/about/technology

118 points by sciurus 15y ago

This plus something for disk persistence is totally sufficient for writing web apps in C++: http://cgi.sourceforge.net/ http://cgi.sourceforge.net/

akkartik 15y ago
Disk persistence was actually the question I came to this thread with after reading the article.

krf 15y ago

qDecoder by Seungyoung Kim (www.qdecoder.org) is a terrific open source library for using CGI with C and C++. A lot of us did what this article mentioned - but probably in the 1990s when desktop programmers were moving to the web. Most probably settled on Perl after trying C and finding development was much faster with Perl.

_delirium 15y ago

I agree they're not a big deal per se, but I do find them clunkier. Facebook seems to agree, and argued that it was worth expending the considerable engineering effort it took to write a whole new PHP runtime, just to avoid the obvious alternative, writing more of Facebook in C++. Though Google does write a lot of its backend stuff in C++ successfully, so culture and what kind of web software you're writing may be part of it.

alexchamberlain 15y ago
No, Facebook had LOADS of PHP code thst sas failing terribly. It was easier to write a PHP compiler that a rewrite in C++.However, now they have control of the compiler, they can probably slowly replace the PHP with C++.

gaius 15y ago

Ah, you kids! Back in the '90s, we thought nothing of building websites in NSAPI.

hackermom 15y ago

For those who never dealt with the server end of the web in the mid-to-late 90s I can tell you that native executables for CGI was at that time not the least rare or uncommon.

biasedstudy 15y ago
Having a lightweight, standalone executable with quick start up time is still a major win.
- cageface 15y ago
  What about caching database connections? Opening a new connection on every request can be very slow, particularly for Oracle.
  - javadyan 15y ago
    One may consider using FastCGI to avoid the costs associated with starting a new process with each request.

akkartik 15y ago

Perl and python and ruby aren't just easier because they have more libraries. They're easier because they have hash literals, a more flexible module system, etc. (ahem, implicit/dynamic type checking) I agree that the reliance of rails apps on gems is unfortunate. They're rediscovering DLL hell for themselves. But the original DLL hell was all C++ apps. You can shoot yourself in the foot with over-reliance on libraries in any language.

NathanWong 15y ago
It's not clear that this comment is addressing any real issues. Firstly, std::unordered_map is officially part of C++ now, and it's been available in all major compilers for a long time. Secondly, there's no substantial evidence provided to support the claim that the module system in a dynamic language is "more flexible" - anytime you want to include someone else's code in your source tree in any language you can just drop the source in as though it was your own. Whether there's a "package manager" to hide the references for you is beside the point; it's not as if the concept of shared libraries is lost upon C and C++. And "ahem" does not establish a valid argument as to why dynamic type checking is "easier" (whatever that even means). In fact, I believe a strong argument could be made that dynamic type checking is the worst aspect of dynamic languages, and the interest that Haskell has been brewing up lately would tend to support this. Static type checking brings bugs to the forefront when the developer is in the room instead of the user. One could argue that runtime reflection provides more flexibility and thus makes dynamic languages "easier", but it's a stretch to extend that to dynamic typing. I'm unsure of how DLL Hell would even apply to a SaaS application, unless we're referring to completely different things; you have complete control of your application's environment in a web app. If there's a package already installed that you don't want or something is missing, you remove it or install it. With the prevalence of virtualization and virtualization-as-a-service, there's no reason to be trying to run two different applications that require different dependencies on the same virtual box.
- akkartik 15y ago
  It sounds like you're claiming C++ is as convenient as a 'HLL'. If so, I think the divide is too great for us to talk across. I've worked in C++ for ten years, but I think scripts in perl or python are more convenient for many tasks. I haven't met anybody who disagreed about something so basic, so I'm not sure how to respond. I use unordered_map all the time, but I wouldn't claim it's the same as support for literal hash-tables in the language. Implicit typing is useful if I am happy to allow my tasks to die at runtime because I screwed up. After all, C++ apps often segfault when I screw up.

boneheadmed 15y ago

I have to say that I like the perspective. I think that a good programmer should be able to use virtually any good language to create anything. In particular, it seems worthwhile, if for example one is well versed in say Ruby, to learn C to get at the root of what is occurring "under the hood". I really enjoy Ruby, but I'm learning C to fully immerse myself in what is occurring with the bits and bytes (or at least the bytes).

drivebyacct2 15y ago

Why C++? Go (golang.org) is too much fun!

drivebyacct2 15y ago
I wish I could edit this comment, I think more explanation would have helped. Go is low level (originally marketed as a systems-level language), but it really is truly fun to use and it has whole swath of really comprehensive libraries for throwing together web apps very quickly. (SPDY, WebSockets, and much more, but I appreciate those features out of the box)

tptacek 15y ago

Writing C++ code that works reliably in a benign setting is not a big deal. With the right libraries, it is almost as easy and perhaps only a little slower than writing in a high-level language; you can't, for instance, really believe that everyone who writes a popular iOS application is a solid bare-metal C programmer. But writing reliable C++ code that works under adversarial conditions is very hard; hard enough that the best C programmers in the world have track records like "only one theoretically-exploitable memory corruption vulnerability in the release history", and quite a few people who set out with "no vulnerabilities" in their project charter end up with way worse records. I've found over the last couple years that one way to get C/C++ code fit into a web application is via "nosql" databases, particularly Redis; let something like Ruby/Rack or Python/WSGI or Java Servlets soak up the hostile HTTP traffic, and use it to drive an async API over Redis. The less C/C++/ObjC code you have talking to an adversary, the better off you are. I'm a C/C++ programmer; C is my first language, from when I was a teenager. I respect C programmers. But if I was interviewing a developer and they told me their gut was to write a C program to do something a Rails program would normally do, and it wasn't an exceptionally specific circumstance, I would think less of them.

bri3d 15y ago
In this worldview, wouldn't the C programmers writing your language runtime have the same poor track record when it comes to security? And wouldn't the runtime itself be a substantially higher-value target for attackers? I, too, would look at someone strangely if they told me they were going to write a C application where I'd use a Rails one, but security certainly wouldn't be the first reason on my mind. As a postscript, I really like the idea of putting C/C++ apps behind a message bus, as decoupled from the web end as possible. I've had great luck using C++ for performance-critical services behind a Rails frontend talking to Redis (I've also used AMQP via RabbitMQ, but I found that to have a high enterprise brokered pain to value ratio).
- tptacek 15y ago
  They do have a poor track record with the language runtime. You should be concerned about the quality of your language runtime. MRI, for instance, has had many memory corruption flaws that were plausibly exposed to hostile input. When security is a priority, I advise using JRuby (it helps that JRuby is better than MRI anyways). But either way: language runtimes for mainstream languages are high-priority targets. Your C code is not. You will not learn the worst problems in your C code until long after it's been deployed.

alexchamberlain 15y ago

THANK YOU! I totally agree that it is not unreasonable to write websites in C/C++. I've just started looking into writing Nginx modules, which are generally written in C. Now that I've started to understand it, I can write secure content handlers in a reasonable time and reasonable effort, whilst being able to use the exhaustive libraries on offer, as well as my experience with the language. Couple this with great performance, and I can't justify writing apps in PHP anymore. We're moving more and more processing to the client , as we have realised that networks are pretty slow. Well then, how do you justify writing slow code behind the slow network? I highly encourage the author to look at writing Nginx modules, possibly not on a hackathon, since you get security and fantastic performance for free!

petercooper 15y ago

[..] I haven't had a reason to touch them. The few times I've seen or heard about them, it's all been linked to frothy people clamoring for the latest shiny thing. Avoiding a technology by applying a frivolous standard like this is a good way to miss out on useful learning experiences. "Doing" is great, but stretching your boundaries and trying new things outside of your comfort zone is an essential part of being a well rounded programmer.

rachelbythebay 15y ago
Ah, you grabbed onto the second sentence while dismissing the first. I avoid them because I haven't had a reason to bother. The task could be accomplished some other way, and was. I've used plenty of things used by "foamers" out of necessity. I don't enjoy it, but it does get the job done.
- petercooper 15y ago
  I've used plenty of things used by "foamers" out of necessity. I don't enjoy it, but it does get the job done. An unpleasant subset of a technology's userbase has no relationship to the usefulness or learning experiences relating to the technology and is of no relevance to the well-rounded, life-long learner. Being distracted by the who in technical pursuits is a burdensome impediment against learning the valuable whats and whys.
  - rachelbythebay 15y ago
    You have to work with the 'who' to actually get anywhere with some of this stuff. And some of these communities are less than friendly. Some of them are outright hostile. Does that help?
    - kragen 15y ago
      Also, the other users of Ruby are the ones who wrote the libraries you get to use in a Ruby program. Which is pretty relevant to the person in a nearby thread who implicitly equates using the Linux virtual memory system to using Rubyful Soup.

jacques_chester 15y ago

The big reason for avoid C++ is to avoid bugs and security issues. In particular, overflow attacks. That the language requires constant, conscious diligence to achieve a security baseline that comes for free in other languages is wasteful. Then there's the library/tools situation. I did all the work for my honours dissertation in Ruby in part because the Ruby ecosystem is vast and vibrant (sometimes inconveniently so). I imagine that the C++-for-the-web ecosystem is going to be a bit more spartan.

VikingCoder 15y ago
> That the language requires constant, conscious diligence to achieve a security baseline that comes for free in other languages is wasteful. For extremely expensive values of "free."
- jacques_chester 15y ago
  Could you elaborate?
  - VikingCoder 15y ago
    No language exists yet that is aware of all security issues. No matter what language, library, framework, toolset you use, you need to be aware of multiple vectors of attack. Claiming that some languages solve these problems for you, for free, is disingenuous.
    - jacques_chester 15y ago
      That's not what I claimed. I pointed out that languages with safe string handling and memory management have a higher security baseline. As in, what you start with, for "free". Achieving comparable string and memory security in C/C++ is an expense. You must take active steps to prevent those exploits; and even then human error means that you will have a higher risk than the "free baseline" languages.

pshc 15y ago

* Dismissing newer technologies as "shiny" instead of evaluating their merits * Language hipsterism * Being disturbed by modular code * Dismissing high-level code that might have leaky abstractions * Plain CGI * Being turned off by callbacks and reinventing the wheel instead * The usual silliness about all tools being capable and therefore equal (they're all Turing complete, yes, but we still want to know which ones are more productive for some use case.) This is grumpy posturing and C++ is now blub. Am I being trolled?

Rusky 15y ago
Dismissing newer technologies as "shiny" instead of evaluating their merits I would think it's more about trying not to dismiss older technologies just because of the merits of something newer. Being disturbed by modular code The C++ code described in the article sounded pretty modular to me...
baddox 15y ago
I think the point about reliance on and obsession with modular code is a valid one, even though it's so entrenched in programming culture now. Donald Knuthe makes a similar (much less inflammatory) argument here (Ctrl-F "black box"): http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856
uiri 15y ago
Just wondering, what exactly is wrong with plain CGI?
- javadyan 15y ago
  I assume he's implying that CGI is slow.
- iso8859-1 15y ago
  With CGI, you do your own data persistence. It leads to gigantic blobs. Also, you spawn a process for each request. http://stackoverflow.com/questions/424839/what-were-the-main-disadvantages-of-cgi-bin-based-web-development http://stackoverflow.com/questions/424839/what-were-the-main... As I see it, it's the old low-level vs high-level discussion all over again. I'm sure you have seen it before. Low-level programmers argue that they have control and know how everything is working. High-level programmers argue security, problem isolation, modularity (i.e. not only using your own code!), readability, maintainability.

pnathan 15y ago

I left C++ a few years ago. It's not that it's a "bad" language, for a certain value of bad. It's just bloody inefficient to get things done in! Coding in it requires girnormous amounts of text shovelling, typing attempts to be strict, template meta-programming requires hand-coding type inference schemes, and on top of that, the library/package management is a nightmare. Well, I didn't think these harsh things when I 'left' C++, but as I worked with more high-level languages, I realized that I was doing more, with less code and dynamic duck-y typing, and with nice libraries only a `cpan` away. So when I hacked together a C++ program a year or so ago, I got punched in the face by all these issues. It was a pain. So I said, okay, this is stupid. I need to use C for low-level work like drivers, and use Common Lisp for other things. Like what everyone else does[1]. Fundamentally, C++ has a number of flaws, of course - that's typical for a pragmatic language - but the key flaw in my opinion is that it's a pain to get higher-level stuff done in until you build the libraries that other language constructs/libraries give you out of the box. [1] For a very small subset of everyone else.

o2sd 15y ago
I am currently writing part of a web application in C++, the other part of the web application is being developed by another programmer in Ruby On Rails. In a single request, the RoR part 'does' about a two dozen 'things', which takes it around 2 seconds to complete. The C++ part 'does' around 1.2 million 'things' which takes it between 0.1 to 0.2 seconds to complete. Building the the component that does 1.2 million 'things' is simply impractical in Ruby. Admittedly, very few web applications have this type of requirement, but perhaps in the future many more will. The two dozen or so 'things' the RoR does would take a LOT of code in C++. Well, compared to RoR it would be a lot of code. And the 1.2 million 'things' that the C++ application does would be absurdly difficult to program in Ruby, and as mentioned, would take an absurdly long time to execute. So at the risk of sounding cliché, perhaps it is less a matter of Ruby vs C++, and more one of using the right tool for the job. Once that decision has been made, programmer productivity has more to do with the programmer than the language. I am extremely productive in C++, even though I have to write a lot of code to be productive. If I was a LISP expert, I would be ridiculously productive, but only after 10 years[1] of learning and gaining experience in LISP. Most projects don't have 10 years for you to become productive in the language of choice. [1] Yes, I am exaggerating. It would only take 9 years to become highly productive in LISP.

alttag 15y ago

Heh. I used to work for a company that used C (not C++) for its large web site. They ran the entire site from a monolithic C file. To say again, the code for the entire web site (including product listings, shopping cart, coupons, etc.) was in one .c file. To make things more "interesting," it was, at the time controlled by a single developer who didn't work on site and wouldn't let anyone else touch his code. This barrier was backed up, as I understood, by both tradition and management. The initial decision for C was, I think, the correct one. The site had been around from the early days of the web, and speed was important. However, the architecting and personnel decisions didn't keep up with the company's growth. Another consequence, though, was switching to CSS (which came along later) from, for example, spacer gifs, took a great deal of developer time and testing, as did adding new features. It's the trade-off I think we all understand well today: fast code or fast developers. It was interesting to see the changes while I was there—the site began (slowly) to get recoded in Java, and broken into more manageable chunks at the same time. So far as I know, the whole thing is now in Java.

alttag 15y ago
Oh, and to make things even more fun, much of the data passed around between back-end processes and vendor apps was done in XML at the time ... and the XML parsing library they used for C was a bit buggy... No one (w|c)ould fix it, which broke some edge cases. Fun times. Also, if I had to guess, I suspect another factor in the transition was that C programmers were getting more expensive and harder to find.
- iso8859-1 15y ago
  Using a buggy XML parser has little to do with C...

puls 15y ago

Why must the standard of discourse always be "I'm right and you're wrong?" It seems to me that more often than not in this technological day and age, the situation is much closer to "I'm right and you're also right, and between our two positions there's probably something for both of us to learn."

mattgreenrocks 15y ago
Intellectual honesty is not a strong feature of the Internet. I point this out whenever possible, but nobody seems to really care. The medium selects those who are both loudest and have an adequate factual basis. Peppering statements with "In my limited experience," makes you seem meek, unfortunately. Blame the culture of needing traffic and thriving on controversy. It feels like it is a race to the bottom. :(
- sanderjd 15y ago
  This is not limited to the internet. We learn as children that persuasive writing is weakened by statements such as "I believe", "in my opinion", or "in my limited experience". (I believe that) it is true that such statements weaken writing, and that it should be the reader's job to determine which content is editorial and subconsciously insert the "in my opinion"s where appropriate. Having said all that, it does seem hard to find intellectual honesty on the internet, but I had more trouble finding a decent newspaper in London so it's not an isolated problem.
- _delirium 15y ago
  I had an interesting discussion about that with some professors as well. It might not be as bad as on the internet, but it does happen, in both research and instruction, to some extent. One prof I know pretty well, who's a good teacher, was lamenting that his students seem to actively want him to be definitive and un-nuanced. His tendency, which he has to work against a bit, is to qualify statements by noting where his views aren't shared by everyone in the field, where he's speculating past the established results, where he's pretty confident of an approach but there are arguments for alternative approaches, etc. But students tend to interpret that as weak and muddled, and prefer profs who "tell it like it is", even if that means in a fairly biased and opinionated way. It seems they particularly like it when you make black-and-white statements that would be controversial, roughly equivalent to "there's a debate on this but you don't need to know about the other viewpoint because it's wrong".

16s 15y ago

I've used C++ with cgi for years too! Glad to see others do it too. Makes for blazing fast web apps and I'm just more comfortable working with it.

sfgfdhgfdshdhhd 15y ago

if your website looks like a unit test, maybe you shouldn't dish out advice on web programming. that's awesome that you know about cgi though

madaraz 15y ago

There is a reason that NO major web application you name is written in C++, Gmail, Facebook, Google Docs, YouTube. There are major advantages to writing web applications in a higher level language and almost no advantages to writing them in C++.

javadyan 15y ago
I doubt that the parts of YouTube responsible for video-related heavy-lifting (transcoding, detecting copyright infringement, etc.) are written in a dynamic language like Python, Ruby or PHP or even a managed language like Java.
- radarsat1 15y ago
  I always imagined that they just patch together a bunch of calls to mplayer and ffmpeg using a bit of shell script.. ;)
  - javadyan 15y ago
    Maybe, but this won't do when you actually have to do algorithmic processing of the video (which I think Youtube does after all).
  - javadyan 15y ago
    and by "algorithmic processing" I mean detecting when the video contains a pirated song, for example.
    - alexchamberlain 15y ago
      I'm sure you could script that out to somone else... :oP
- hlfcoding 15y ago
  YouTube optimizes their Python with psyco: http://www.slideshare.net/didip/super-sizing-youtube-with-python http://www.slideshare.net/didip/super-sizing-youtube-with-py...

mwd_ 15y ago

Choosing a good language for your project is all about understanding trade-offs and the overall space of languages. It's hard to do this if you only know C++ and view everything else with suspicion. The comment "...back to programming languages, one thing that always bothers me is why new ones keep appearing" sounds like it was written to satirize that sort of perspective.

reactor 15y ago

http://www.treefrogframework.org/ http://www.treefrogframework.org/ might help.

overgard 15y ago

Here's the thing, writing a web app in C is like using a flame thrower to light a candle. Yeah it's possible, but it's dangerous as hell at best and it doesn't really gain you much. And this distrust of other's libraries is odd. You're already running on an OS that's providing millions of lines of code to you in the form of api's and services, and using a compiler that's going to do all sorts of modifications to what you've created at the machine code level. You're already well into trusting a lot code that's not yours. But something that's a million times easier (parsing HTTP headers), and now they're worried about other peoples code? Seriously?

joe_the_user 15y ago
Being in the process of writing a c++ web client, I am strongly inclined to agree with your assessment of c and web apps. The one thing is, if someone does write c web apps - having your own set of libraries can be useful exactly then. The web has all these crazy encodings and protocols and knowing exactly which way your library does them is really useful when you use a language with no safety net or safety switch or anything. Spent the afternoon figuring out, sort-of, the url encoding of reddit's "api" and how it interact with Qt's QURL class.
udp 15y ago
> using a compiler that's going to do all sorts of modifications to what you've created at the machine code level You do know that the compiler isn't allowed to change the behaviour of your code, right? (If it did, it would be a bug in the compiler, and C compilers are pretty damn mature.)

lrobb 15y ago

The reaction to this piece is interesting... I was sort of "ho-hum" about it, but I've written many a "web-app" in c/c++ - cgic on linux, isapi on windows... not to mention socket servers with thread pools implementing custom protocols... I don't say that because I think it makes me special -- it's what we ALL used to do because that's the only thing we had. After you've done that for a few years, you become VERY efficient at banging out code.

ComputerGuru 15y ago

Does anyone know a real (not proof of concept) FastCGI C++ library/framework?

sciurus 15y ago
http://news.ycombinator.com/item?id=3449294 http://news.ycombinator.com/item?id=3449294
obtu 15y ago
Wt (I haven't used it): http://www.webtoolkit.eu/ http://www.webtoolkit.eu/

jQueryIsAwesome 15y ago

Some of her points are vague and unclear: > that somehow you would need to abdicate almost all of your code to modules where you just hope they work Well, you are using jQuery, jQuery UI, jQuery Player and jQuery Scroll-into-view in your example project, that is actually a big pile of modules if you ask me.

jterenzio 15y ago

> At some point, you just have to shut up and make stuff. Amen.

scscsc 15y ago

I find it ironic that the author says that you should just shut up and make stuff without taking his own advice (the part about making stuff will probably follow soon). Having written a C(++) web-app (using CGI), I'm ok with writing in C++ (it's not that bad), but the advantages of using a language more suited for web development are not negligible. The author would probably find this out the hard way (if/when (s)he gets to making stuff).

obtu 15y ago
Here's the followup: http://rachelbythebay.com/w/2012/01/10/cpp/ http://rachelbythebay.com/w/2012/01/10/cpp/ It's a round-up of her recent blog posts about super trunking scanner, which scans airwaves and displays the info it gleans to a web ui.

racER 15y ago

Well, I can't see any specific advantage on using C/C++ as backend of a plain old CGI API. Personally I'd use PHP or something like that, which integrates tighter with the web server. Using C on CGI is propably not very much faster compared to an optimized PHP environment with precompiled (cached) p-code. > "C programs are suspectible to memory corruption." (tptacek) Yes, they are, because in C you can do memory corruption, in many other languages you can't (even if you'd want to). But where do these corruptions most likely occur, when speaking in context of web applications? Yes, in I/O and string operations. And all these can be mitigated with somehow "safe" classes - by these I mean not a home-brew string-class, but something like STL (which has proven stability). However, is memory corruption the only security risk? In my opinion, an average C/C++ programmer creates more secure code than an average PHP programmer - just because a C programmer is used to the intrinsic security issues, while the PHP coder won't produce an buffer overflow by not validating input, but leaves eg. XSS or SQL injection holes. Writing a web application in C without preparing for safe I/O & string operations is as bad as writing dirty script code in PHP/Perl/Ruby/... At my company we've written a really big web application (a hosting control panel) completely in C/C++, but for other reasons than execution speed: the runtime dependencies of a sellable web application are pure horror. Neverending CPAN-depencencies in Perl, incompatible function changes in PHP, and so on. With a monolithic app (web server & application logic all-in-one) you just need a libc - that's all. Easy to roll out, and thus easy to sell. :)

albertsun 15y ago

OkCupid is written in C++ http://www.okcupid.com/about/technology http://www.okcupid.com/about/technology