HN Explorer

Ask HN: Is PHP/MySQL Still Practical for Building Web Applications?

82 points by jakerocheleau ↗ HN
I ask because there are so many open source projects based on PHP code, but from what I've read RoR is faster and easier to work with. I'd like to get opinions on the matter to reference for future decisions in startup development

103 comments

[ 4.0 ms ] story [ 174 ms ] thread
michaelhart
While RoR is getting better in this respect, PHP is vastly better documented (both officially and all throughout the web) and the community is (at least, for now) superior to RoR. This is something that simply requires more time for RoR, as PHP has had quite a few years head start to get to where it is.

In practice, it honestly boils down to what you're doing and what's easier for you (and your team). If you want to test the waters, follow a few tutorials for each that you're unfamiliar with, and see what suits you better.

If you're using a shared server, you also have to make sure that your host supports RoR (most hosts don't). So that could be an extra expense to consider.

Me personally: I'm a php person. I prefer PHP + CodeIgniter, and I'm all happy :) RoR is fine and dandy, imo, but wasn't worth 9 years of PHP experience when PHP works amazingly well for everything I've ever asked of it.

byoung2
In practice, it honestly boils down to what you're doing and what's easier for you (and your team)

That's definitely a huge consideration, especially the team part. Plus, you're going to have a much easier time finding PHP developers than Ruby developers.

ibrow
Whilst you may have an easier time finding PHP developers I actually think it is harder to find good/great PHP developers in comparison with Ruby devs. The reason for this is that Ruby/Rails development seems to focus more on TDD, CI, logic/display separation and other good practices, where as PHP, being older, hasn't traditionally had this approach. Having these practices at the core of what you do (IMO) makes you a better developer (not necessarily programmer).
sanswork
It's hard to find good/great developers period and when you find them language is rarely a concern. It's easier to find PHP developers though and dispite wanting to you'll never get to staff your team with just great developers once you grow over a couple people.

Say you have a job posting and you get 100 php developers and 5 Ruby ones. Of those 5 ruby ones 3 will people people who watched the screen casts. 2 will be intermediate/senior. Of the 100 php developers 50 of them will be horrible. 40 will be junior level. 10 will be a mix of intermediate to senior.

(In my experience anyhow, my company currently uses primarily php for services and RoR for control panels so we hire for either and cross train)

ibrow
> It's hard to find good/great developers period and when you find them language is rarely a concern

Totally correct, however, with Ruby I think it's easier to find them primarily as there are less Ruby devs about, and using your example above, more or them are intermediate/senior (40% for Ruby, 10% for PHP). Then again intermediate/senior != good/great.

