His prediction that other frameworks will become more Rails-like is accurate, but about two years late- most languages now have at least one railsalike web platform by this point. In fact the real problem is typically choosing one that is likely to have a decent shelf-life rather than not being able to find one at all.

There are two things about Rails that are great, one of them is the ideas it is based on, and those ideas are something that one could implement in any language. The other one is Ruby. The runtime needs work (and is getting work) but the language is amazingly easy to work with. That's the bit that other languages have an issue with.

Various commentators have suggested that Java won't be the biggest language on the JVM in the longer term, so the rise of things like JRuby would be a step towards fulfilling that prediction.

Would be keen to know why Ruby-on-Rails is so slow too!

Several of my clients who tried Ruby-on-Rails then abandoned it because of speed and scalabilty. Despite it's other attractions - a big high-traffic website needs something more scalable.

The Python framework Django seems to address these concerns and I have a couple of well-funded dot.com businesses that are using Django for high-profile websites. In fact, due to it's popularity, the main issue is not the technology but finding enough good developers proficient in Django.

ReadyPeople

For all his faults (braggart, twit, vacillator, egomaniac) aren't these the same points he made back in December?

Ghetto's and twetto's (tm) are dangerous.

Don't go arguing with your friends, try and swing some who really isn't on your side - if they come around you may have something.

For the record - Zed, hit Australia and we can go however many rounds you like, then go drink together like real men.

Charlie.

"Let's face the facts: Ruby is too slow," Bray told delegates. He says Ruby 1.8.6 - which dominates the enterprise landscape - is up to 20 times slower than Java.

i dont know when was RoR started to dominate the enterprise landscape. Tim Bray is blinded with RoR's 5 minutes videos he cannot see the facts right. Anybody who plans to do a real fast, multiuser, multi threaded server side application should avoid RoR, or Ruby. According to my tests Ruby is many times hundred of times slower than Java, not 20. (Except some IO operations and regular expressions)

Then you either need to double check the quality of the rails apps or get some decent coders on the other languages.

You probably also need to investigate what the managment are doing (or not doing) in the development cycle

"Other languages could learn a thing or two from Rails and Bray predicts frameworks would become more "Rails-like" - meaning the future does not belong to Ruby on Rails alone."

Indeed it does not, and its XSScripting Needs and Feeds, [and in Control of PROMISe Systems such as Banking and Defence, where Transparent Clarity is best served with Obfuscated Steganographic Code/SurReal Plain Text], are being catered for in PGP2...Pretty Good Privacy PerlyGatesPython for the Full Monty Works in Progress. However/But because of the Sensitivity in the Paradigm Quantum Computing Shift, it is bound to be considered Slow, for it is also AI Lead Root and Branch Rewriting of Universal Source/Resource Locator Protocols. But Bray knows that/has an inkling about that, for he says as much .... and asks the right question, although I notice that the ? is missing in the text ... "the cause of the problem remains unclear - is it compilation of Ruby or "some pretty freaking complex and scary stuff" in Rails."

"But...

"Let's face the facts: Ruby is too slow," Bray told delegates. He says Ruby 1.8.6 - which dominates the enterprise landscape - is up to 20 times slower than Java.

And, despite tests, the cause of the problem remains unclear - is it compilation of Ruby or "some pretty freaking complex and scary stuff" in Rails.

"When you start to run Rails, you get wildly non-linear performance. Rails has worked well on Ruby 1.8.6... everything else is a work in progress. It's weird and it's hard to understand," Bray said.

"Ruby is richly festooned with core libraries and APIs that aren't built in Ruby, they are built in C," he said."

The problem probably is a little bit of all of that, too. However, as long as they a Running on Parallel Tracks and/or in Rails, they'll be Supportive and Complementary to each Others Goals and Tributary Tangents/Dreams and Journeys.

Probably they are hampered by Thinking to Small in AI Bigger Picture ProgramMIng for Pinging Dynasties/Virtual Global Control of Operating Systems?

Google App Engine supports Python and Django. This will no doubt encourage uptake.

John

This is just a guess, but maybe the reason why it's so slow has something to do with the fact that it starts out with a scripting language which has never exactly been world-renowned for its speed, and then wraps everything up in a layer which is bound to slow it down even more?

Everything you see in the market today is about .NET development, then Java and PHP.

I am not even sure I've seen one posting for a Ruby developer on sites like Monster or Workopolis.

Not sure where a lot of article writers get their information from, but from a purely job-seeking perspective, Ruby (and a lot of other fringe languages) is not where its at, and does not dominate any marketplace.

