CppCMS – High Performance C++ Web Framework | Hacker News Reader

CppCMS – High Performance C++ Web Framework

cppcms.com

120 pointsviana007128 comments

Some of the negative comments here really anger me, and I feel a need to speak up.

Who gives a flying fuck if this tool is the right one for whatever is your individual definition of web development? The fact is that someone had a need for a particular solution and they were kind enough to build it, document it, and show it off here for free. Turning your nose up at this based on language choice just makes you a close-minded fool.

Applications for this do in fact exist, and I'm quite pleased that the author was kind enough to post this.

On a past project I've had to write my own asynchronous web framework in C based on the wonderful libmicrohttpd. I decided on C because this was a resource limited device on which I was already using every available CPU cycle on a realtime computer vision algorithm and it all was just barely performing within acceptable limits. I needed as tiny a footprint as I could get.

I'm in the early stages of a different project which will probably face a similar situation, except on this massive concurrency will be key. I will absolutely be looking into CppCMS when the time comes.

You know, every time I see one of these types of frameworks the first thing that comes to mind is "Some people are just determined to make C++ look cool again". I mean sure, sometimes you run into a case where you are running computer vision algorithms on an embedded device and have to choose C or C++.

But how common are those use-cases really? And why on earth would you want to worry about buffer overflows and memory leaks when you're already worrying about XSS and CSRF attacks?

As fast as modern Java is, it just seems unnecessary.

> And why on earth would you want to worry about buffer overflows and memory leaks

Have you written a line of code in modern C++? Know what RAII is? If you use C arrays and char*s in C++, that's your problem - the language provides idioms that are "as safe as" Java.

This. I can count the occasions where I used new/delete (and worried about lifetime of objects) in the last year on one hand. And I'm a full time C++ developer.

RAII doesn't save you from buffer overflows, or memory leaks when you need an object to live beyond the current scope.

C arrays and pointers can still be used on the stack, and are sometimes simply the right tool for the job.

While RAII greatly reduces memory leaks and enhances resource-management, it doesn't save you in all cases, which means there still is an overhead and you will still have to worry about it.

RAII doesn't save you from buffer overflows, or memory leaks when you need an object to live beyond the current scope.

C arrays and pointers can still be used on the stack, and are sometimes simply the right tool for the job.

While RAII greatly reduces memory leaks and enhances resource-management, it doesn't save you in all cases, which means there still is an overhead and you will still have to worry about it.

Java doesn't have Undefined Behaviour, buffer overflows, or memory leaks (not completely true, I'm not counting space leaks here but I hear it's possible to introduce a memory leak by writing a faulty class loader).

While C++ does provide idioms for writing safe code, C++ can't remove them, which means you will always have to worry about it. Sometimes the problem isn't actually your code, but the library you're using, which is the case at my job, which again made me miss a safer language :(

> RAII doesn't save you from buffer overflows

How do other languages solve this problem?

> or memory leaks when you need an object to live beyond the current scope.

Have you ever heard about smart pointers? They take most pain from dealing with pointers. Managing circular references remains a bit complex though.

> How do other languages solve this problem?

Reading or writing past the allocated parts of a buffer is treated as a runtime error, wheras in C/C++ you just end up with corrupted memory.

> Have you ever heard about smart pointers?

Ahh, completely forgot about these. You're right, they're great.

> If you use C arrays and char*s in C++, that's your problem

Sadly it's not that cut and dried. I've written a mail-client in C++, with an embedded Lua intepreter for the scripting. Guess what the Lua API wants to use?

There are many many situations where you need to integrate with libraries that only present C-bindings, and that gives you a lot of constraints.

(Though I admit I was pleased with the C++ API of libmimetic, the MIME-library.)

I agree there are rough edges, and for specialized use cases like yours, you might have to walk that extra mile. But when I hear that a framework/library/tool is worth nothing just because it is written in C++ and not in the hip Ruby/Python/Go, it makes me sick. This guy wrote CppCMS taking inspiration from modern frameworks hoping to make life better for himself and for people who care to write webservices/apps in idiomatic C++ and NOT C. Imagine if someone had written a had a well designed, idiomatic C++/Lua API(like, say, boost::python) and open sourced it, would we not have commended their efforts?

Nope. Nor do I plan on it. Why should I use a language that forces me to know about RAII and the difference between C pointers and "language provided idioms" to begin with? Tell you what: I'll buy your "modern C++ is safe" argument if you buy my "modern Java is fast" argument.

> Why should I use a language that forces me to know about RAII and the difference between C pointers and "language provided idioms" to begin with?

No one asked you to. I don't like Eclipse that much personally, but I did not go to their page and say "Hey, you know what, I hate Java so your product sucks!". (I have deep respect for Java and the Java community, BTW). But frankly, as someone who has not written a line of code in C++ - however bad it may be - you're not really qualified enough to preach the world about its utility.

> I'll buy your "modern C++ is safe" argument if you buy my "modern Java is fast" argument.

Yes, the JVM is an engineering marvel - we all know that! What we also know is that it is adept at hogging all resources you might have(unless you learn how to use those bazillion -X<options>) - so no, thanks. I prefer compiling to native code and having total control, and in cases I don't want all that, I might just stick to Go or Python.