(Disclaimer: we're a PHP shop, but know a lot of really talented Rubyists)

sanswork
My point being that it's not easier to find them because there isn't as many of them available. The ratio may be better but the gross numbers aren't.
kaylarose
From my experience, a good way of weeding out the 50 horrible php programmers, is to ask about (even simple) OOP.

Then to differentiate Junior from Senior just ask them what testing tools they use (testing is not [as] ingrained in the PHP community [yet]). If they can talk intelligently about PHPUnit, mocking, etc. they are more than likely senior level, or at least passionate enough to learn more than most PHP developers.

cmelbye
I disagree with the documentation point. Type in any Ruby class whether it's a standard class, something from Rails, or a gem and you'll find a community run rdoc page with a ton of information on it.
josegonzalez
An rdoc is only as useful as it's included use-cases. About the best thing about PHP is the fact that there are zillions of included comments on the php documentation pages. While most are not at all what should run in production, a single good comment can give you a lot of insight as to how to use some code.

Tests != actual usage.

This is actually why a readme for a gem, plugin, extension, module etc. is so important, and why I think Github has been good for the developer community at large.

dangrossman
This has been my experience developing with PHP for many years. Especially in the early years, I found more code in the comments on PHP documentation than anywhere else (in documentation, on blogs, on Q&A sites). That the PHP community has always had this ability for its millions of users to aggregate code for common issues in one place makes its documentation much more extensive than it may appear at first glance.
ryan-allen
I've run server ops (and do development) for significantly loaded RoR and PHP applications (and still do), and I can say that there is more quality information available for RoR than there is PHP for setting up high scale and stable setups.

When setting up a RoR stack, all the information I needed was available, the infrastructure was pretty stable and was easy to debug problems. PHP on the other hand, had close to no information on dealing with high load. The optcache libraries are poorly documented, nobody is really talking about it, and running anything but Apache (for performance, of course) under fcgi was horrifically problematic.

In the end we had to write our own monitoring tools to deal with all the oddities we discovered with the standard fcgi spawner (there were many), and when trying to mitigate memory leaks we discover that there are 'many known leaks in the PHP stdlib, but that's OK because everyone runs short-lived processes and restarts them regularly so we don't need to fix them'. My idea of a robust (fcgi) server would be that it doesn't require constant restarts, but that's just me.

RoR is only one framework in the vast number of Ruby libraries. I have worked in both technologies and there are more well designed, useful and current libraries and tools surrounding Ruby than there are PHP.

Quite honestly I'm sick of people apologising for it and pointing to the 'big players in web' as proof that PHP is OK. In my opinion it really needs to go away. In the years I worked with it, it taught me nothing but bad habits. I'm not the only one.

EDIT: Two Ruby libraries I used recently that were very high quality were Nokogiri (HTML/XML parsing) and Typhoeus (HTTP library wrapping libcurl). I don't recall ever seeing anything like those in PHP that had such intuitive APIs. Can anyone provide any counterpoints of better libraries in PHP that don't exist in Ruby? P.S. Wordpress is not an answer.

jarin
I highly disagree that PHP has more quality information available than Ruby on Rails. Any time I've ever looked for anything on PHP all I get is ExpertsExchange quality (with the occasional gem on Stack Overflow), but a search for nearly any problem in Rails turns up a multitude of amazing blog posts, Google Groups posts, or gems that solve my exact problem. Failing that, IRC (or just digging through Ruby code which is easier to read than almost any language I have worked with) has been very helpful.
ryanto
It all comes down to the code. Good code in a bad language is better than bad code in a great language. The nice thing about RoR is it kinda forces you to do a few 'best practices things' so even newbie developers tend to end up with 'ok' code. Of course, there are many PHP frameworks that also apply this sort of way of coding.

Also, note that there will be a learning curve (probably small, but you will notice it) when you first start learning rails. Like all new languages, you'll overcome this eventually.

There is really no reason to choose one or the other. You basically already know the answer. Whenever people ask me this question I say 'What do you think the pros/cons are for each language?' and then right after they list them I say 'ok, pick one'. This is really not a subject worth dwelling on with established languages/frameworks.

PS: If it were me, I'd choose RoR :)

itsnotvalid
What's the worst is bad code in a bad language. Having a web framework would make things much more systematic, while raw speed is going to be a hit on (compare raw PHP with CakePHP 1.1, for example).
LeBlanc
PHP is not equivalent to Rails. It would be more accurate to compare PHP to Ruby and compare Rails to a PHP framework like Kohana.

I've worked with both Kohana and Rails. Rails is more popular so it is easier to find solutions and add-ons. However, it does a lot of things by 'magic' and a beginner will have a hard time modifying rails source or creating a gem (if they want to do something non-default). Kohana on the other hand is easier to understand, extend, and modify, because the entire source is in your project folder as PHP code.

Good luck!

prateekdayal
I have been doing RoR for over three years now and absolutely love it. A few things make it great

* The best practices are well documented and if you follow them, you are gonna end up with good code. Good code helps you iterate faster (and with more confidence) and thats crucial when building a startup.

* There is pretty good documentation available and tons of great books that you can read. Also with every release, it gets easier to do things in Rails. Ofcourse you should have test coverage to make sure that you can upgrade rails easily. This basically boils down to the first advice about following best practices.

Basically to get most out of rails, you have to buy their philosophy and follow the best practices. If you do, you can be assured of great productivity and programmer joy :)

morganpyne
Absolutely. The point has been made here already, but PHP + (Framework of your choice) + MySQL can still be used to produce great web applications quickly and easily. My framework of choice happens to be Symfony, but there are many good options. I also really like Compass for CSS and Capistrano for deployment (both borrowed from the Ruby folks) and that's fine too; they don't require any server-side Ruby support to be useful.

I would argue that a lot of the frameworks seem to be converging in ideas and functionality and borrowing heavily from each other, so whether you use PHP/Symfony, Ruby/Rails, Python/Django or whatever you probably will have more shared core concepts across them than differences. I think that a more interesting question would be "Is PHP/MySQL still practical for building web applications if I don't use a framework?" And the answer there is "that depends..." :-)

n-ion
there is another comment that speaks to this ("it comes down to code"), but i'd just like to say - use what ever you can to get the job done, then think about porting/optimizing/frameworks...