Agreed - I've been developing some small/mid-sized sites using RoR but I've recently switched to Django and mod_python - the sites are faster and on the whole more reliable - I was a Python novice before this, but I've got up to speed on developing Django/Python apps very quickly and won't be considering going back to RoR in the near future!

98 Hits on jobserve.

You do have a point though, programmers are best off sticking with the tools that the employers want. Irrespective of how good the tools are.

"Ruby on Rails" is just another way to make a database-backed website. Of course it is slow - as the computers and networks become faster and storage becomes cheaper, it's necessary to throw a spanner in the works by using slower and less efficient languages, like Ruby. This reduces development time for the programmers, except that it doesn't - the programmers spend the same amount of time or more making the web applications they would have done in another, less bizarre, language, and any time that they manage to save is more than compensated for by reduplication of effort, or "time wasting on rails", which means that for any database-backed web site software there are at least ten different packages, all of which do the same things, all completely unnecessary, all with a shiny three dimensional logo, and all of which will be out of date in six months.

The reality is that there are too many people competing to make database-backed web application software and not enough market for it.

When people are comparing its performance with Java, they evidently aren't /that/ bothered about performance in the first place....

False assumption. You fell victim to one of the classic blunders! The most famous is never get involved in a land war in Asia, but only slightly less well-known is this: When people are comparing its performance with Java ..... they /are/ bothered about performance, but are unfortunately handicapped by being a bunch of PHB morons who think that they "have to have" every latest fashionable faddish buzzword they ever hear as it flies in through one ear and straight out the other.

It makes me sick how web apps are thrown together these days. Any other application requiring high-throughput would be written in C/C++.. but not web applications, oh no, we have to wedge a great lump of abstraction between the application and hardware and then throw loads of memory, processors and power at the thing to make it work.

Maybe if web app 'developers' spent a little less time bitching about how their chosen framework/language is faster than everyone elses and spent a bit more time learning how to program properly we wouldn't need to worry about scalability because it wouldn't take a server room the size of a football pitch to run their crappy application!

At least all these MVC frameworks raise the barrier to entry a little. Ease of coding is what leads to the most awful results... just take a look at an internet full of awful, unmaintainable PHP.

Having to think at least a little about how you're going to structure your app (even if you do just throw everything into the V bit) and using an ORM layer to talk to a database instead of writing flaky SQL probably cuts down on the most common catastrophes of web development, if only by a little.

Assembling a nice FCGI app in C might be pretty gosh darn fast, but is it more economical in the long run than just buying a bunch of shiny Sun T1 boxes and using a more web-dev friendly language?

But expecting everyone to code better is a bit like the myth of educating your users not to do stupid things.

the voice of no experience (I suspect).

"The most famous is never get involved in a land war in Asia" Ol Genghis was quite successful at this, you know !! And all he had was men on lots of little ponies !!

Oops, forgot to mention the 4 1/2 foot plate-armour-piercing arrows that rather upset his plate-armoured foes !!

@Re: Scripting? JVMs? Bah!!! - Just take them all out and shoot them !! Then we can all go back to assembler programming like I used to do !!

That bamboo armour next to the double recurved bow on top of that fast pony !!

I haven't got anything against (good) frameworks, its all the damn crappy 'web-dev friendly' bloat-ware which people seem intent on basing these frameworks that pisses me off.

With all the 'green computing' buzz that is flying around at the moment, you'd think it might occur to someone that if instead of running away and hiding from the hardware, they actually use it in the way it was intended to be used, they might get a bit more bang for their buck. Anyway, that's an argument for another day.

Best Advice for Programmers Assembling/Building Projects .....KISS and Keep KISSing ...... and Servering to the Money Shot/the Glory Spot for that is both the Dumbest and SMARTest of Drivers even whenever the System is for Artificial and RobotIQ Use.

And should IT feel Threatened by Exposure/OverUse which is never Abuse, the SMART Money will always ensure that you are well Compensated and Tempted to come back for More, so that they can Give even More again ...and again ...and again........ with a Payment of Danegeld so that the Way can be Beta Prepared. Although that might be somewhat Alien in Concept to All, but those with some Viking Blood in their Veins.

Funny how there's a fairly large Java-hating community, but then there are some Java haters that also worship the "Ruby on Rails" bloatware. AFAIK, the first "enterprise-worthy" framework for n-tiered apps was J2EE; in fact so good that Microsopht went to copy it with its .NET thingy. And, you know, these are languages that actually *compile* code, even if it is bytecode (or MSIL for .NET).