C++ is never going to be hip, but as an HTML5 game developer I can't tell you how many times I have wished for the ability to stack allocate objects, or to use RAII.

C++ gives you plenty of ways to go harm yourself, but unlike C they are pretty easy to work around. And the nice thing is that for the most part wrong code looks wrong.

Gah! Enough with the "use-cases" already! They're "uses" or "cases". Why the redundancy? What next, "profit-money"? "Price-point"? Oh wait...

I couldn't agree more. Disclaimer, I work mostly in embedded systems. But, still. There's something to be said about being too quick to judge based on the language or tool used to accomplish the job. Every tool has its use and my guess is that plenty of people will use this.

Why on earth would you use C++ for a massively concurrent app? While I understand using C/C++ for low-memory devices or where deterministic/manual memory handling is important. Concurrency/Paralellism is simply not C/C++, Java's, or any language which relies primarily on locks, cup of tea.

If possible, try to make Go work. It's concurrency model is great for massive concurrency.

C++ doesn't rely on locks. You can use whatever you want.

Hmm. Most of what I've seen uses mutexes and semaphores for synchronization. Do you have actors and/or channels libraries for C++? I recon you do, but how good are they?

I don't know much about the public actors or channels libraries for C++, since I work on a project that rolled its own green threads system and doesn't have much of a use for channels -- we end up having types that perform fifo enforcement in other ways, and our way of "sending a message" is often popping a green thread that switches itself to the appropriate POSIX thread before doing something, using some sort of fifo enforcement object to rearrange things in the right order at the right time (and then holding a short term userland single-threaded lock -- with no cross-posix-thread synchronization -- to do some atomic business once you get your turn).

You could create a channel library that is "as good as" other libraries you'd see, except that they'd use C++ constructors/destructors and you might want a family of channel types depending on ownership semantics -- such as a single-producer single-consumer channel, versus a (less performant) channel with more shared ownership.

The state of existing actors or channels libraries is probably dismal. A channels library would need to be rolled together with a specific green threads system, and that's one of the advantages Go or other languages with a canonical green threads implementation has.

This isn't an "app." It's one service that's a small but important piece of a rather large backend. It's essentially a content-aware WebSockets proxy. I want it to be extremely light weight with minimal latency addition (less than 1 msec, ideally).

So why C/C++? When it comes to language choice I have a very simple rule: use whatever I think I can be most successful with.

Go prescribes a particular concurrency model. C and C++ do not. I have many years of experience wielding C to write very small, very fast programs that do very big things. I have zero years of experience with Go. Go would be interesting if I was writing something more general purpose or something that needed lots of extensibility, or something on which I plan to collaborate with people who don't have a lot of concurrent programming experience. None of those cases apply.

app, application, I wasn't thinking about mobile apps or the like.

I agree completely with using whatever I can be most successful with line of thinking. This is why I try to learn as many languages as I can, so I have a good notion of what is the best tool for the job.

Whenever I think "loads of concurrency" I immidietly think about Erlang, Clojure or Go, as they have great concurrency models. Then again, you'll always be more productive in the language in which you have most experience, so to each his own I guess :)

"I'm in the early stages of a different project which will probably face a similar situation, except on this massive concurrency will be key..."

I'm a fan of native code, and I use C++ at work and C and C++ on my personal projects. In my last job I was doing web work, writing PHP for Drupal sites. My reaction to CppCMS is just to note that it wouldn't necessarily be easy to create a faster CMS using C++ versus PHP. Drupal sites can be slow as dogs, but the reason has nothing to do with PHP per se. The Drupal codebase is extremely bloated and fairly inefficient in its design, but even worse are the modules that get piled on, and there can easily be well over 100 modules on a site. I've watched the database queries that come out from a real site and it was stunning and appalling to see the volume and the redundancy that occurs on a single page. I was also amazed by the sheer quantity of PHP that gets loaded and parsed (if you're not caching) on a single page. So that tells me that PHP is pretty fast to be able to support that enormous edifice of code. It's not a guarantee that C++ would make you faster than an interpreted language, because the work that goes into generating a webpage plays to the strengths of interpreted languages and away from C++: you'd have to be careful and think through how to handle lots of strings and memory management. A good garbage collector is said to be faster than malloc/new when churning through lots of memory, because it can amortize the work and run on a background thread. I think lots of little strings could especially become a problem unless you planned out a strategy for handling them efficiently. Also, as others have pointed out, a lot of the issues with making a website fast aren't about executing code on the cpu. It wouldn't necessarily be easy to beat something like node.js at handling requests asynchronously, for instance. That stuff can be hard to write. So, I think it would be a good idea to do even a very high performance site in an interpreted web language first, then decide cautiously if there's a way to make it faster by replacing some or all of it with hand-written C++.

Disclaimer: I used to write Web apps in C++ in late 90s/early 00s for the largest web company of the time.

1) DB is often a bottleneck for web apps. Not always. But often. Very often. Optimizing pages rendering will improve the performance for pages that are already rendered pretty fast. It will do nothing for pages that are loaded slow due to DB access. A better/smarter cache will give you much bigger bang for the buck.

2) For the annual salary of a good C++ programmer (i.e. one who can write safe and readable code with STL and Boost), I can run 50 large AWS instances for a year.

