Y Ruby not PHP???

[MohsinAli]

I am a php developer since last 2-3 yrs.
Should I switch to Ruby?

Can anybody convince me...

[Fenrir2]

No. Just try it out and see if it suits you

[lo0ol]

It's pretty difficult to offer any suggestions without a bit about you—what type of projects do you work on, what development and production environment do you work in, do you enjoy the syntax of PHP, what really matters to you, etc.

[Koobi]

I've been a PHP developer for a couple years. I was convinced it was the best thing out there but I find I like Ruby better...but it's really a matter of taste.

What do you like most about PHP? See if similar things exist in Ruby.

One thing that makes me a little weary abotu RoR is how easy it is...you don't have to do much and that puts you in danger of becoming lazy...so if you do happen to switch to RoR, try and find out what happens in the background so that you have a good idea of what's going on because this will also make it easy to catch errors.

I've just started to learn RoR, got a long way to go myself

[Koobi]

I found this and thought you might find it useful:
http://www.jonathansng.com/technology/php-vs-rails/

[ParkinT]

I have been a PHP developer for 10+ years. When I discovered Ruby [on Rails], I became completely enamoured with it.
However, based on the project, I still use PHP. I don't dislike PHP just because I am in love with Ruby.
Software development languages are not like a mate; you are not expected to commit to only one!

[fLUx1337]

I've got to admit I am a one tooled guy, I go one way and make it work for my needs. Every web development project can be done in PHP and Ruby, as well as tons of other web languages, and while I agree sometimes a job can be done easier in one language, is it worth using that language for the whole project, just because it makes a single job easier for whatever reason?

Try it, if you like it, use it. If you keep wanting to go back to PHP maybe ruby isn't for you.

Just remember PHP isn't a god of languages and Ruby is just a follower of that god, they are both better than each other in one way or another...

[Anthony_c]

Same here, one-tooled guy, and I don't jump on every new thing that pops up like RoR. I choose to design my own frameworks on a per-site basis, but it works, and it's more secure then, say, certain bulletin boards *cough* phpbb *cough*. Also, recall that RoR's fundamentals spell DRYCoC....

Missing a K, perhaps? lol...

[Telmo Cardoso]

I'm a java expert and know some things on PHP. I already payed for an intensive training I'm making this month on RoR.

My question is, I know RoR is all about saving time, frameworks embeded, etc.

But its supported my some hosting companies? It wont take to long to read a page made in RoR compared to PHP or even JSP? Cause if the intention of RoR its only save time to coders I think I prefer to deliver in more time but more perfect jobs (mainly quicker to generate ones).

Thanks

[sbauer]

I'm a java expert and know some things on PHP. I already payed for an intensive training I'm making this month on RoR.

My question is, I know RoR is all about saving time, frameworks embeded, etc.

But its supported my some hosting companies? It wont take to long to read a page made in RoR compared to PHP or even JSP? Cause if the intention of RoR its only save time to coders I think I prefer to deliver in more time but more perfect jobs (mainly quicker to generate ones).

Thanks

RoR is supported by quite a few hosting providers. However, when looking for hosting, you will need to read the fine print. You need to figure out how much allocated memory they give you for Rails hosting. Currently, the recommended deployment/hosting approach is Apache set up as a proxy to forward requests to a cluster of Mongrel instances. Mongrel is a HTTP server written in Ruby that's designed to handle Ruby coded apps. Now, those Mongrel instances take up memory and the more instances you have (I would imagine most sites start with three) the better your site will run.

You could also use Apache with FastCGI hosting as an option, but the Mongrel cluster is recommended.

Recently, a company developed mod_rails, an Apache module that makes Rails deployment a breeze. I've never tried, but from what I've read deployment is much better and server setup time was dramatically reduced. A few hosting companies are either supporting it or running a public beta program.

Deployment in Rails isn't one of its finer areas.

What do you mean by "It wont take to long to read a page made in RoR compared to PHP or even JSP?" Are you talking about readability, performance or something else? In Rails, you don't really have pages. You have controllers and views. You'll see that in your training, though.

[Telmo Cardoso]

Hi, thanks for the reply on that last part I was talking about the quickness of the pages showing to users.

I have sites that when page takes long that 0,5s users start to complain

[sbauer]

Hi, thanks for the reply on that last part I was talking about the quickness of the pages showing to users.

I have sites that when page takes long that 0,5s users start to complain

Yeah, that depends on a lot of things, though. Ruby and Rails performance is one thing, but you also need to consider your server, and media resources (images,css,javascript).

As far as Ruby/Rails performance, there has been a lot of talk about that. Your best bet would be a search on Google.

[lo0ol]

But its supported my some hosting companies? It wont take to long to read a page made in RoR compared to PHP or even JSP? Cause if the intention of RoR its only save time to coders I think I prefer to deliver in more time but more perfect jobs (mainly quicker to generate ones).

As sbauer mentioned, the hosting climate for Rails gives you many options. Deployment on Rails is miles ahead of where it was just a year ago now. In terms of performance... I think at this point I don't think language speed is too big of a deal. Ruby's expressiveness does put it at a disadvantage for performance on a strict technical level, but in all honesty you'd be way better off at optimizing on the application level: caching, optimizing your queries, and then going back and repeating those two steps in perpetuum. For the vast, vast majority of web apps you're going to hit much larger bottlenecks by running crappy SQL queries than you would by how fast Ruby reads in a regular expression, for example.

The old adage is usually still relevant: development time is more expensive than processing time.