TO the question at hand - Yes - php and sql can get the job done... i mean are you building it for 1,000 users? or 100,000? php and sql can handle both...

Code tight and code well, tell everyone else to go to hell

TamDenholm
My personal opinion is that a project can be language agnostic. You can build in whatever you want. It doesn't matter if you build your app in php, ruby, python, asp or whatever, if you're a good coder you will produce good secure code, if you suck, so will your code.

So build in whatever you're most comfortable with and don't pick a language because of a superficial reason.

Loic
Maybe the best answer. I would just add, that if you need to integrate with a special system like an already existing business application, just be sure to have a supported set of libraries to access it from within your web application. This is the only constraint that would make me discriminate a language against another outside of the very good points of Tam.
xtho
There still is the question of how much time you're willing to spend to hunt down bugs in the interpreter/standard library/framework or to work around certain idiosyncracies that once upon a time might have looked like a cool idea. Will a "good coder" tolerate more or less such wtf moments?
thinkingeric
Build in whatever the people who are going to maintain it after you've moved on are comfortable with .... if you still bear some responsibility at that point.
Ramone
Isn't this the opposite of "pick the right tool for the job"? Building with whatever you're most comfortable seems to be a superficial reason. Different platforms/languages have real diversity in their strengths and weaknesses.
_b8r0
You raise a valid point if you're putting up a shelf. But if you're programming then you'll be at a disadvantage if you're not familiar with the tools at hand. Even a designer is going to suffer if they're made to use the Gimp when they're used to Photoshop, not because Gimp is or isn't a good tool but because the interaction is different.

Switching from Lightroom to Aperture I've noticed substantial differences in my photography, and I'm not a very good photographer. I'm considering switching back to Lightroom - I'm sure Aperture's great, but the learning curve is harder than switching from Vim to Emacs.

ulf
"It doesn't matter if you build your app in php, ruby, python, asp or whatever, if you're a good coder you will produce good secure code, if you suck, so will your code."

Can we please link to this in every new language discussion/flamewar?

blparker
I agree with this to a point. You should produce code in whatever language you are most proficient/comfortable with, pending that language is suitable for the domain in which you are producing code in. I wouldn't want to try to produce a web application in Assembly.NET, nor would I want to develop a low level component in Ruby. Depending on the domain, language becomes a bigger issue, which may result in you not having the ability to be language agnostic. But, in the overall sense, I do agree with what you're saying.
davidedicillo
It's about the developer, not the language. Just write good code and the language at the beginning won't really make a difference. If you like rails but you are more comfortable with PHP, maybe you could try CakePHP or Codeigniter. Even Python/Django could be an option you should consider.

Also for RoR you could use Heroku that makes deployment a breeze, but definitely when it comes to resources Ruby is way more expensive than PHP.

volkadav
I do have some future-direction worries about php (the 6 dev process has had some ... quirks; like "let's just bin this and start over") and mysql (re: acquisition by oracle and ensuing staff departures, forked projects, etc.). But they're still fine for a proof of concept implementation. Not many architectures survive contact with real use unchanged, so having to buttress (e.g. op code or data caching) or swap out components entirely is not unheard of. Sometimes the best way to understand a system is to build it, so even if you do end up rebuilding it in whole or in part, at least you've learned the hard lessons about how everything hangs together to make it work right.

PHP and mysql are dead stupid easy to get started with. An mvc framework like symfony/kohana/zend/etc. can help speed dev time for your PoC, but most of them are performance hogs so you'll probably have to buttress that (APC, memcache, etc.) if you do end up having to scale. All this stuff's widely supported and retarded easy to deploy usually.

RoR is a bit more of a moving target at the moment. Which means docs can/do lag the bleeding edge quite a bit, standard OS distribution packages are frequently out of date (or just out right retarded e.g. debian's disabling of rubygem self update), and the best practices for deploying and scaling are in a state of flux. (I think currently the recommended way is phusion's passenger/mod_rails or whatever it is, for apache/nginx anyway. Or has the state of the art moved on again?)

[deleted]
(comment deleted)
nessence
As for the title of your question, sure, PHP/MySQL are stil practical. If the answer to your question were no, then that would mean companies like Facebook and Yahoo aren't practical.

With regard to your future decisions, you might strongly consider another language and framework, not because one is more practical than another, but because the developers behind that framework may have more of a propensity towards the context of your startup. So, for example, Ruby has a large web application community, Python has a large scientific community, and Java enterprise.