3) Writing safe C++ code is hard. Even with STL and Boost you still have to understand the little details of objects ownership (see boost::shared_from_this<> as an example).

Overall, I would invest in distributed system with smart and efficient caching instead of trying to optimize single server performance. At the end, you will run out of the single box solution (if you are successful). Going from 1 server to 2 servers is really hard. Going from 10 to 100 is not too bad.

Disclaimer: I’m not a C++ guy; I generally write in Ruby and PHP.

I agree with your overall point — C++ may not be a good fit for web development, and there’s a lot to be said for being able to scale across multiple servers (and choice of platform will determine how quickly you have to solve that problem).

That said, my experience is that for most projects the performance bottleneck is the framework, not the DB. On big PHP projects, loading lots of code on every page load takes a huge amount of time, and many frameworks do things like parse multiple XML files on every request.

Similarly, Rails is slow… just take a look at how much time is spent outside of the database for a typical request. It’s crazy how long it takes, considering that most requests boil down to a DB query and then some string concatenation.

Another angle on his is the common pattern of having a bunch of app servers and just a few DB servers. That implies that the DB is not the main bottleneck.

Again, I agree with your overall thesis, I just have to disagree with the common wisdom that is point 1.

In my statement I kind of assumed that all the "cheap" optimizations in the framework are already done (e.g. PHP APC cache is enabled, lazy classes/configs loading is implemented, etc.) so we compare "apples-to-apples": a highly optimized C++ framework to a highly optimized, say, PHP framework (can't comment about Ruby - didn't have experience building/running large-scale apps on it). And of course, it all depends on the application itself. Fetching single "narrow" rows by primary key is obviously cheap and nobody cares. However, you have to dig through a table larger than 500G with multiple indexes is not so cheap.

And the reason why you don't see a lot of DB servers is that it is HARD to scale DB by just adding servers (I am ignoring for a second non-SQL servers w/o joins as well as high-end Oracle and new MySQL-Galera solutions). An ACID compliant SQL DB is a single-server affair unless you invest heavily into the DB itself since it is really hard to run DB cluster even from pure operational standpoint.

Sure, I was considering cheap optimizations — APC is helpful, but not that helpful.

Most queries in most projects are cheap.

On the other hand, frameworks that have ORMs and other DB abstraction layers often make trade a little bit of DB time (and developer time) for a lot of framework time.

And as you say, scaling the DB is a lot harder than scaling the app servers (typically) — the implication being that trading framework performance for developer time makes a lot of sense.

Well, all applications are different so can't comment on your experience. For me APC does at least 2-3x in the max number of non-DB requests per second. Personally I think it is a lot.

As with any technology, ORM is just a tool. Used wisely it works great. Used it w/o understanding of what you are doing - you get a recipe for disaster.

"Most queries in most projects are cheap" is the true assumption for small projects. When you cross certain threshold, none of the non-cached queries are cheap (by non-caching I mean caching in all layers including the DB itself).

And I strongly disagree with "trading framework performance for developer time makes a lot of sense". In 99% of cases you DON'T care about performance. Yet, a "bad" framework adds penalty in 100% of cases. I strongly prefer to have a good-enough performance from the framework and then focus on this 1% of cases when it matters (and in majority of cases, it's the DB, not the app code).

> In my statement I kind of assumed that all the "cheap" optimizations in the framework are already done (e.g. PHP APC cache is enabled, lazy classes/configs loading is implemented, etc.) so we compare "apples-to-apples": a highly optimized C++ framework to a highly optimized, say, PHP framework

I'm kind of skeptical, to be honest. I suspect a simple, unoptimized C++ application wouldn't have a lot of problems keeping up with a highly optimized PHP framework. Interpreters do so much extra work.

Not that I would use C++ for web stuff- that's 99% string munging, and string munging in C++ is how you wind up with your desperate last words mockingly quoted on seclists.org.

Assume your DB query takes 10 secs. It's irrelevant if C++ code takes 0.01 sec when your PHP code takes 0.1 sec.

Now why would I assume that? There are times when you need to generate a big report, and just the SQL can take that long or more. But typical web requests for typical applications are not like that. DB queries shouldn't take more than a couple hundred milliseconds for "typical" application requests.

Even counting that, the comparison is also not necessarily correct. In some cases, perhaps the C++ code would have taken 0.1s, where the ruby code takes 5s. In fact, 50x is about the slowdown you used to see for ruby in the programming languages shootout, and it is still pretty bad. [1]

[1] http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

I must say, I made a beeline for the security page and was not disappointed. While I think they underplay the risk of memory corruption flaws (namely by emphasizing backups to be critical, rather than isolating user data to minimize compromise in the case of the site being owned), they otherwise do a fantastic job. I can nitpick a bit (and will probably send some recommendations to improve the guide a little) but I really have to commend them on that.

I knew I would find a statement like this in the security page: "So using modern language techniques programming in C++ is not more dangerous then programming in Java, Python or Ruby."

This is a belief that many C++ programmers have, and having spent much of my life in the past few years finding ways to break a C++-like memory model (Rust) I cannot emphasize enough how dangerously wrong it is. Safer than C, sure. As safe as a memory-safe language like Java, absolutely not.

What are you talking about?

The safety you mentioned comes from only two things: type safety and runtime array boundary checks.

