My first reaction to seeing Rails BITD was to think 'wow this would be so fast done in C++'.
Then about 2 years later, when I began to really understand Ruby and some of the community had shamed the C++isms out of me, it became clear why it was impossible.
Ruby interpretation and introspection makes so much possible in an elegant way - you can bruteforce Rails out of another language but you'll lose a lot of what makes Rails so powerful in the process.
For backoffice webapp use I believe nothing can compete with Rails currently - it's stable, well documented and has awesome library support.
However, highload client performance does not come out of the box, which is part of the reason for the drift to Node or lighter Ruby frameworks.
I don't think you need to make Rails faster, you just need to use it for what it does best (complex backoffice apps and APIs) and use something lighter for the high performance requirements.
I'd agree with this, and append the suggestion that if particular parts of your application have high performance demands, those should actually be decoupled from the main app into API'd services. This tends to make the entire application more elegant while using the appropriate technology for each task.
I don't know why you are being downmodded. You are precisely on point - in Python (a slow language, similar to ruby), I'd often spend 50-500ms in the db (or 10-100ms in memcached) and 1-10ms in code.
Optimize your sql, then optimize your memcached.
That said, I've recently been working on a project building a webapp in Scala. The type safety Scala gives is amazing.
Want to write to master then read from a slave in the same http request [1]? Won't compile. Want to build a page without a tracking beacon? Won't compile. Want to prevent invalid input to enum fields (e.g., a string for which the only valid choices are "moderator", "subscriber" and "contributor")? Compiler has you covered.
[1] If you write to master then read from a slave, there is a nontrivial chance that the result of your write won't be mirrored to the slave.
We have two main stacks at my company. One is Rails-based, the other is a mix of C++ and Java. The tasks that the C++ and Java side do is significantly more complex (real-time graph-traversal and number crunching) than what Rails is doing.
On similarly sized server instances our Rails stack can handle about 10 requests per second, whereas our C++ / Java stack can handle about 400.
In practice the only time that I've seen the database be the bottleneck in Rails is when the database is accessed by people that pretend that ActiveRecord is in-process data and just use it like it's not querying a database (e.g. I've seen pageviews that require 30+ SQL queries). That or their database is set up in stupid ways and doesn't have indexes in the right places.
Rails is actually very slow. That said, I think a smarter approach than recreating the framework in faster languages would be to allow C or C++ into the main Rails project and to rewrite the hot parts in one of them. We sped up ActiveResource by about 35x by reimplementing it in C++ (with no changes required to our apps).
QActiveResource is pretty cool. It looks like it might leak in the presence of Ruby exceptions, though.
When I do this sort of thing, I wrap ruby.h function calls with rb_protect, check the return code, and then throw a C++ exception to unwind the stack. There is an allocation cost to doing that.
> our Rails stack can handle about 10 requests per second
Is this representative? I built JMeter testing into a series of Django apps I built for the portal I worked for and the numbers were consistently higher. I always assumed they were similar in performance.
I think that if the app were doing something extraordinary, wheels would mention it. The ones i built Jmeter testing do straightforward database queries, HTML (sometimes image) rendering and queuing stuff for future processing.
In any case, I haven't tried to optimize them (memcache and front-end caching were kept minimal and implementation as simple as possible) before going live (after, of course, making sure they were load-tested and would survive a reasonable load) so we could watch what breaks under load, compensate with extra iron, and correct it later. All those machines were heavily monitored.
I was on a Rails project with some pages spending 200ms or more rendering views. To some extent that could have been got around by inlining partials or getting very clever with cache invalidation, but it would have come at a high cost in terms of complexity. Maybe a C++ framework could hit the performance/complexity sweet spot better. Then again, the site's down, so maybe not.
I agree that one area where rails could improve is in the string serialization/ERB component (e.g. includes shouldn't materialize a string then write, but should concat to the current output for example) but ruby strings are pretty damned fast in my experience. I believe that's an implementation detail that could be addressed without going to C++.
I think wt is much better suited than a rails clone for the few kind of webapps you'd write in C++.
http://www.webtoolkit.eu/wt/
You can think of using it as a multiplatform GUI for a native app, that runs locally but uses the web browser instead of something like Qt or WxWidgets. Or you can use it for a webapp that pegs the CPU more than a database.
I really don't understand the Rails clone thing. When Rails did was take a lot of best practices from all over the web and wrap it up in Ruby using the best features of that language to maximum effect.
It seems to me if you want a good C++ web framework, you need to start from first principles instead of trying to clone something designed from the ground up in such a different language.
On the one hand, it's certainly reasonable to have a site up for the project before the code's ready. On the other, I certainly hope they're building something meaningful with it, before they call it stable.
Then I hope they've done something meaningful with it. It doesn't necessarily have to be reimplementing their working (although apparently it isn't...) site, is what I was trying to convey.
I actually wonder what the market is like for a C++ web framework. In principle I like the idea of a framework built using a compiled language, but I imagine it'd be far easier to write a vulnerable application.
OkCupid use their own event-driven C++ web server framework for their website. I don't remember to what extent but it at least powers specific features such as Chat ans Search; I can't guarantee they use it for the pages of the website but I'd say they do (there are a couple of presentation but I read them long ago).
We do use okws for the whole website. It's more work to use than a framework like, say, Rails but it's well-designed and has some great features.
For instance, it includes a templating language called Pub. A typical request hits a handler in C++-land which collects the data the page'll need into a top-level Pub object. Then it invokes a Pub template which renders the page. All of this enforces separation between your back-end logic and the design of a page.
It would be awesome to see more frameworks with fresh ideas in this area, though.
More rigid static type safety, mostly. Haskell doesn't allow you to accidentally cast something to the wrong pointer, or accidentally index off the end of an array, or similar things to which C++ is vulnerable but which modern interpreted languages protect you against.
Meanwhile, Haskell's sophisticated type system lets you enforce rules that help make sure you don't accidentally pass an unescaped string to your database or user's browser, which kinds of errors are rife in even those sites developed in interpreted languages. Yesod leverages this extensively.
On reflection, I think C++'s templates may be powerful enough to let you do similar, really, but 1) it is likely to be incredibly verbose, 2) you are still potentially vulnerable to the pointer or buffer related errors mentioned above, and 3) in my experience people don't generally write C++ that way - it'll be interesting to see what they've done here, though.
Was expecting a much larger gap in performance from standard frameworks, it's not that faster after all. And how can PHP with it's per-request lifecycle be faster?
This is interesting, I'm a c++ developer by day and like Rails on the weekend so it tickles my main interests.
Building a large app that needs performance? I could see a C++ web framework being useful, but basing it around Rails is a weird choice. Rails is great for what Rails is great at, try a whole new bag that works with the language benefits and the expected use cases.
It would be interesting to see how this framework's performance would compare to something like the Play framework (Play for Scala 2.0)..I mean, do you think a C++ framework like this one would be able to scale and/or handle much better traffic/load than a framework like Play?? (Play for Scala 2.0 in particular)...Anyone?
Unlike Ruby, I'm stilling waiting for the one framework to stand out and dominate others, like Rails.
As of now, there are too many little web frameworks in Go. Most of them are inactive. People still have a hard time selecting which one to use for their project and not regret their decision in the future.
Ruby has Rails, Python has Django, what does Go have? Just name one, not a list.
Then about 2 years later, when I began to really understand Ruby and some of the community had shamed the C++isms out of me, it became clear why it was impossible.
Ruby interpretation and introspection makes so much possible in an elegant way - you can bruteforce Rails out of another language but you'll lose a lot of what makes Rails so powerful in the process.
For backoffice webapp use I believe nothing can compete with Rails currently - it's stable, well documented and has awesome library support.
However, highload client performance does not come out of the box, which is part of the reason for the drift to Node or lighter Ruby frameworks.
I don't think you need to make Rails faster, you just need to use it for what it does best (complex backoffice apps and APIs) and use something lighter for the high performance requirements.