It is in fact easy to set up and maintain -- it just requires a bit more thinking, mostly to get the authentication and such things working right, but that's a matter of editing a config file. Maintenance wise, PostgreSQL doesn't need much of that, the occasional vacuum and that's it. With auto-vacuum enabled, even that is taken care of.

I used MySQL a lot in the past, and ended up going to PostgreSQL around version 7.3, because I needed the triggers and the views. Never looked back to MySQL, PG might be slower at certain things, but at least I don't end up getting a call at 3am in the morning in the weekend informing me the database crapped itself up again, only to have to wait for myisamchk to go through near 20Gb of data.

Give it a shot and you will be enlightened :)

I've been noticing the same trend for a while now, but on the other hand, if someone fresh out of college wants the perks, the travel, the cushy paycheck and so on, that's not necessarily a bad thing as long as they've set that for themselves as a goal to obtain. The problem lies with the bunch that wants to take a shortcut and want that stuff straight from the start. I've seen a few of those during interviews and actually explained that to them as the reason they didn't get the job.

The one I did hire also mentioned that he would like to be part of the team that deals with all the "cool" stuff, that gets to travel, gets company supplied phones and laptops, and gets that cushy paycheck -- except he said that that was a goal he had set for himself, and that he was more than willing to start at the bottom of the ladder - and that as long as the company treated him well, he'd to the same.

You're misusing the word "scalable". You probably mean vertical scalability, or performance. And it's not saying we don't know how to build a performant application. It's saying we don't care, because programmer time is more expensive than CPU time. It's simply not worth it to optimize past a certain point.

Which is exactly the attitude that's keeping things from scaling (regardless of whether I'm using this word in it's proper context, sorry, English isn't my native language) -- because you don't care, so why care at all about optimising when well, you can just throw more hardware at it? Sooner or later you'll be spending more on hardware than you are on programmers. Besides, programmers that do not know how to optimise properly should either quit the job or go back to school and study some more.

Citation needed.

Twitter.

Also, you are again talking about vertical scalability. Rails is actually excellent at horizontal scalability, which means, specifically, "Can we throw more servers at it and have it just work?" Not every PHP app can do that. Nor every Python, or Java app. However, unless you do something stupid, every Rails app can be scaled by throwing hardware at it. Keep in mind, you will have to do this at some point. No Amazon, or Myspace, or Google, is going to run off a single server, no matter how massive. They all have to scale horizontally. You have to address that problem sooner or later.

Scaling is scaling, whether it be horizontal or vertical. Horizontal scaling only gets you so far in the long run as well. Then again don't take my word for it but I've seen that same "oh well we'll just throw more hardware at it" solution blow up in some seriously interesting ways.

So, I'm arguing that horizontal scalability is more important than vertical scalability. Horizontal scalability means you can ultimately handle as much traffic as you can find hardware for. Vertical scalability means you save some money on hardware -- that's all.

Vertical scalability also forces you to know what you're doing when it comes to algorithms and such things. I know, I know, I'm probably a horribly oldfashioned cunt by saying it, but really, if you're going to build a car, you might as well build yourself a fast one instead of a 10 ton truck being powered by a 2 stroke 40hp diesel engine and say "well we can always throw more engines in here".

No, it's not, but it's still pretty damned good. Hype does not automatically make something a bad idea. Does anyone remember the hype about AJAX? I think most Rails hype is tame compared to that, but as it turned out, AJAX is pretty useful. It's not the Best Thing Ever, but it's still useful.

I'll admit it's good, but the problem comes from people who blindly follow the hype and will claim that RoR IS the best, and can do it better, and what the hell do us old Perl writing coots know anyway. I don't want to go and compare experience e-peens, but my comments on scalability are based on some interesting observations in the past.

If you can find where I've said Rails is the best thing ever, please, point it out. Otherwise, please try to reply to just my post, not every Rails developer ever.

Did I say you said rails is the best thing ever? I didn't. Why bring it up in the first place?

No, it's a framework based on Ruby, the language. Just as Catalyst is a framework based on Perl, the language.

Your point?

The idiom of "let's throw more hardware at the problem" is a way of saying "we don't know jack shit about how to build a scalable web application, so we'll hide the symptoms by throwing a bunch of additional hardware at it so it at least seems we can scale things".

Really, building a scalable web app is not hard, but if you're using Ruby on Rails, you're looking for a miracle since it's a known fact RoR doesn't scale very well. Other languages suffer from the same problem, except it seems those languages have more people using them that actually know what they're doing, instead of just following the RoR hype of it being the best thing since sliced bread, which it's not.

I'll take Perl and Catalyst over Ruby and Rails any day of the week. Ruby borrowed heavily from Perl, and managed to snaffle the rest of it's features out of Python, all combined into a very un-directed little language.