There is no problem in implementing runtime boundary check in C++.

What else in C++ is less safe than in Java? Is there some kind of magic?

Iterator invalidation, returning references that outlive their referent, storing references in data structures that outlive their referent, invalidation of the "this" pointer, etc.

Basically those are examples of bare pointer manipulations (as references are essentially syntactically sugared bare pointers).

Although it can be mitigated with specially written collections (incompatible with the standard collections) and strict coding guidelines, I have to agree with you that the C++ memory model itself is insanely dangerous.

I would like to see an implementation of our test suite [1] for CppCMS in order to see the CppCMS vs CPoll-Cppsp cage match. Any C++ experts who would be so kind to send us a pull request? :)

[1] http://www.techempower.com/benchmarks/

I love that the code for the fastest database backed web server[0] found in this test suite, beating golang by 40% and node.js by 13x comes from a repository[1] that is filled with "all the code i've ever written since grade 11; also includes some forward-ported code from grades 8 and 9." including random class projects and a netcat replacement.

[0] http://www.techempower.com/benchmarks/#test=query

[1] https://github.com/xaxaxa/workspace/

Yeah. I've considered adding a popularity attribute of some sort to use in the filters. E.g., "mainstream," "challenger," and "fringe." But to date, I've not put a whole lot of thought into how exactly I could objectively measure popularity. Perhaps Google search hits for "[name] web application framework."

That would be biased towards the frameworks named as some common word (like "go") being mistakenly marked as more popular than they are.

Indeed. I'm not really sold on the idea, and addressing this is not a priority.

I just wanted to point out that I'm aware that it's a little funny to see fringe frameworks compared head-to-head with mainstreamers. But the charts are but one data point to consider in evaluating options. :)

cppsp also compiles with a comically large number of warnings.

Haha, I feel like there is a language bubble, everyone is using their interpreted/bytecode language, but people never realize how performance can be and is still always an issue. Even with the fastest computer, or cloud, or cluster, computer resources are always finite, and it's easier to reach that limit than anything else.

People relying too much on inteepreted or bytecode languages end up making abstraction on what happens on the metal, forget the basics of good enough performance, and bam, even the fastest server looks like a piece of garbage.

I'll always be conservative regarding language choices, because if a language makes things easier, it should also be taken with a grain of salt.

CppCMS license is LGPLv3 - not too company friendly.

CppDB on the other hand is MIT or Boost. It is the best DB library I found so far for C++.

How is LGPL not company friendly? It allows you to make all the changes you want for your own web site without having to distribute source code. If CppCMS is designed as a library, you can even use it in proprietary applications.

1. It is limiting: no static linking or you have to distribute re-linkable object files (LGPL section 4.d.)

2. It is long and complex license, not yet tested in court. Sometimes what constitutes a "derivative work" is not that clear.

3. Section 6 says all these can be changed anytime, potentially making it more restrictive (see GPL v3).

So from the business viewpoint it is better to find an alternative now than to potentially lose all the investment later.

The LGPL doesn't apply to network distributed software. Working with this software via an API (i.e. HTML) doesn't mean you need to do anything.

These kinds of licenses are put in place so people can't create proprietary extensions/patches and fracture a community. Now, I'm not saying this is better than MIT, but at least deters people from that.

1. will only matter if you are distributing binaries to clients/customers, which generally isn't the case with a SaaS product.

It does limit your future options.

GitHub started out as SaaS and now offers Enterprise product https://enterprise.github.com/

CppCMS also offers commercial licensing. Don't get me wrong, I love BSD and MIT software, and release some of my own code under permissive licenses, but it really bothers me when someone complains about the GPL or LGPL because they want to free-load off of others' hard work. The LGPL is a very commercial-friendly license!

I like to release my libraries and tools under the BSD license, and I like to use others' permissively licensed libraries and tools in my own proprietary/commercial/closed applications.

LGPL doesn't stop that. You can still distribute your own source under your preferred BSD license. And if you link dynamically, the LGPL can't impose its requirements on your code.

The LGPL only requires that binary distributions of the derivative work have source reasonably available and that the library can be switched for another version by an end-user.

I really like the fact that Linux is GPL, the license served the community well. For large, stand alone apps it makes sense.

On the other hand I try to avoid GPL/LGPL for components.

Here is a scenario:

1. Invest in developing your app based on CppCMS

2. It takes off, great - buy commercial license.

3. The next version of LGPL gets more restrictive, you're stuck with commercial license.

4. Artyom gets hired by Google/Apple, no time for CppCMS anymore; only the LGPL fork gets fixes from now on.

5. Throw away your investment (time and money), start learning something else - how cool is that?

That can happen with BSD software, too. Thr LGPL only gets more restrictive if the author releases a new version of their library that only permits the new LGPL version. Any project can change its licensing at any time, but with most open source licenses you retain your rights under the old license.

Yes, it can happen with BSD and MIT. But at least you can start a fork from there, if you really have to. Forking LGPL stays LGPL, with the limitations & all.

1. It is limiting: no static linking or you have to distribute re-linkable object files (LGPL section 4.d.)

Static linking is fairly uncommon; it's more common to distribute the versions of DLLs you require on Windows, or use a package dependency on specific versions (or provide your own copies) of the system-provided libraries on Linux.

