Rails like framework for C++ with great speed
treefrogframework.org
treefrogframework.org
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.
The second I touch a network resource (typically the database) all the hand-crafted assembler in the world ain't gonna save me.
A stronger argument for a rails rip off in a statically typed language would be tool support, esp. consistent code completion.
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.
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).
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.
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.
What version of Rails is this? And can I talk you into open-sourcing it, if you haven't already? :)
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.
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.
There's also a port to the JVM and ruby bindings.
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.
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.
Check out yesod (www.yesodweb.com).
> I imagine it'd be far easier to write a vulnerable application.
In C++, probably, yes. In Haskell, not so much.
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.
Cache for the performance comparison: http://webcache.googleusercontent.com/search?q=cache:wSdyzM4...
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.
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.