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.
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++.
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.
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.
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.
If possible, try to make Go work. It's concurrency model is great for massive concurrency.
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.
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.
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.
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.
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.
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?
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.
CppDB on the other hand is MIT or Boost. It is the best DB library I found so far for C++.
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.
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.
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."
[1]: See the end of the credit from SC2 HoTS
Have you evaluated Code Synthesis's ODB?
This is so dumb. Why it is called CppCMS then?
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.
Something more web frameworks should do.
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
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.
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.
It did a fine job at the time!
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.
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.
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'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.