The primary contention behind PHP has largely been it's limited OO and speed, as compared to it's brethren interpreted languages. You can, creatively, do advanced things in PHP which are done in other languages, but it's not as straight forward and often clumsy or not supported. That said, PHP is simple enough that large implementations can easily modify PHP for their own use; considering how slow PHP's codebase moves, forward compatibility is far less of an issue.

All together I wouldn't base your decision on speed. Computing power is cheap now and all of them are feasible as far as speed is concerned. If you need to build something NOW, strongly considering going with what you know. If you have more time, consider writing something cliche like a multi-user blog or twitter platform with each framework -- you'll be exposed to patterns you haven't seen before and can also figure out what you like and don't like.

jeffreymcmanus
If you are a software entrepreneur as opposed to an individual coder, one of the things you have to consider is how easy it is to hire someone who knows the platform or language you've selected. It's a fact that in the US and around the world, PHP developers outnumber Ruby developers by a significant margin, probably at least an order of magnitude.

In some ways, this may seem like an unfair comparison (by way of analogy, pedestrians outnumber drivers around the world as well). This doesn't address whether Ruby is "better" or not than PHP (or Smalltalk, etc.), it only has to do with what a startup engineering manager will have to contend with if an when your startup gets traction and you need to start hiring people at a particular moment in time.

adaml_623
But you have to ask yourself what your new hires are going to be bringing to your company? Are you going to be hiring dinosaurs or mammals?
jeffreymcmanus
I'm not sure what this means, but I think it reflects an incorrect bias that everyone you ever hire must necessarily be "plug and play". This assumes that humans are not educable which is not the case with the possible exception of certain conservative legislators.
dangrossman
You can just as easily say RoR is slower (than, say, Symfony 2.0 on PHP with an opcode cache) and harder to work with (from a system administration perspective).

Take a look down the top 100 website list, and of those sites that are web applications, more of them will be built on PHP than not. I don't think there's even a Ruby application among the top 100 sites except parts of Twitter, but I could be forgetting something.

- Facebook

- Yahoo! (Answers, Bookmarks, Delicious, etc)

- Wikipedia

- WordPress (.com application is #19, another 14 million active installs of the free software)

- Flickr

It may not be cool right now, but it's certainly practical.

anemecek
The problem with this argument is that all of the websites that you mentioned were founded before Ror or alternatives were mature enough. Adam D'Angelo (former CTO of Facebook) said that if Facebook was created now, they would not use PHP (source: http://www.facebook.com/note.php?note_id=137376312958147). I can imagine that the situation is similar with the other websites.
rimantas 

  You can just as easily say RoR is slower (than, say,
  Symfony 2.0 on PHP with an opcode cache)
You can say that, but is it true? I did not investigate it, but the last time I saw some comparison PHP frameworks were horribly slow compared to RoR.
michaelhart
codeigniter is VERY fast, and it doesn't get in your way. codeigniter is commonly referred to as the Ruby on Rails for php by some.
kemo
kohana 3 is more like RoR for PHP, CI is like RoR for PHP4 :)
ErrantX
Seconded, Kohana really wipes the floor with CI nowadays (this from someone still forced to maintain a couple of CI-based sites...) :P
kaylarose
I like Kohana much more than CI, if only for tossing PHP4 support.

However, but I've found that there is lots of fragmenting in the community/documentation. See the differences between 2.3.4 -> 2.4 (lots of breaking changes) -> 3.0 (almost entirely different framework). Which is kind of a bummer when using it for long-life projects (we have a few projects are stuck on 2.3.4).

That said - Symfony 2.0 looks fantastic, and very much like the next "Rails-like" PHP framework.

BBonifield
Exactly the same story here. Our primary product is stuck on Kohana 2.3.4 because of the lack of care that the Kohana team put into backwards compatibility. I wouldn't be surprised if they decide to essentially rewrite things again in the future either. If I could go back in time, I'd pick something else.
kemo
Kohana 2 was "just a php5 fork of CI", while Kohana 3 is practically a whole new framework. The "problem" is that Kohana team doesn't like handicaping new versions for sake of complete backward compatibility.

They just make the framework better with every new version, although in case of Ko3 minor versions are backward compatible (for example 3.0.8 with 3.0.1., but 3.1.0 will not be, at least concerning the response object and the ORM logics).

