Slashdot Mirror

Your cynical undertone that software only get slower and slower is not true. Firefox 4 *is* faster than Firefox 3. Haven't used Firefox 5 yet. Phusion Passenger 3 is 50% faster than Phusion Passenger 2.

and significant challenges making it play nice with Apache in a manner comparable to mod_php. (has mod_ruby come of age, yet? ;3)

Passenger is what you're looking for.

I don't know if I can really explain how a trigger file is hackish, if you don't see it already.

You're creating a file -- and with most filesystems, it's likely hitting a disk -- for the sole purpose of triggering a task. A task which, again, could have easily been launched by simply backgrounding something with whatever connection you had.

Maybe I'm just OCD, but that just seems wasteful and unreliable... I mean, there's going to be a delay, and some wasted CPU polling it, unless you're watching it with something like inotify.

The only case I can see where I'd prefer a trigger file is for things like Passenger, which is designed to bring Rails hosting to the level of PHP hosting -- that is, to a place where you could conceivably give someone something like FTP access (instead of SSH access). In such an environment, being able to touch a file is... still a brutal hack, but at least has a purpose.

And I kind of like daemontools in theory, but gave up on them after too long struggling with them in Debian/Ubuntu. DJB writes some good stuff, but it became irrelevant for the same reasons Minix did.

Well the deployment of Rails is getting easier every day. It now integrates nicely in your LAMP stack thanks to Fusion Passenger.
Or if you want more scalability, spead and general coolness you can use JRuby (with Warbler) to deploy a Rails application on a J2EE application server of your choice (e.g. Glassfish, Tomcat, Websphere). This also allows you to leverage technologies such as JMS or JDBC connection pooling from your Rails application.
Deploying Rails application has been a mess since it's inception, but with Passenger and JRuby we have two very mature options.

I always stumble across blogs with long explanations and tutorials on things so simple as *starting a service at boot* - and not even an arbitrary service, a common service like Ferret.

So what's Ferret or you inability to manage system services got to do with Rails ?

Not to mention that it's easy to do something idiotic in Rails. For example:

Orders.all.each { |order| ... code goes here ... }

With power comes responsibility - something you ought to know by now. You can do something just as stupid using _any_ other web framework + ORM; this is not a problem in Rails, it's a problem with the way you choose to solve the problem at hand.

Go guys! We're counting on you!

How about counting on yourself and getting some work done (on the Rails framework) without waiting for others to solve your problems ?

I'm writing a Rails application right now. It ran at 0.8 requests/sec in production mode. Then I spent 15 minutes on implementing fragment caching in my app, and my performance jumped to 40 requests/sec. And I'm not even done optimizing yet. Using Phusion Passenger and Ruby Enterprise Edition gives you additional performance boosts and memory reductions.

And it never claimed to be. I don't know anyone who uses Ruby because it's more secure. Everyone I know who uses Ruby does so because of the beautiful syntax, pervasive OO, and other things that make it nicer to program in.

And again, it's not the security. I'm willing to risk having to patch my interpreter like this once in awhile, if it means I'm able to

Keep in mind, this vulnerability is so far only a DoS, and won't necessarily affect most installations. Most people run multiple interpreters serving a single site, each load-balanced to. Knock out one and it'll be restarted, while the other continues to serve content.

Which brings us to your next point...

mod_ruby -- you do realize pretty much no one in the Ruby world uses Apache, right? It's all mongrels and nginx... But if you must, there's Passenger.

> I have dealt with deployment and scaling issues for a few years

What do you think of modrails? To me it changes the Rails deployment game entirely... no more mongrel clusters, no more complicated rewrite rules...

> and all I got was a pinkslip

You should have used modrails. Suddenly, Rails deployment is as easy as PHP deployment. I no longer hesitate to put up little toy apps since now I don't have to worry about mongrel clusters and init scripts and all that rot. Great stuff!

> I am no longer a Ruby on Rails fan as I have found
> more and more people complain about scalability.

Remember, languages (and frameworks) don't scale, architectures do.

> There have been numerous companies that have abandoned ship.

From where I stand there are lots of companies getting onboard, and modrails is a sea change (for the better!) in the Rails deployment story.

Speak for yourself. Many of we Rails developers would be a lot happier to see Twitter go, because that's the one app everybody points to when they need an example of a Rails app that has problems scaling.

RoR is my bread and butter, but I'm not one of these typical RoR fanboys who preach like Rails is the second coming of Christ, and will cure cancer while simultaneously letting you build the next Slashdot in five minutes.

You want the truth? RoR isn't suited to every task, and Twitter is a perfect example of that! We're talking tiny text messages posted to an account. Then you have the concept of followers. That's pretty much it. It's a bonehead simple service that's built around extremely high volume and relatively low complexity. This thing should have a C/C++/Java backend and a thin and light frontend, where Rails would likely have no difficulty filling the job. Neither would Django, or Cake, or the languages themselves (Ruby, Python, PHP, etc).

If Twitter ditches Rails it won't say a single thing about Rails' ability to scale beyond that it didn't work for them. What it does say is that choosing the wrong tool from the get-go is an ideal way to doom your app to having such issues.

I don't know how many times I have to say it, but Rails is still a baby in the grand scheme of things, and so is Ruby. There was a time when people used to joke about writing high-performance applications in Java, but those days are over. Why? Lots and lots of brilliant people came together to figure out how to make Java fast, and they've done a really great job. Anyone who thinks that Ruby's issues with speed and Rails' exacerbations of them is going to be a constant has made an error in judgment. Then again, you can't really blame them.

Said it before.. will say it again: people hate Rails because there are too many fscking Rails fanboys out there. Bad programmers who like Rails because it makes them look like stars. It makes those of us who take a practical and pragmatic approach have a rough time on sites like this. Anyone who's ever attended a RailsConf knows that there's a lot of enthusiasm, but the people who make it out to the conferences and pay their dues are - in general - very level-headed about what Rails can and can't do, and are actively working on solving those problems Rails has. Phusion Passenger (mod_rails) was born out of necessity, and I can speak from first-hand experience that it does exactly what it says.

Everybody take a step back and relax. You didn't hear this kind of bitching when YellowPages ditched their system to rebuild in Rails, and in case anyone hasn't noticed, they're looking to hire even more Rails developers. Oh, and they're doing a great job scaling. If Twitter ditching Rails is evidence of Rails' failure, what does YellowPages' success with it tell us? Or, for that matter, any of the other large and successful Rails apps?

FWIW, Twitter isn't *the* Rails app to most bonafide Rails developers. Basecamp is.