It isn't just MVC, its security (which J2EE lets me do with the deployment descriptor stuff and role-mapping) and there are boatloads of Web2.0 dudes that don't watch out for this. This is why its so easy to find 0wned sites every now and then. That said, it seems Sun did something wicked on Java EE 5, as my precious Entity Beans have been slaughtered and everything's been turned upside-down. Oh well, at least my current job involves J2EE 1.4 so I don't have to worry about that ... yet.

That said, I might really prefer C/C++ webapps, but I have found nil documentation on how to even *compile* CGI stuff, and there is no real framework for C++, as all "teh kewl kiddies" are into other stuff and C++ isn't so "enterprisey".

<rant>

But then you wouldn't have all of these fabulous right out of the University developers creating entity classes irrespective of the DB. Then want to know why the DB is slow, why their Entity Manager is throwing an exception, why there are all these locking issues, key violations, why this worked faster in mySQL, what's an index, etc, etc.

Pray to the Oracle (tee hee) for the DB admin who needs to maintain a databse without knowledge of persistence APIs and how they interract with the database.

I could go on and on about this. Making classes relate to tables and relationships with annotations makes automatic code generation easy. Making code efficient and scalable? PAH!

</rant>

There are lots of C/C++ apps out there, some huge, some have been used, and expanded for many years, even decades.

How come C/C++ is adequate for projects from the small to the behemoth when it is for a desktop app or a non HTML spewing server app but not adequate for web apps?!

Is there something special about spewing HTML or one of its XML cousins that make C/C++ inadequate? (A PHP/Java/C/C++ programmer for server, desktop and web inquires)

Obviously! Mine's the one with the Railtrack logo..

You guys need all to lay off the coffee.

Now back to serious work (serious as in "Washington Post Serious", and the WaPo is a cheerleader for land wars in Asia, incidentally). Did I mention I work with Java?