kaylarose
Yep. We are in exactly the same situation. Even moving to 2.4 looks to be a pain. The only brightside is that it's not THAT big of a framework, so patching it is not too bad. But still...
michaelhart
that's exactly why I'll never use Kohana. I will have to look more into Symfony, however, before I can accurately compare.
sanswork
I use RoR for all our control panels and human interfaces at work. RoR is many things but fast isn't something I would call it.
hallmark
YouTube was written in Python. Just wanted to add a unique (and possibly non-obvious) data point.
pbiggar
In a similar vein, Google is largely written in C++.
ldng
Originally AdSense too was Python/MySQL. Nowadays I don't know.
vital101
It's extremely important to draw a distinction between cool and practical. HN is all about the cool new hotness. People here are always on the bleeding edge of technology, so they tend to flock towards those instead.

Also, hiring PHP developers is easier than <insert cool technology here> developers. There are just more people with PHP knowledge. Not saying that is a good reason to use a language, but it is a factor.

yaubi
But when it comes to hiring _good_ developers, Python/Ruby/Lisp are definitely a better option.

In my experience, while it seemed at first that hiring PHP developers would be easier, it actually proved wrong, as we had to spend way more time to find _good_ developers among the mass than we would have if we were looking for, says, Python developers.

BBonifield
My personal opinion about this is that the better/more driven/valuable developers are the ones who are quick to try new tech and follow emerging trends. Many people know PHP, but I think you'd likely find better talent in the long run if you offer a position that uses a more exciting back-end.
TomK32
I'm in webdevelopment many years now and switching from php to ruby was a step I'll never regret. About the sysadmin perspective, I manage all my servers myself, used debian on my workdesk long enough to do this, and in the last year with all the stuff like bundler and the new rubygems.org it got so much easier. If you need it even more easier then Heroku is something you won't get elsewhere.
flacon
There are major Ruby Apps out there in the top 100: http://rails100.pbworks.com/Compete+Rankings

hulu.com yellowpages.com

also major sites: like justin.tv. slideshare etc

The argument that "Ruby cant scale" just doesn't hold. Check out Ruby EE by passenger.

makuro
These answers are all pretty long. The answer is yes, definitely, without a doubt. Practical means "for use in practice" and PHP powers a lot of your daily web applications, especially the simpler ones. Judging from your question text, at your skill level, PHP is sufficient if not ideal for development, deployment, and performance.

MySQL is also fast and easy.

sp4rki
A big part of the reason that many of the biggest sites websites on the net now are made in Php, is because it was the most viable and popular option 5 years ago. In that time both Ruby and Python have made leaps of advances in using their technology for web development. Now both languages are faster than Php, and in general the popular frameworks in this languages also preach better practices.