3. Section 6 says all these can be changed anytime, potentially making it more restrictive (see GPL v3).

Section 6 of LGPL3 does not say that; it says that you have the option of choosing a later version. Any code released under "GPLv2 or later" can still be used under GPL2.

https://www.gnu.org/licenses/lgpl.html

> CppDB on the other hand is MIT or Boost. It is the best DB library I found so far for C++.

Have you evaluated Code Synthesis's ODB?

Are these key-value DBs like LevelDB / BerkeleyDB / etc? or maybe something more sophisticated?

Both CppDB and ODB are abstraction layers between your code and SQL (Postgres, mySQL etc). ODB is somewhat closer to ORM.

CppDB uses MIT or BSD license (you pick), ODB is under LGPL or commercial license.

> Have you evaluated Code Synthesis's ODB?

I did not test ODB yet, but I'm planning to. Not fan of their license tough...

> CppCMS license is LGPLv3 - not too company friendly.

Actually LGPL is as 'free' as it gets with the GPL license family. If I wanted to be 'company unfriendly' I'd choose the AGPL.

But the thing is: Arguing about licenses is nonsense. The developer has an agenda and chooses the right license for it.

For me if I release open source I almost always license it under GPL3/AGPL because I don't want someone to take my code, stuff it into a closed system and make money of it. If I decide to contribute to the open source community I don't want leeches to profit from it.

If you want to use my code commercially: pay me.

How is LGPL not company friendly? As CppCMS is to be used on the server, there's no requirement to redistribute code, so the redistribution requirements of the GPL and LGPL don't apply to anyone except internally to the company.

And even if the company chose to open their source and distribute it, using dynamic linking allows them to choose any GPL-compatible license they like.

I don't see how it's "not company friendly."

Since Blizzard use LGPL in their flagship product Starcraft 2[1], I would consider your statement to be verifiable false.

[1]: See the end of the credit from SC2 HoTS

"CppCMS is a Free High Performance Web Development Framework (not a CMS)"

This is so dumb. Why it is called CppCMS then?

http://cppcms.com/wikipp/en/page/faq#If.CppCMS.is.not.a.CMS.....

Quote from that page:

The original idea was: "Write your own CMS in C++".

The lead developer asked in 2008 for a better name but didn't get any suggestions, so the name stuck.

It was decided later to keep this name as it was already well known name and all the software around used cppcms as the namespace.

I looked into CppCMS a few months ago, I would love to use it but the lack of SSL/HTTPS is a huge detriment. If I have to stick nginx in front of it for SSL I may as well keep using fastcgi.

I would be interested in how this perfoms compared to the web server implemented in Go

Or Erlang.

They've got translations in their example: http://cppcms.svn.sourceforge.net/viewvc/cppcms/blog/trunk/p...

Something more web frameworks should do.

If the only benchmark is going to be against PHP + Wordpress, you might as well just say it's better than zero.

It seems there's no documentation?

http://cppcms.com/wikipp/en/page/cppcms_1x

Odd wiki. Unlike Wikipedia, the front page is completely open to public editing.

C++ isn't suitable for Web programming.

Half of eBay used to be a massive ISAPI dll plugged into the back of IIS.

It did a fine job at the time!

More details on this?

http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29...

Thank you sir! Any video to go with the slide deck ? Or article. The deck is interesting, but I'm still thirsty.

This was back before we had videos :)

