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.
I've done basically exactly the same thing. Much of the webapp is written in python, but the core performance critical part is written in C++. There basically wouldn't be any other way to make that particular app work, and this approach worked really well.
That being said, I never felt particularly inclined to write the whole things in C++.
> That being said, I never felt particularly inclined to write the whole things in C++.
Agreed, however one of the problems we are encountering is passing messages efficiently between RoR and the C++ components. Currently using XML until another method that is more efficient, but no less flexible, presents itself.
Personally I think the debate should be less focused on which language to write your web application in, and more on improving the glue between different languages so in developing web applications we can have the best of all possible worlds.
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.