Hi, I am from Nepal. And my native language is Nepali.

If you say we all should have only one English language then I would disagree.

PHP is just a language.

Like anything else it depends on what the application is. There's a problem I've seen in programming -- and this goes back decades -- where newcomers and experts alike seem to think that every project should be done in one language. Not just one language, the one language they know.and favor. This is foolhardy at best.

It ends up akin to the man who's only tool is a hammer -- suddenly everything looks like nails.

PHP excels at one thing, being glue. It is IMHO the perfect glue between SQL and HTML, with its white-space neutrality, powerful string processing, character set and escape style juggling, and massive out-of-box function/object library very few other languages match up in that task.

The problems though are manyfold. People try to use it as more than that. They start slapping "template systems" on top of a language that's already a template system! (seriously, things like "smarty" are some heavy-duty derp), they start trying to do general compute tasks with it. They try shoe-horning programming models like MVC (ideal for event driven realtime UI's) into the language where it just doesn't fit the requests > process > output operation of the language. They try using double quotes for every blasted string, building strings when they should just be dumping to output, using string addition instead of comma delimits on their echo. They do really stupid things like put the SQL login credentials into DEFINE where they are undeletable and in global scope, just begging for a code elevation to pwn the entire process.

The language also has some real weaknesses; such as it blindly allowing you to include() any type of file and to readfile/fopen the source code files. This means with the inherent risk of code elevation common to all source-distributed interpreted languages leaves you with NO secure way to store things like the SQL creds short of actually disabling all file operations other than include/require. To the point the most secure approach is to run off at least two domains, one that handles all secure ops, and one that handles file ops.

But so long as you use it for what it excels at, you can most certainly scale it. In that way the question itself is somewhat flawed as to be frank scalability has little to do with the language being used. Scalling is about how to build and structure your program and not the language you wrote it in. To say that one language scales better than any other is pretty much nonsense, and those so claiming generally just haven't learned how to do it in languages other than the one they're hyping.

Bringing us full circle to what I started with. A lot of people will say things about a language they don't use; that it's dying; that it's outdated; that it doesn't scale. That's usually more rabid fanboyism or outright ignorance than fact. Either because what they're saying to use instead is all they know, what they learned first, or because they're just parroting what someone else said. That last part being the true power of propaganda, and how so many bad practices and worst choices get held up as the latest hot and trendy version of disco pants.

See all the things people are throwing node.js at of which it is completely unsuited; like outputting a normal everyday vanilla website.

If you are going to use PHP v3, they would be right. There is PHP7 now and it's pretty awesome. Again, it depends on what you mean by 'scale'.

In short ... that's not true. We can argue about memory consumption, data-structures etc ... but node and python are memory whores as well if we compare them to strong and static typed languages.

PHP can scale it just sucks at certain operations or applications. a message queue in PHP is possible, I wrote one with ticks and sockets, process forking and everything ... I just don't think it's nice to use and for what it does it's rather inefficient in comparison to go or node.

calculations are a pain, the memory consumption is sub-optimal but lets not forget the meaning of a dynamic and weak typed language with runtime type cohesions, as well as that those problems apply to every language within this domain.

I will not go into this any further because I think there will come some more concrete answers just don't forget people often confuse different types of efficiency. Often the boundaries of scaling are based on the implementation and architecture not the initial language the application is written in.

.... you can f*ck up in any language.