OKCupid is written in C++ as well. (http://www.okcupid.com/about/technology)

That seems really strange. I mean I get why their database is written in that, but I would imagine that their matching algorithms, at least, were written in something more easily adapted to change. It is one of the cases where I would want to write it in Lisp.

Google is C++ (the part which actually brings in revenue)

You do realize that the most widely used Ruby, PHP, Python, Perl, JavaScript and Java implementations all rely very heavily on C and/or C++ in one way or another, right?

Even when using JRuby, for example, it's still running on a JVM that's very likely implemented using one or both of C and C++.

Don't forget that the major web servers and web browsers are all implemented in C and/or C++, or in one of the many scripting language or other runtime implementations implemented using C and/or C++.

And that's ignoring all of the other infrastructure, like server operating systems, router software, and so forth that's implemented using C, or C++, or both.

Every line of code executing in your non-C or non-C++ web development language of choice likely depends on many thousands of lines of C and C++ code, even as you malign them here.

http://pypy.org/

PyPy may someday be a viable replacement for CPython, but that day is not today. The viability becomes much more questionable as more and more of the Python community moves to Python 3, which PyPy basically does not support.

That's not the point. The point is that the argument that modern languages are written in or depend on C/C++ is fallacious: there is no need for C or C++ there, nor is there any technical advantage to their use. CMUCL and SBCL are almost entirely self-hosted, and things like PyPy and JikesRVM stand as strong examples in other languages.

Nobody here has said that C or C++ are absolutely needed. I merely pointed out the reality of the current situation, which is that both C and C++ make up a big part of basically any web app around today, even those written in some other popular languages.

Also note that I referred to "the most widely used" implementations of those languages. Yes, we know that PyPy exists, but CPython is still used far, far more often. Yes, we know about Common Lisp implementations like those you listed, but the reality is that they basically aren't used in practice. PyPy, CMUCL and SBCL are essentially irrelevant when considering the big picture. C and C++ are involved in one way or another in pretty much every other case.

If you refer to the original post in this thread, you will see that it was about the supposed unsuitability of C++ for web development. When we look at the entire picture, however, we do see that such sentiment is quite wrong. C and C++ play an absolutely huge role in modern web development and web applications, regardless of what some people may think.

Yes, of course in the end everything runs on machine code. That does not imply though that it is reasonable to write your web applications in machine code or assembly or C or C++.

I'm not arguing whether or not C++ is actually suitable for web development, I just don't think your line of argumentation makes sense.

The majority of that C and C++ code is hand-written, and not just the output of a compiler or an assembler. They have directly been used to craft some of the most important, and often most difficult to implement, parts of the web application stack.

It's absurd to claim that C and C++ aren't suitable for web development when a huge part of basically every web app today is written in one or both of them. They aren't just suitable for web development; they are critical for it.

You're arguing semantics so let me continue the pattern.

In any non-trivial (jobs/money are on the line), web development != web programming. C/C++ is suitable for web programming, sure, but web DEVELOPMENT is an entirely different matter and is highly dependent on the availability of support, both community and professional, staff, and the competency threshold (or "learning curve") which is the knowledge you need to contribute meaningfully. The latter is one of the most important, especially since the vast majority of C/C++ programmers are not web developers, and doing something wrong in C++ is a lot easier than in memory managed, interpreted languages.

Ok, but there's a huge difference between the VM being written in C or C++, versus the web application itself being written in C/C++.

Facebook was running a C++ based PHP interpreter, I'd say that's Web programming in an extreme capacity.

That sounds like saying assembly is well suited to web programming because Ruby compile down to it eventually.

Not exactly. Now about half of the Facebook developers use C++ (the other half PHP)

Is that the rest of some technical feature or set of features, or just that most college graduates can be expected to have some minimal competency with C++ coupled with the fact that the PHP interpreter was written in C? I am inclined to think this is more a pragmatic decision than a technically motivated one.

It was technically motivated:

https://developers.facebook.com/blog/post/2010/02/02/hiphop-...

https://github.com/facebook/hiphop-php/wiki

https://www.facebook.com/notes/facebook-engineering/folly-th...

Edit: From the 1st link

"[...] I started my first piece of code transforming PHP into C++. The languages are fairly similar syntactically and C++ drastically outperforms PHP when it comes to both CPU and memory usage."

It sounds to me like they wrote a PHP compiler that leverages GCC's optimizer. I am not seeing the technical motivation to use C++ for that; it would have been just as good to just produce GIMPLE. It looks like C++ was just chosen because it is what the developers knew, which is not all that far off from what I said.

(Edit: it is also worth pointing out that the motivation for this tool is to avoid having to write C++ code)

HipHop was originally just a source code converter. It basically took PHP source code and compiled it to C++ code. It's because they wanted to write in PHP but they needed C++ speed. But I don't think that's how it works anymore.

I'll reply at all the above here.

When you have load/concurrency that needs you to move to C++ there's no doubt C++ is right.

When you reach that level though, you will usually have the resource to build infrastructure specifically designed to your need, dismissing any "general" purpose C++ framework.

All the example mentioned here are using in-house products for the most part.

I am not sure it is ever true that there are no doubts about C++ being "right." It might be "good enough," but it is a generally bad language that would not be my first choice for anything (I would sooner use C, but even that's not my top choice).

Well, I might have over-emphasize on what is "right". Blame this on the language barrier :)

And I would sooner use modern C++, it is personal preference and experience.

It's not about experience, it is about the language. Modern C++ is basically a motorized stone hand-ax. Even experienced C++ programmers are surprised by undefined behavior and unexpected semantics.

A significant amount of undefined (and unexpected) behavior in C++ is inherited from C, for compatibility. You'd sooner use C, and fall into undefined behavior quickly as well.

C++ is large and hard to master, but I don't think UB is the best reason to choose C over it.

C++11 is years ahead of Java. http://herbsutter.com/elements-of-modern-c-style/

I especially like the fact that you can specify which variables are captured by the closure: http://www.cprogramming.com/c++11/c++11-lambda-closures.html

I use both C++ and Scala on daily basis and there are just a few things I wish C++ had from Scala. On the other hand it is a huge time saver not having to worry about the JVM GC freeze.

> not having to worry about the JVM GC freeze

Bad engineers blame their tools.

Good engineers start with good tools and avoid wasting time.

See section 9 http://www.joelonsoftware.com/articles/fog0000000043.html

Yeah, let's use a memory unsafe language, handle memory management by hand and just completely ignore the fact that no human being has ever managed to consistently write bullet-proof code in it.

Using software which automates memory management, engineered by the brightest minds on this topic, is for hipsters, right?

I guess you also roll your own crypto and implement stuff in assembler “for performance”?

It depends on the use case.

Sometimes you need performance or there are other constraints, in which case your choice of language is very limited.

Automated memory management works, but not all the time. And how about other resources? How you make sure your mutex gets released? Add a comment "please don't forget to release this one"? How about file handle, temporary file, serial port, DMA, GPU, network port and other limited resources?

BTW, I think most of the brightest minds you mention use C or C++ on daily basis. :)

"Automated memory management works, but not all the time."