Compiled web apps are nothing special. If you can do it in Perl (I'm showing my age there), you can do it in C. It'll just take you longer. Basically, you just need to be able to read environment variables and STDIN, generate output on STDOUT, and interface with files and/or databases. Access to libpcre is highly desirable, since most of what you will end up doing is text manipulation.

However, if your compiled program fouls up, it might take other things with it. Whereas if an interpreted program fouls up, it rarely takes anything but one instance of the interpreter with it -- and if it does, you can at least blame the interpreter.

"How come C/C++ is adequate for projects from the small to the behemoth when it is for a desktop app or a non HTML spewing server app but not adequate for web apps?"

- it is too difficult/expensive to guarantee that you have a secure application at a low level - this is not too much of a problem if you are Adobe rolling out an app that someone runs on a machine, but if you are on a volume e-commerce app, it's all to easy for a rogue C++ wizkid contractor on the take to spot flaws in the system and put together a component that to hijack and log valuable information stored in another part of the system.

With Java/.NET etc, it is much easier for a developer of a sensitive part of the system to take safeguards against this type of hacking.

Managed development platforms abstract you from the nuts and bolts, and reduce the number of trust issues especially when dealing with multiple teams developing a product for a large organization. Java / .NET etc free you from that.

For all but a small number of situations you'd be mad to go with C/C++ unless you opt for managed C++ - and even then you'd still be mad considering it will take an expert C++ programmer to write code that performs as well as an intermediate Java/.NET programmer.

I think these days, most desktop apps also have sizeable portions written in managed code - and with integrated development environments targeting both the web+desktop such as AIR and WPF - it seems if you value your career, best avoid the hippy code of Php, Perl, Ruby and the rest of the sandal wearing fad languages - these tools are free for a reason - they are developed so their inventors can charge Microsoft, Sun et al a fortune in consultancy so they can fast track their developers up to speed in order to evaluate the technology so they can nick the best of their features and incorporate them into their own products.

My name is Inigo Montoya. You killed my metaphor. Prepare to die!

He's absolutely right, I've yet to see a ruby on rails app which did anything particularly clever which couldn't have been done faster and just as easily using PHP and MySQL. And as for useability, do you really want to confuse your users by presenting them with some crappy interface your designers/developer thought was "cool" which take so long to load they bugger off to a competitor?

KISS is right, it always will be, and keeping to a standard interface makes your potential customers become real, paying customers.

"if you are on a volume e-commerce app, it's all to easy for a rogue C++ wizkid contractor on the take to spot flaws in the system and put together a component that to hijack and log valuable information stored in another part of the system."

Do you know of any cases of that happening, James?

"it seems if you value your career, best avoid the hippy code of Php, Perl, Ruby and the rest of the sandal wearing fad languages"

Any evidence for that, at all?

"these tools are free for a reason - they are developed so their inventors can charge Microsoft, Sun et al a fortune in consultancy so they can fast track their developers up to speed in order to evaluate the technology so they can nick the best of their features and incorporate them into their own products."

Any evidence, in particular, or cases of where that's happened?

...somebody can use language which isn't understood even by its developers (and with a stupid name to boot - Ruby on Rails is in the same line of names as Zero Cool and Acid Rain, i.e. teenage hacker nicks)

Why would anybody ever use a scripting language for anything besides text batch processing and starting up things is beyond me...

I have to say I have never understood why the world went Gaa Gaa for Ruby on Rails. Its just so slow and if you need to stray outside the framework then you have a lot of workaround coding to write.

I have found Python to be much faster, switching to Pythonic idioms increases the speed even more, and finally import psycho and go psycho.full() at the top of your code file and you are doing J.I.T. and just cranking up the speed like crazy.

I started with Ruby but switched to Python and have not looked back. I have scaled the build-in web servers in python web frameworks with Python written proxy load balancers and gotten terrific scaling from Python that leaves Ruby On Rails in the dust.

But alas, hey RoR has great marketing and they sold sand to the arabs so to speak. So who am I to complain? Just gives me an edge in my offerings over the RoR competition in the market place.

Peace out.

import antigravity

weeeeee!

Ahahahahaha!

While its market share may be dropping a bit, Perl does things pretty nicely still, despite a lot of the willfully obfuscatory coding that goes on (Mason is fixing a lot of that stuff).

As for the fact that web apps make lots of string manipulations and database queries (which are actually normally the slowest part), why on earth would you spend the effort coding in C, and then make calls to libpcre? There is a tradeoff between coding speed, performance, and maintainability - if your stuff is going to stay static for long periods, then not using a scripting language might make sense. However, since you'd be reinventing the wheel a lot of the time, it may not end up with any performance gains over say Perl/Mason or Python/modpython or Django.

Perl really is the beaten-up Transit van of scripting languages. Once you know how to start it, it just keeps on running. You get used to its odd behaviours (like the mid-stream syntax changes) and they become endearing. Drivers of newer, trendier vehicles may point and laugh, but they'll be laughing on the other side of their faces when you pass them as they're stuck on the hard shoulder.

And it's also on practically everything that sh is. (sh shouldn't be overlooked, either; it's a PITA to get at form variables, but if you just want to produce some output depending on the contents of files and things, it does that nicely.)

Oh yes, I may not understand Perl that much, but I definitely prefer Perl over Ruby on Rails anytime!

... and that's why I use RoR. 90% of the "anti" opinions here don't get it. It's quick, it has a low entry barrier, and, if you want the Ajax stuff, it's very easy to do simple things. If you want stuff that scales to the moon then you use a technology that will do that - d'oh!

Ruby has also got lots of nice utilities to do SOAP and so on. It just works and it doesn't hurt. Integration with other services (.Net or Java) is a breeze and you can get help really easily from other people in the community. In general there is only one way to do something (because the language is young) and it does what you want. Compare with Java - 25 frameworks with alpine learning curves (XML or properties files - let's have both!) before you can do anything. It *used* to be simple and pretty easy to get things done but the signal to noise ratio is really painful now and getting worse with every "improved" J2EE implementation from the big vendors. Me no want no stkinkin' entity beans - they leave a stain on your teeth.

I am a Java certified web developer and wouldn't go back, except for the cash. It used to drive me crazy: make a change, run Ant, deploy the WAR file, waste 20 minutes doing nothing. Get shouted at by PHB for reading El Reg while all this was going on. This is typical if you work on a legacy system.

Now I can just get stuff done, and that's all I want. I'm really keen on the whole JRuby thing, where the Rails app will just run from a WAR file and use all the sexy scalability stuff that the Java people have spent so much time and energy on - but I'll happily use it at one remove, thanks.

Sigh.

Forgot to mention the whole generating code thing - saves lots of time and energy. It's fundamental to the way Rails works.

Of course Perl's a hippy language - don't you know anything? The source code is full of quotes from "Lord of the Rings". Can't get much hippier than that.

Create, REPEAT, Update, Delete?

I don't think so.