I worked with Php for a couple of years and I can tell you that I absolutely thought the language was a melting pot of some great ideas with a huge bunch of WTF form the very beginning. In my opinion Php as a language is archaic and the only reason to use it now is because it makes sense for your team (because that's what your team has experience with). That being said, a good developer gets great stuff out the door regardless of what language they use to do so. Hell one of best developers I know is a Php junkie - with whom I always ended up having a slight language war with. The funny thing is that even tough he was the strongest Php advocate I know, he is now using Python for everything and agrees that it's a much better language.

Now I work almost exclusively with Ruby for webdevelopment (and also for a big part of my server scripts now that I mention it) because it just makes sense. The code is a lot more maintainable and scalable, though this is because it's generally the case that out of a batch of Ruby developers you will probably get more 'good' developers than out of a batch of Php developers with the same amount of people. It's my experience that its easy to get 50 Php developers, out of which only a couple are actually good ones, while if you get 10 Ruby devs, at least half are competent.

This rant is getting long so I'll just leave you with a thought. If the only developers you can get right now are Php devs, it makes sense to do your project in Php; however, if it's possible for you to get your hands on some Ruby or Python developers, you really can't go wrong by choosing either over Php, specially since doing so will generally have the benefits of a faster, better, and more maintainable codebase.

qixxiq
I find the hardest problem to overcome with PHP is finding developers, as it isn't a particularly nice language to work with.

If you're not doing a computationally expensive startup, speed won't matter much. If you ever get to the size where it does (i.e. Facebook) - there are always solutions.

I've been seriously considering trying to start up an alternative language that takes the best parts out of PHP, but drops all the backwards compatible nonsense. It really has some great features but the annoyances will scare off most top developers - and you're left with a crowd of 85% script kiddies and only 15% developers that actually learnt to use the language properly... and trying to find one of those 15% isnt easy.

bilban
That would be Python!
joelhaasnoot
Launching a new site on the PHP/MySQL combo (with CakePHP as the framework) on monday so there better not be.

I do have to say, being a single coder/sysadmin/tech-cofounder, it has been an uphill battle and really it's a full-time job, but I make do with a couple of hours on the side as a student.

chriseidhof
I've built a large application in CakePHP (and had plenty of PHP experience before that). For most things, it worked well. Last week, I started doing RoR again (after a couple of years), and it beats the hell out of any other ecosystem for webdevelopment. Ruby is (for me) a much better language than PHP. I've done a lot of Haskell, too, and Haskell is even a better language than Ruby, but doesn't have the same amount of web developers.

What's nice about Ruby is that there is a huge ecosystem. Ruby on Rails is already very complete (especially compared to PHP). There are a lot of plugins for Rails that add the functionality you want. For example: adding image uploads (including thumbnail generation) was about 15 minutes of work, adding comments to my models too, and voting on models/comments was also done by installing a plugin. In PHP, there's a lot of code available, but most of it doesn't integrate automatically with other code.

I think that the amount of smart people that are working on a language/framework is very important. In Haskell, for example, there are not too many people working on web frameworks, and there's still a lot missing or broken. In PHP, there are a lot of people working on the language/frameworks, but a lot of the smart developers have moved to other tools, such as Rails/Django/etc. Therefore, I would just follow them and use a framework like Rails.

(A slight warning: this is all very subjective, this post is not based on any objective facts)

boundlessdreamz
slightly offtopic: What did you use voting/commenting ? When I last looked none of the plugins in that area were maintained
chriseidhof
One of my friends pointed me to this site: http://ruby-toolbox.com/, it's great for finding maintained plugins.

To answer your question: I used thumbs_up for voting, acts_as_commentable for comments, clearance for authentication and paperclip for file uploads.

I found thumbs_up before I knew of ruby-toolbox: I went to the acts_as_voteable github page, clicked on "Network" and scrolled to the right as far as possible. Most rubyists are very active on github, and a lot of the packages are forked.

boundlessdreamz
Thank you :) I was looking for something that integrates rating (not voting) and commenting in one package. I found this https://github.com/grimen/is_reviewable through the toolbox. But last commit is from 2009. Hopefully someone has forked it or I will have to fix it
xiongchiamiov
Abandoned gems is one of the biggest problems I have with Ruby. Rubygems is starting to look like CPAN, which makes my sysadmin life hell.
jasonlotito
I don't know. A lot of the smart PHP developers are still there. Maybe people using PHP moved on, but PHP devs are still strong.

As for PHP code, pear is still widely used for code distribution. Combined with pecl, and you have two resources for code distribution depending on how the code is integrated (PHP or C). And don't confuse pear as a library. It's a distribution method. For example, PHPUnit is installed via pear.

macco
PHP is totally fine. The question is more: Do you like, do you want to work with PHP, or do you want to work with Python, Ruby, Smalltalk, Lisp, etc.
jakerocheleau
By the sounds of it Python or Ruby seem to be the best options. I've done light PHP work for a year or two before but wouldn't say I'm an expert of any sort. Thus why I'm so open to switching into learning a more "modern" language
mojuba
One nice thing about PHP is that despite its archaism it keeps growing as a language. The 5.3 release alone added anonymous functions, namespaces, consts and many internal improvements. I recently rewrote one of my projects from the 4.x era for version 5.3 and found myself thinking that I don't hate PHP so much anymore. I still don't like it either, but at least I know the language is in good hands anyway.
xiongchiamiov
The problem is that they add them without breaking any backwards compatability, so you end up with unpleasantries like the \ namespace separator.
mojuba
On the other hand breaking compatibility the way they did with Python 3 is reckless. Ask someone who has a huge code base with, say, test scripts that do 'print' a lot if they are eager to switch to Python 3.
xiongchiamiov
That's an easy enough fix, and one that's handled quite well by 2to3. In fact, 2to3 handles most things, although there is of course some stuff that needs to be done by humans. But that stuff is certainly not 'print'.
jarin
Practical? Yes. Ideal? Maybe.

There are a lot of really good PHP developers around. But for ease of development and community support on a brand new project I'd probably go with Ruby or Python.

simonpreed
Use what makes you happy, building a startup will be have many more pressing questions than the choice of language. Trying to make sure you use a 'cool' technology is probably not going to worth the time.

Good luck.

scrame
I hate php, and don't really like mysql.

Yes. It is quite practical.

iampims
Build your webapp in a way where migrating parts of it to better suited technologies isn't impossible, and if/when you feel the need to migrate from PHP/MySQL, you'll be able to do so.