[citation needed]

"BTW, I think most of the brightest minds you mention use C or C++ on daily basis"

I doubt it. Most of the brightest minds I have met, at least in academia, use high-level languages: Python, OCaml, Lisp, Haskell, etc. They have more important things to worry about than whether or not it is safe to deallocate objects.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses"

Do you realize that almost everything widely used today is implemented in C, C++ or ObjectiveC?

All the operating systems (Linux, Windows, Mac, iOS, Android), most of the desktop apps (Office, Photoshop), programming languages (PHP, Ruby, JavaScript, Python, both Sun and IBM JVMs), browsers (IE, Chrome, Firefox), web servers (Apache, nginx), database (Oracle, MS SQL, mySQL, Postgres, Redis, MongoDB), Google's search engine, eBay, Bing, Facebook, most of the games, embedded medical devices etc.

http://www.stroustrup.com/applications.html

"Do you realize that almost everything widely used today is implemented in C, C++ or ObjectiveC?"

Yeah, and we are plagued by the bugs and security problems made possible by those languages. Imagine how much more we could be doing if programmers were not spending hours trying to figure out where a dangling pointer was created.

Really, the popularity of C, C++, and related languages has little to do with the languages themselves. C became popular because of Unix, not because of its technical features, and Unix became popular because of its licensing. C++ became popular because of Windows, not because of its technical features; Windows became popular because of the Unix Wars and because of MS Office. If Unix had been written in Lisp or ML, we would be talking about how popular Lisp or ML are. For what it's worth, entire operating systems were written in Lisp at one time; their failure had nothing to do with their technical merits and everything to do with terrible marketing and bad predictions.

If you want to talk about how fantastic C or C++ is, try pointing to an overwhelming success story that could not have happened without the language. Altran Praxis has the lowest bug rate in the industry; they credit the SPARK programming language, which is well-suited to the formal verification techniques they rely on. The military planning system DART paid both its own development costs and several decades of research that led up to it; it was thrown together in a few weeks using Lisp. I have yet to hear that kind of success story from C++ programmers; the only thing I ever seem to hear about are squeezing a few extra clock cycles out.

If this were a popularity contest, we would still be hand-rolling assembly language. The same reasons that led programmers to use compiled languages apply to switching away from low-level languages like C and C++. Sure, people are still writing assembly language, but it is a niche. That is where C and C++ should be: a niche, mostly just for maintaining legacy code that is too expensive to rewrite in a better language.

Good trolling skills, I must admit. :)

So there are some anecdotal stuff nobody actually seen, but it will change the word anytime now.

Don't hold your breath: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...

Android: http://www.war-worlds.com/blog/2012/06/on-android-garbage-co...

C#: http://conversations.nokia.com/2012/06/01/interview-with-mat...

Ruby: https://blog.twitter.com/2011/building-faster-ruby-garbage-c... (It was not good enough, they dumped Ruby)

Accepted answer? "Manual tracking of objects" http://stackoverflow.com/questions/2484079/how-can-i-avoid-g...

Google has 14 million web pages about Garbage Collector issues...

"C++11 is years ahead of Java"

OK but so what? It is also years ahead of BF.

C++11 has a few nice features, but it is really dragged down by low level issues. You talk about garbage collection like it is a problem, but C++ still does not even offer good garbage collection (not even optional garbage collection) for those situations where it makes sense. At least with Java you do not need to manually break cyclic references to prevent memory leaks.

As for closures, why would I want to specify which variables are captured? If I reference a variable from the enclosing environment, I capture it. If I mask the variable, I do not capture it. What point is there in explicitly declaring this? Frankly, the entire C++11 approach to closures is insane. Why add the extra syntax to explicitly declare how variables are captured, when capture by value covers all cases?

I stand by what I said. C++ is an awful language.

Since it has deterministic destructor and RAII is easy to implement, garbage collector is not needed. It works not only with memory allocation, but any other resource you need to release: mutex, serial port, window handle, file handle etc. Also move schematics really helps with performance: create, copy & destroy can be avoided altogether. No garbage, nothing to collect. :)

BTW, Normally you should avoid "new" and "delete", only very special use cases need it.

Specifying the closure variables is optional and it is both for performance and encapsulation. You can specify "nothing", "everything by reference", "everything with copy", just some by copy or reference - mix & match. If this is too much to start with then just copy everything with [=] and clean it up later if it turns out to be a bottleneck. The point is: you can save on cycles if you want to/have to.

If you think C++ is not a match for you, that's OK, there are plenty other languages. You don't need performance all the time - some are OK with 400 queries/sec, others want 7,000 on the same server: http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...

"Since it has deterministic destructor and RAII is easy to implement, garbage collector is not needed"

This is kind of like saying, "x86 has CALL, PUSH, and POP operations, so there is no need for a language with subroutines! Just use inline assembly!" Garbage collectors are not strictly needed in any imperative language. The point of garbage collection is to enable programmers to think at a high level, without having to divert their attention to low-level issues.

"Also move schematics really helps with performance: create, copy & destroy can be avoided altogether. No garbage, nothing to collect."

Move semantics are a solution to an artificial problem. Sensible defaults like allocating objects on the heap and using references everywhere would have solved this problem and many others. Yes, I know that the C++ approach to programming is supposed to give programmers the power to do things for themselves, but that does not mean that the default semantics have to be brain-damaged. If code like this:

  std::vector<int> vec;

Caused an object to be allocated on the heap, and created a reference to that object, move semantics would not be needed. To stay true to the C++ way of doing things you could have a special non-reference type. Note, of course, that this really needs garbage collection to work well, and that the garbage collector would be entirely optional (as Bjarne Stroustrup suggested): programmers wanting to avoid the garbage collector would use non-reference types and pointers to non-reference types.

"Specifying the closure variables is optional and it is both for performance and encapsulation"

I am not seeing how it makes sense for either. Specifying anything about how variables are captured is a pointless exercise. Variables should just be captured if they are not shadowed, and they should always be captured as copies. When programmers need to capture by reference, they should just create a reference and capture that. Introducing another syntax just to declare how variables should be captured, and then making another nonsensical default behavior (no capture at all), is just silly.

"You don't need performance all the time - some are OK with 400 queries/sec, others want 7,000 on the same server"

You know, it is not a very strong argument when the top result (in C++) is only marginally faster than the next best (in Java). The fact that another C++ framework happens to be much further down, below systems written in Java, Scala, PHP, and Lua, is also not helping you. If anything, that test shows that the cost of using a high level language is not so bad; fantastic performance can be achieved without having to fumble around at a low level, and low level languages like C++ are not a guarantee of good performance.

https://news.ycombinator.com/item?id=5998050

Google after benchmarking C++, Java, Go, and Scala:

"We ﬁnd that in regards to performance, C++ wins out by a large margin. [...] Scala concise notation and powerful language features allowed for the best optimization of code complexity."

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...

(shameless plug: my projects based on cppcms)

https://github.com/allan-simon/tatowiki/

I've made a complete wiki engine (with also search engine integrated), which is easily skinable etc. (it's still at an early stage) , you can find an instance here http://en.baike.jisuanjiwenti.com/

You can check the line of code and the architecture of it, to have also developed with some PHP framework, I didn't find anything "weird" or to far from my old habit (and I do prefer compile-time check and possibility to run my server in gdb)

In order to help me create faster application with cppcms, I've started to create a framework upon cppcms here https://github.com/allan-simon/cppcms-skeleton

1997 called. They want their framework back.

While I still stand by what I said, I want to add a clarification. Some languages are good at some things while others are good at some other.

C/C++/etc are good for job intensive stuff that doesn't need fast maintenance cycle.

Dynamic language are good as web server because of their flexibility and their fast response time (In term of maintenance)

I wouldn't run an OS on Javascript and I wouldn't use C++ as a Javascript replacement in the browser.

How did Java fail? Java servlets are still very much so in use. This is for back end code, and I can certainly see this being useful.

Edited to add that they mention that this won't satisfy every use case, and also what use cases they think it does satisfy. http://cppcms.com/wikipp/en/page/when_to_use_cppcms

I removed the Java part because it was ambiguous and unecessary

Don't you think that first off you need to be an expert in all those languages, in web-technologies, have vast experience and up to date knowledge in all of that, to make such claims?

I'm pretty sure you just have wrong impression of C++, or to put it simply, you don't know C++.

In what way does C++ have worse response time in terms of maintenance? What do you mean exactly?

In general, statically typed compiled languages are better at refactoring than dynamically typed interpreted ones. Changing programs in the latter without fair test coverage means teetering on the brink of a catastrophe. Just recently I have seen an article on HN claiming unmaintainability of dynamic languages.

The truth is that every general purpose language is general purpose, and the claim about language suitability is a commonplace and an overgeneralization. You can do 3D games in JavaScript and client web apps in C++. Different languages have different drawbacks and that may limit their applications, but C++ is not targeted for OS development, and JavaScript is not targeted for web development, both are just general purpose languages.

Speaking of "low-levelness" of C++, with all the modern features and libraries it is as high level as other languages, and in some aspects is even more high level, e.g. JavaScript or Python have no corresponding means as the template metaprogramming which is the high high level. C++ just allows you to do low-level manipulations, you are not required to.

There are many myths and prejudices against C++ caused by ignorance and frustration of those who have not cracked it at a time.

The C++ vs Javascript example was, wait for it, an _example_.

It was a general statement aimed at a general framework. I said in some other place here that C++ is relevant but when it is, it's usually done via in-house library that are specific to your need.

All the example of company here using C++ use their own solution and most use C++/C/etc as a VM or code interpreter and uses another language for the logic.

Don't be offended because C++ doesn't do everything. For all I care, you code your server in C++. I'll code it in whatever I want and I'll sleep like a baby.

Exactly! C++, well used, is largely a vertical language, not a low-level or high-level one. That's why it's easy to create a fairly big system entirely in C++. And having worked with such a system, I can say that it's quite comfortable, in some ways that most so-called "higher-level" languages don't offer. For example, your comment about refactoring is absolutely spot-on.

Most criticisms of C++ rely on outdated prejudices. Some people still think that modern C++ code is rife with pointers to void and reinterpret_casts.

To be fair, bad code still is, and it's more common than most of us would like to admit.

What's next ? A OS written in Ruby ? snark

It's not a Content Management System. Read the article.

Reply on news.ycombinator.com