PHP 7 Virtual Machine(nikic.github.io)

365 pointsby lvhtقبل 9 سنوات125 comments

nikic.github.io

http://nikic.github.io/2017/04/14/PHP-7-Virtual-machine.html

126 comments

donatjقبل 9 سنوات

It's always pleasant to see PHP occasionally get a positive moment in the limelight on HN. It's oft scorned yet powers a very large chunk of the web. With the work done on 7 it's also one of the fastest scripting languages around and deserves a little more credit if I'm honest.

aphextronقبل 9 سنوات

It has come a long way. My last job was at a big PHP shop, which had a heavy focus on doing PHP The Right Way. The result was a fairly decent, maintainable codebase. I came to really appreciate the flexibility and ability to just "make things work" that PHP has, while finally having a proper development environment with real dependency management and IDE support.

david-givenقبل 9 سنوات

Do you have any pointers to the recommended Right Way to do modern PHP? I'd be interested to explore it; I have a number of places where I want to add tiny bits of interactivity to otherwise static web pages, and this totally seems to be what PHP does best.

Mahnقبل 9 سنوات

http://phptherightway.com is a good place to start, if you haven't read it before. It's opinionated, and not necessarily a guide follow down to the letter, but it can put you on the right track.

david-givenقبل 9 سنوات

Ha ha --- I should have thought to search for that!

It seems to be a bit light on advice in places. e.g. the section on comparison operators lightly mentions the difference between == and === but doesn't say anything about when they should be used. As that's one of the traditional PHP gotchas I would have expected more there.

Anyway, thanks; I'll check it out.

jdpedrieقبل 9 سنوات

http://www.phptherightway.com/

matthewnقبل 9 سنوات

O'Reilly's "Modern PHP" (270 pages) is a fantastic introduction to the new way of doing PHP.

Sunsetقبل 9 سنوات

What was your IDE of choice at that shop?

Seldaekقبل 9 سنوات

I think PHPStorm from JetBrains is the IDE of choice of most PHP devs using IDEs at this point. They completely own the market, and rightfully so (I'm still stuck on Sublime Text myself, but wouldn't consider any other IDE than PHPStorm if I were to use one).

Aeolunقبل 9 سنوات

How are you stuck on Sublime Text?

aphextronقبل 9 سنوات

PHPStorm all the way. It integrates perfectly with Xdebug and you end up with an environment almost as good as Visual Studio or Eclipse debugging.

malzaقبل 9 سنوات

Honestly. I think its main problem is it's not hipster enough. It's too popular. I bet if you made it difficult to use (for most people), added features that make certain aspects a nightmare to scale and gave it a weird name then it would do well here. Obviously don't let anyone know about the origin... say you built it at a series of obscure coding bootcamps.

simiasقبل 9 سنوات

I think that's unfair, the reason PHP has a bad reputation is not because of silly hipsters. It's because for a long time it was a terribly designed language. It was a laughing stock for a good reason. The whole "hobby-grade templating language turned general purpose with complete disregard to how programing languages are designed" thing.

Now I'm willing to believe that it's improved a lot since then, but it's got a very bad reputation to overcome, and it's deserved. The languages seems headed in the right direction at least, maybe in a few years we'll forget what PHP used to be.

drspacemonkeyقبل 9 سنوات

I'm pretty sure a substantial part of PHP's reputation is the nightmare code produced by PHP developers.

cr0shقبل 9 سنوات

And that goes right into the whole "badly designed language" trope as well. Essentially, anything written in PHP prior to version 5 (and especially prior to version 4) should be considered suspect.

I'm a long time PHP developer (well, was until recently - my current position is in the javascript/nodejs stack arena), and have been using it since the v3 days (so not there from the beginning, but close enough). There were some truly awful examples and code practices out there.

That isn't to say you couldn't write quality procedural PHP back in the day (had you configured your server properly and stuck with "best practices") - it's just that the majority of people hacking on PHP didn't. I'm sure there were a few that did, though - but I'm hard-pressed to recall any at the moment.

Today's PHP is a much different beast than yesterday's. The OOP model and other advancements makes things so much better, provided they are all used properly and followed. Now - could you make PHP 7 as ugly as 3? Sure. But you'd be insane to do so unless you had no other choice...

drspacemonkeyقبل 9 سنوات

Nail, meet hammer with claws on both sides.

It's entirely, 100% possible to write good, clean, tested, maintainable code in PHP. But most people working with PHP, for whatever reason (and I'm sure there are many reasons), simply don't bother.

I suppose the same can be said of all languages, but PHP devs are the worst offenders IME.

nerfladقبل 9 سنوات

Agree with you, and let's not forget that JavaScript has similar origins.

Aeolunقبل 9 سنوات

Lets not forget that Javascript still has a lot of the issues that PHP has now finally overcome.

tangent128قبل 9 سنوات

I haven't touched PHP in years, but I am hearing it's supporting stricter type checking, which is promising.

amiga-workbenchقبل 9 سنوات

You hit the nail right on the head there.

Some of the nightmarish build configurations to get some Javascript projects going are just beyond belief.

nilliamsقبل 9 سنوات

It's unfortunate if you've encountered that because there's really no good reason for it. Thankfully now however most/all major JS frameworks & libs are moving to/have moved to 'zero configuration' cli tools (ember-cli, create-react-app, angular-cli, ...).

root_axisقبل 9 سنوات

> I bet if you made it difficult to use (for most people), added features that make certain aspects a nightmare to scale and gave it a weird name then it would do well here

This is the same quality of vapid criticism that is often levied against PHP, just in reverse, all that's missing is a link to a 'fractal of bad design' type of post. I'm guessing you're going to try and justify your comment with some version of "well my criticisms are actually valid", but hopefully I'm wrong.

Piskvorrrقبل 9 سنوات

Mind you - that article is from 2012, and was valid criticism. In 2012. Quoting that today would be similar to "HURR DURR IE8 SUCKS COMPARED TO CHROME 57" ;)

Terriblehnقبل 9 سنوات

mawقبل 9 سنوات

On the contrary, I dislike PHP because I find it so difficult: its bad documentation, its badly designed standard API, the many badly designed and badly documented frameworks to replace the badly designed API, and the core language that goes out of its way to let buggy code through all combine to make writing medium-sized and above programs extremely difficult.

Supposedly it's better now. I'm skeptical.

Severianقبل 9 سنوات

I haven't used PHP for a number of years, but I have to disagree on the documentation. I found PHP's docs to be heads and shoulders better than other languages. It has expressive, sane examples, and allows comments that may help others with repeated questions regarding certain functionality.

Compare PHP with say, Python. Tell me which one you would rather refer to.

KingMobقبل 9 سنوات

I'm with you on most of these, but disagree on the documentation. The main PHP code is quite well-documented, even from way back, which contributed to its popularity.

styfleقبل 9 سنوات

The docs are great--its the API that is badly designed in my opinion. It's not very intuitive or memorable. Take a look at string functions[1] for example. `count_chars` vs `strlen` and the list goes on.

[1]: http://php.net/manual/en/ref.strings.php

hliyanقبل 9 سنوات

I wholeheartedly agree. I've seen many cases of PHP being scorned in favour of Node.js in problem domains where PHP is a clear fit (I've been guilty of this myself). It's not at all a bad language in the hands the right person.

Dibesقبل 9 سنوات

out of pure ignorance -- what are the correct domains that either fit into?

tannhaeuserقبل 9 سنوات

PHP started out as a language you could embed into otherwise static HTML via SGML processing instructions. While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can't escape the strings it injects into HTML - it's trivially easy to build a PHP app taking user input where the user sends malicious <script> tags and PHP placing it happily into generated HTML (eg. XSS attacks). PHP apps typically also build up dynamic SQL from user input by string concatenation, which has resulted in uncountable SQL injection attacks. PHP apps and frameworks like WordPress and Drupal initially have worked around these limitations by using ad-hoc measures, then grew into meta site template engines and generators themselves, resulting in code bases without much architectural oversight. These dangerous properties, and PHP's really bad standard library, in combination with PHP being used as a beginner language for web sites, have resulted in PHP's bad reputation. Since experienced developers have avoided it, PHP also has a bad presence at StackOverflow, which contains thousands of low quality answers answers to PHP questions.

On the plus side, PHP really owns managed hosting. You can install WP etc. via "panels" even without any admin experience and go from there by installing a mess of "plugins" and "themes" (which, due to lack of modularity, can do all kind of things to your site).

Node.js generally requires your own VM (there is no managed hosting) and due to it being run in a single process (or process cluster) generally requires that you know what you're doing so that a single error doesn't bring down your whole site. Its attractiveness comes from the fact that you can use JavaScript both server- and client-side (unlike PHP which runs server-side only). While Node.js has the edge in web apps, the options for content-driven sites are limited on Node.js; there's nothing like WP or Drupal for Node.js, and some say Node.js also lacks a canonical framework for rapid creation of database-driven web apps such as Rails or Django.

sbarreقبل 9 سنوات

> While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can't escape the strings it injects into HTML - it's trivially easy to build a PHP app taking user input where the user sends malicious <script> tags and PHP placing it happily into generated HTML (eg. XSS attacks).

> PHP apps typically also build up dynamic SQL from user input by string concatenation, which has resulted in uncountable SQL injection attacks.

You can make these beginner mistakes in any language that outputs HTML to the browser, and accepts user input via the browser.

I'm not specifically defending PHP here, but I hope you're not implying that these problems don't exist in Ruby, Python, Java or even Node for that matter...

The issues you are describing are unsafe coding practices and have nothing specifically to do with how PHP works, and it's "trivially easy" to make those mistakes in almost all web programming languages.

It's also not true that PHP "can't escape the strings it injects into HTML". There are standard library functions to do this (and have been for probably 10+ years, since the late PHP 4 days), as well as many well-tested community packages to do this at the framework or application level.

Also your explanation of "plugins" and "themes" is a concept tied to applications such as Wordpress, Joomla, and other CMS products (and again are not concepts specific to PHP).

It's certainly true that PHP's low barrier to entry has led to many badly coded websites getting onto the Internet, but I think it's ignorant to claim that PHP can't be used correctly and safely to develop web applications, or that most of the problems you describe are not easily avoidable.

All languages and frameworks have their pros and cons, and their caveats, but it helps no one when people spread FUD and outdated (or straight-up false) facts about web development.

Whether you code in it or not, you should probably refresh your knowledge of the PHP language and ecosystem if you're going to make public statements about how it works and what it can and can't do.

jeltzقبل 9 سنوات

Of course you can write safe code in PHP, it is a complete general purpose programming language. But just like one can blame C's design and standard library for many security bugs I also think it is fair to blame PHP's standard library and design.

For example PHP's PDO library makes it less convenient to supply parameters to a query the safe way than it is to do it the unsafe way. This is not necessary as can be seen from the excellent Ruby library called Sequel where it is just as easy to do things the safe way.

Another example is PHP itself being a template language, but which lack of automatic escaping makes it very dangerous to use. Since just one missing escape call in the wrong place can fuck up your day. To be fair PHP is not the only one who has fucked up here. This is also an issue with Ruby's ERB templates in the standard library, but fortunately Rails has added automatic escaping to its ERB templates.

One important thing about designing safe software is to make it easy for the end users to do things the right way, and here I think PHP has done a pretty poor job.

Prefinemقبل 9 سنوات

I would say it's unfair to compare a library to the basic PDO. If you want to compare apples to apples, try looking at Sequel versus Doctrine or some other third party SQL library.

Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache. But you don't have to use it that way, and probably shouldn't. While PHP started as a template language, it has clearly moved past that.

jeltzقبل 9 سنوات

I do not think it is an unfair comparison since Sequel has both basic parts on the same level as PDO, and then implements the more advanced features on top of these basic parts. The basic parts of Sequel has superior usability and safety to PDO.

Sequel's right way:

    user = db['SELECT name FROM users WHERE id = ?', id].first

Sequel's wrong way:

    user = db["SELECT name FROM users WHERE id = #{id}"].first

PDO's right way:

    $stmt = $db->prepare('SELECT name FROM users WHERE id = ?');
    $stmt->execute([$id]);
    $user = $stmt->fecth();

PDO's wrong way:

    $user = $db->query("SELECT name FROM users WHERE id = $id")->fetch();

As you can see PDO is optimized for doing things easily the unsafe way while Sequel has the safe way as the normal way of running queries which is just as easy to use as the unsafe way.

> Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache.

That is simply not true. Look at Twig which by default escapes everything automatically, or Rails's patched ERB which keeps track of escaped an unescaped strings based on data types and makes sure everything is automatically escaped in the end. In those template languages you need the explicitly do something unsafe to get an unescaped value. While in PHP you need to audit all places where echo can be called directly or indirectly.

Prefinemقبل 9 سنوات

Okay, so instead of Doctrine, look at another library that has the basic parts and then the advanced parts. Here is one from a different library that is safe and "easy"

    $user = $db->find('user', 'first_name = ?', ['Name']);

> As you can see PDO is optimized for doing things easily the unsafe way while Sequel has the safe way as the normal way of running queries which is just as easy to use as the unsafe way.

PDO isn't "optimized" to do them the wrong way or the right way. Yes, it's less code to do it the wrong way, but that isn't a true definition of easier.

As for the escaping, I would expect Twig to escape things, it's want it's meant for (and the reason you use it instead of just vanilla PHP). And Rails is a subset of Ruby correct? So not a true comparison again.

CiPHPerCoderقبل 9 سنوات

Compare Sequel to EasyDB then: https://github.com/paragonie/easydb

jeltzقبل 9 سنوات

Sure, I know there are good libraries for PHP, I mentioned Twig for example, but my issue is that the standard library of PHP is shitty and contains traps for beginners.

Prefinemقبل 9 سنوات

Honest question, is Sequel a standard library for Ruby? I assumed it was something you had to install after you installed Ruby.

sbarreقبل 9 سنوات

Most languages let you cut corners and code in a sloppy way. This is not limited to PHP.

I think anyone can show anecdotes to support "coding in [language you don't like] is bad".

Replace "unsafe" with "non-performant" and go back to early Rails days and you'll have plenty of examples where naive framework implementation led to programmers shooting themselves in the foot with the "easy way" in a different context..

Like I said, all languages and frameworks have their caveats and learning to code properly is the developer's job, and the "right way" or "best way" is often a work in progress that evolves as the community develops best practices..

jonkneeقبل 9 سنوات

> Most languages let you cut corners and code in a sloppy way. This is not limited to PHP.

Completely true, but for years PHP made it extraordinarily easy to shoot yourself in the foot right out of the box. register_globals for example...

http://php.net/manual/en/security.globals.php

Revisorقبل 9 سنوات

Deprecated 9 years ago.

marcosdumayقبل 9 سنوات

It's not what you can do, it's how hard it is.

Just try pulling data from a database and inserting it into a page on a way that is vulnerable to XSS in Django, Jinja, or Rails. You obviously can do it, but I bet you'll need to spend half an hour reading the documentation before you succeed.

The same happens for SQL injection, and session management issues, and a huge amount of other problems.

tpetryقبل 9 سنوات

The fault in your argumentation is comparing a language (PHP) to a framework (Django, Jinja, Rails).

Your argument is valid too for any PHP framework, it's hard to do XSS in laravel, symfony or zend framework.

Joeboyقبل 9 سنوات

PHP is a web framework. It's just one that requires another framework on top to mitigate its shortcomings.

Prefinemقبل 9 سنوات

I use PHP quite a bit outside of the web.

I think tpetry was pointing out the difference between a language and a framework built on that language.

(Replace language with whatever you think it is, it's still a subset just like Ruby on Rails is a subset of Ruby)

tannhaeuserقبل 9 سنوات

Sure you could separate PHP the language from PHP the processing instruction and PHP the standard lib. But PHP calls itself a "hypertext preprocessor" (it's in the name) and PHP's own intro (literally on page 1, sentence 1, cf. [1]) advertises web templating as its distinguishing feature. So I think it's fair to compare PHP against other HTML generators.

[1]: http://php.net/manual/en/intro-whatis.php

Prefinemقبل 9 سنوات

So, regarding the parent, I was pointing to PHP being more of a language and less of a "web framework" which I don't believe you address at all. As for web templating and such

> PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.

I would focus on the core statement of the sentence which is "is a widely-used open source general-purpose scripting language". Comparing PHP to other HTML generators (re re re? parent: Django, Jinja, Rails) leaves out the entire concept of "general-purpose scripting language" and only focuses on "embedded into HTML" which while a main feature isn't the whole of it.

Joeboyقبل 9 سنوات

And I'm pointing out that treating PHP as a framework is not a "flaw in argumentation". The default installation of PHP gives you a setup that parses HTTP requests and returns HTTP responses, and provides a bunch of web-centric functionality in between. ie. it's a web framework, albeit not a very good one.

Prefinemقبل 9 سنوات

> The default installation of PHP gives you a setup that parses HTTP requests and returns HTTP responses

Correct me if I am wrong, but so does Node, Ruby, Python, etc...

Sure it was built for the web, in simpler times, but everything has to start somewhere. Now days, PHP is a completely different beast.

> Just not a very good one.

An opinion if fine, but it seems like you are deriving this opinion from old experiences (or maybe the old PHP hate bandwagon)

Joeboyقبل 9 سنوات

> Correct me if I am wrong, but so does Node, Ruby, Python, etc.

I think Node is also a framework, although there seems to be some controversy about this[1]. Ruby and Python give you standard libraries from which you can build a web server or templating engine or whatever, but it would be weird to say that made them Web Frameworks. Maybe things have changed, but last I knew PHP had a command line switch that tells it to not act like a web framework, because that is its default mode of operation. But you're right that it's been a few years.

I don't think I'm jumping on a hate bandwagon, but I am succumbing to someone-is-wrong-on-the-internet syndrome, which I know to be a mistake.

Although I can't resist asking - are you saying PHP is a good web framework? How does that fit with the idea that PHP is not a web framework?

[1] https://softwareengineering.stackexchange.com/questions/2991...

marcosdumayقبل 9 سنوات

You would have a point the frameworks you provided had that kind of protection by default (or if you could at least enable it project-wide), and if PHP development were mostly done on them, instead of wordpress and drupal.

Besides, there's more to security than SQL injections and XSS. The PHP tooling is overflowing with bad practices.

tpetryقبل 9 سنوات

Take a look again. Each of those Frameworks is using a template engine which is escaping any ouput by default. If you do not need escaping, you have to opt-out for single outputs.

tannhaeuserقبل 9 سنوات

Reading through it, my comment came about too much as a rant against PHP, though I actually like parts of the PHP community for their sense of practicality.

I know there are libraries for HTML escaping, but I stand behind my statement that PHP's lack of HTML escaping is a fatal and unforgivable (almost criminal) design flaw when PHP's original use case, and distinguished feature vs. other general-purpose languages is dynamic HTML templating. In my opinion, PHP has gone the "get something quick out there and fix it later to become the dominant web runtime" route (which kind of worked), but without doing the actual hard work, and as such deserves to be called out.

sbarreقبل 9 سنوات

You're calling out problems that are common to all programming languages on the web, and I think you're just focused on PHP because it was one of the first languages to run into those problems (and to solve them as well - HTML escaping functions are part of PHP's core, it's not a library) due to it's early widespread popularity and adoption.

Trailblazers often bear the brunt of learning through trial and error, and later adopters benefit from all those lessons learned. This includes the PHP language and ecosystem of today, that looks nothing like what you describe.

Also: show me a popular web programming language that prevents the problems you called out (at the language level, not the framework level). You can output unescaped input, or create SQL injections, in any language if you don't know what you're doing, or if you're using the wrong tools.

Again if you want to keep speaking on the topic, I encourage you to refresh your knowledge on the PHP programming language (and probably also on web development in general if you think other languages don't also have the same pitfalls).

Your concerns and opinions are literally 10+ years out of date.

bpicoloقبل 9 سنوات

> show me a popular web programming language that prevents the problems you called out (at the language level, not the framework level).

Golang? https://golang.org/pkg/text/template/

ssharpقبل 9 سنوات

PHP made it way too simple to go from a basic installation -> serving web pages, just using it's standard library. You're right -- that was it's intended use-case and while it made for a dead-easy user experience, it also planted lots of traps that users fell into in droves.

Where languages like Ruby had Rails and Python had Django, PHP was able to do things quickly without having a framework on top of it. That, coupled with clear design flaws and a standard library that lacked, well, standardization, made it an easy and deserving target for criticism. PHP was also slow to adopt objects, namespaces, package management and other things developers came to expect.

t0mislavقبل 9 سنوات

I agree! 6 years ago when I started with web, as a total newbie, decision was to use Ruby on Rails. I gave up after day or two, I didn't understand how to start with this thing. And I was pissed of. Then I wrote few lines and save it as .php, upload to hosting which I already had, and things worked. I'm still using php to this day.

mschuster91قبل 9 سنوات

nodejs is imho best suited for two groups of tasks:

1) APIs/programs relying on high concurrency and parallelism, especially where the handler(s) have to wait a lot for stuff like DB accesses

2) streaming (in the sense of websockets servers), PHP iirc can't even be used as a websocket server

3) Any API that can be implemented without needing too many async calls - you'll end up in callback hell or promise hell otherwise

PHP on the other hand has other use cases:

1) stuff that needs to be massively and easily deployed - you can grab PHP/MySQL/Apache hosting everywhere for either dead cheap or totally free. Examples include Wordpress, Drupal and MediaWiki

2) stuff that is highly complex in its flow. If your API requires dozens of DB calls, filesystem access, networking or just involves thousands of SLOC, you're better off writing it in PHP as it (since PHP5) carries a solid OOP stack - and even if you're not writing OOP code, being able to write program flows without dozens of promises is a breeze.

3) stuff that requires weird extensions to PHP. Basically there are bindings for everything and it's trivial to write your own binding to a library if it does not exist yet. For example, I have used PC/SC to interface with crypto smartcards, and it works surprisingly well.

4) shell scripts. PHP interpreters are widespread - OS X includes PHP by default and it's a $package_manager install php away on most Linux distributions. Perl and bash have their own strengths but honestly, Perl is outdated and PHP abstracts a load of stuff away, so you can write shellscripts that work on all major platforms without having to account for stuff like "does the OS have GNU grep, busybox grep or BSD grep".

stabblesقبل 9 سنوات

There is a project called ReactPHP [1] which provides a nodejs-like event loop and async execution.

However, I think the power of PHP is that it is not designed to be its own server, to run forever in the background and handle all kinds of complex async flow. Execution stops when a request is done: no memory and data leaks between requests and easy to reason about.

In practice you don't really need async, except for stuff like sending emails and heavy IO. Laravel simply handles this by pushing jobs on a message queue and handling it via a worker process, but you can use any microservice of course (in particular a simple node app).

[1] http://reactphp.org/

robryanقبل 9 سنوات

I am by no means an expert on the subject but use Ratchet (http://socketo.me/) with proxying through nginx for my limited websocket needs. Works well.

em1tقبل 9 سنوات

I've only tried Ratchet in a sandbox and not in any production project. And as far as that, it worked well. I've done some minor stuff involving ReactPHP (which Ratchet uses for some parts) in the early days of the project, but same here - nothing that was deployed to production.

I'm no expert either, but I just leave a note regarding Pushpin (http://pushpin.org/) here as an option to have a websocket server together with PHP. It's not a PHP project, but a good tool to have in the toolbox :)

vgy7ujmقبل 9 سنوات

Perl is WAY better for shell-scripty stuff. It also has yearly releases and backwards compatibility is much better than for PHP. I think YOUR perception of Perl is what is outdated here.

And come on, for "job control" type scripts you should be fired for using PHP over Bash. Most things can be done in 1/10th of the LOC and OOP etc won't matter when your Bash script is one file and 150LOC instead of 5-10 files, objects an methods that are called just one time etc, 1000+LOC PHP.

mschuster91قبل 9 سنوات

> I think YOUR perception of Perl is what is outdated here.

Next to no one uses Perl any more. You won't find people to maintain your homegrown stuff - and aside from maintaining an OTRS instance I have not seen Perl code in a decade.

> Most things can be done in 1/10th of the LOC and OOP etc won't matter when your Bash script is one file and 150LOC instead of 5-10 files, objects an methods that are called just one time etc, 1000+LOC PHP.

Well good luck with Bash if your batch script involves stuff like parsing JSON/XML or interacting with databases. I prefer to write quick one-offs in PHP than wasting hours with Bash scripting; and even if it's no one-off but a script that needs to be run regularly (e.g. via cron), you'll find a competent PHP programmer for maintenance way easier than a competent Bash programmer.

> And come on, for "job control" type scripts you should be fired for using PHP over Bash.

For plain job control, like an initscript, I fully agree with you. But not for anything more complex, for the reasons outlined above.

geonقبل 9 سنوات

> PHP iirc can't even be used as a websocket server

True, if you run it behind a web server like 99.999% of all users.

If you run it as a cli script, you can implement pretty much anything. I saw a ftp server once. Crazy.

Still, even on a normal web server, php can do long polling perfectly fine, which is often enough.

> being able to write program flows without dozens of promises is a breeze

It is a breeze with async/await too.

mschuster91قبل 9 سنوات

> If you run it as a cli script, you can implement pretty much anything. I saw a ftp server once. Crazy.

Yeah, I implemented a simple ircd once. Funny days... but I don't know of any library/framework that could help you with the websocket protocol level, and I'm too old for writing my own ;)

geonقبل 9 سنوات

Websocket is actually not that complicated. A couple of headers to upgrade the request from HTTP to websocket, then framing of each payload.

But you could use something like websocketd, which spawns a process of your chioce for each client and pipes the websocket to stdin and vice versa.

https://github.com/joewalnes/websocketd

Each PHP process looks like it takes about 5 MB of ram on my laptop, so probably not the best method for 5000+ concurrent users if you use PHP, but still.

cr0shقبل 9 سنوات

> I don't know of any library/framework that could help you with the websocket protocol level

FYI - http://socketo.me/

LinuxFreedomقبل 9 سنوات

what would be a good hardware spec and server configuration to have 5000 users do long polling with a php backend?

geonقبل 9 سنوات

If you care about performance and traffic, perhaps php isn't where you should start anyway.

LinuxFreedomقبل 9 سنوات

Yes, of course there are easy to use and much better programming languages for that - I just really wanted to read some "real-life" recommendations from that guy that mentioned "php" and "long-polling" in the same sentence.

[Maybe it was just a joke and I did not get it... or I did get it but did not identify it as a joke... however... I would like to see some beef...]

mschuster91قبل 9 سنوات

Uh. You do realize that Mediawiki, powering nearly all wiki systems including Wikipedia, is written in PHP. Or Facebook, they were able to go with PHP for iirc 500 M users?

PHP is in any case a better choice, performance-wise, than Python or, god forbid, Java.

geonقبل 9 سنوات

Facebook built their own PHP-to-C++ compiler (https://en.wikipedia.org/wiki/HipHop_for_PHP) and later a JIT compiler/VM (https://en.wikipedia.org/wiki/HipHop_Virtual_Machine), with a custom, typed version of PHP (https://en.wikipedia.org/wiki/Hack_(programming_language) ).

All just to make PHP a little faster. I think you are making my case.

mschuster91قبل 9 سنوات

HH transpilation was introduced in 2010. Depending on when exactly you look in 2010, FB had between 350-600M active users (https://www.yahoo.com/news/number-active-users-facebook-over...).

Many websites don't ever get to 350M users, so it's safe to say that plain PHP will satisfy your startup for a long time. Also, PHP7 is pretty much on par with HHVM in real-world scenarios: https://kinsta.com/blog/the-definitive-php-7-final-version-h...

SergeAxقبل 9 سنوات

Check out "experimental JIT branch" of PHP. It boost performance 1.5-2 times compared to current PHP 7.1, and they didn't start optimization yet. It blows HHVM out of the water, and I can't wait to compare performance with Java and .NET.

geonقبل 9 سنوات

And the vast majority of websites never get 5000 concurrent users either. Your planned load obviously dictates the language as much as anything else.

cutlerقبل 9 سنوات

PHP performs better than Java? Care to offer evidence?

mschuster91قبل 9 سنوات

Can't disclose much in public, but our PHP CMS hosting requirements tend to be waaaay cheaper than our Java-based CMSes. Also, deployment of PHP apps is (in my experience) faster and easier.

cutlerقبل 9 سنوات

(cheaper hosting || faster deployment) != better performance

jwdunneقبل 9 سنوات

With regards to 2, I have experienced this. As a solution, I built a websocket server using NodeJS. I then built an API in express that PHP / Gulp used to push messages to be sent via websocket.

There might be a better way but I'd effectively added support for server push from our PHP app in a morning, with great results.

The other thing it provided me was clear evidence of the "best tool for the job" in a shop that demanded PHP.

The problem I have with PHP is what is usually touted as it's benefit. It's easy to find PHP developers. The problem: most of them are not very good.

To close, there are many more PHP RFCs that internals should approve, e.g arrow lambdas with automatic variable closure, design by contract, etc. These could really bring the language into it's own.

matsemannقبل 9 سنوات

One thing I like about PHP for quick prototyping or one-off projects is that an error doesn't bring the whole server down.

For instance, I held a workshop where I hosted a server the students were to do some requests to. I had written a simple Node application that read the json they sent and returned a result. What I didn't anticipate was that them sending malformed json would bring the whole server down. So then I had to add error handling and stuff. Of course one should normally do that, but in PHP the malformed requests would just fail, leaving other requests unharmed, which would be acceptable for this kind of project.

bpicoloقبل 9 سنوات

Every web framework out there (express + nodejs included) will handle exceptions properly and not blow up the server on exception.

matsemannقبل 9 سنوات

You're not refusing my point by insisting on adding more complexity (a huge framework), when simplicity and rapid prototyping of a small script was the goal.

This question is what I mean, extra stuff one has to keep in mind: http://stackoverflow.com/q/5999373/923847 Does it matter for a real project? Probably not, just some boilerplate. Does it matter when I want something quick up and running? Yes.

bpicoloقبل 9 سنوات

> a huge framework

I contest the idea that sinatra-style frameworks are "huge".

Python + flask is about as low-overhead as one can get. No need to set up any extra (apache || nginx).

PHP's model of "just chug along returning null" by disabling most relevant errors is a massive antipattern in production code.

innocenatقبل 9 سنوات

PHP has lower overhead still. You don't need to import, explicitly define route, etc. PHP Built-in dev server doesn't require anything extra either.

bpicoloقبل 9 سنوات

I mean, it's "different", but I think it's a stretch to say lower. PHP overhead is suddenly a lot higher when you need a route with a dynamic ID in it if you're talking pure out-of-the-box, for example, which is a reasonably trivial use case.

ec109685قبل 9 سنوات

Express can't catch an exception thrown in a callback cleanly.

bpicoloقبل 9 سنوات

It doesn't crash the server, though, is the point.

ec109685قبل 9 سنوات

It effectively does. All concurrent requests are halted.

kyriakosقبل 9 سنوات

PHP does not deserve most of the negativity it receives. It matured a lot recently and even though there are many alternatives tha probably can do better under some scenarios php still does what it does very well.

jpalomakiقبل 9 سنوات

It is also quite interesting the PHP introduced many (or at least some of us) to the ideas of server-less computing already 20 years ago.

That's how I got started. I paid some small money for local ISP and got in exchange FTP user account and account on their shared MySQL Server. I would write my code and deploy via FTP. I believe some companies ran a cluster of servers, providing cloud like scalability for these deployments.

viraptorقبل 9 سنوات

That's not what the server-less idea is about. You're describing a standard shared hosting.

_wmdقبل 9 سنوات

You're in software land, what is old is always new again. Try to dance around with the Wikipedia definition for serverless and get back to us when you've found a way to exclude the majority of old-style PHP hosting environments from it:

> Serverless computing, also known as function as a service (FaaS), is a cloud computing code execution model in which the cloud provider fully manages starting and stopping of a function's container platform as a service (PaaS) as necessary to serve requests, and requests are billed by an abstract measure of the resources required to satisfy the request, rather than per virtual machine, per hour.[1]

> Despite the name, it does not actually involve running code without servers.[1] The name "serverless computing" is used because the business or person that owns the system does not have to purchase, rent or provision servers or virtual machines for the back-end code to run on.

For example, nearlyfreespeech.net neatly fits even the pay-for-what-you-use billing definition here

viraptorقبل 9 سنوات

Big differences, with shared php hosting you get: (Yes, I'm sure there are exceptions, but they're... exceptions)

Payment per month not per usage. Normally there are usage tiers and a "you reached your limit" page rather than scaling.

No versioning beyond standard file operations.

No routing. You get all traffic in a single endpoint.

Only web traffic, no integration. Serverless in many cases is FaaS, with multiple event sources, not web-request-handler-aaS.

Sure, there are some similarities. But the use cases are completely different. Nobody is seriously considering "should I use AWS lambda, or GoDaddy shared PHP hosting?"

[deleted]قبل 9 سنوات

agumonkeyقبل 9 سنوات

Gotta admit that since the PHP ~6 days they made more than impressive efforts in many domains.

innocenatقبل 9 سنوات

There weren't PHP6 though.

agumonkeyقبل 9 سنوات

hence the ~

IIRC it's after that time that PHP saw very important changes vm and language.

jerryszczerryقبل 9 سنوات

> PHP ~6

Ah, you mean good old PHP 4294967289?

tyingqقبل 9 سنوات

It's fairly impressive that the php7 core team was able to release something that competes well with HHVM from a performance perspective.

I assume they are working with significantly fewer advantages and resources than Facebook, so that's a pretty nice result.

nodesocketقبل 9 سنوات

HHVM was released in 2011, while PHP 7 was released in 2015. So perhaps in that extra time there was additional techniques, optimizations, and technology that allowed PHP 7 to stay comparable in terms of performance to HHVM.

tyingqقبل 9 سنوات

There was a long time to catch up, yes. But HHVM did several big improvements to their JIT tech between then and now.

PHP7 also rolled out with very little noise about stability, migration issues, etc.

Not knocking FB at all, just noting the PHP folks did a nice job.

kijinقبل 9 سنوات

The PHP team is absolutely obsessed with backward compatibility. They broke surprisingly few things with PHP 7, and everything they broke was clearly documented.

You don't get to power a significant fraction of the world's most important websites if you break backward compatibility every few months.

bpicoloقبل 9 سنوات

They broke an unusual number of things in 7.1, a couple somewhat annoying e.g. defaulting DateTime('now') to including microseconds, without a single builtin function available that can strip/change microseconds on a datetime.

captn3m0قبل 9 سنوات

Yes, but they decided to keep it to 7.1, not 7.0, which meant the majority of the perf upgrades were available to most users who migrated to 7.0 _easily_.

7.1 was where all the breaking changes got pushed as a result.

vgy7ujmقبل 9 سنوات

PHP in itself perhaps but I have seen major efforts being put into 5.3 -> 5.6 and 5.6 -> 7.x.

One thing that broke badly was phpunit and related libs for mocking etc.

This was a very vanilla PHP project by the way, no frameworks etc.

krickقبل 9 سنوات

FWIW, I had to deal with HHVM a year ago, when PHP7 was recently released, and while PHP7 was already quite stable, HHVM (and especially Hack) was misbehaving in seemingly common situations.

sbarreقبل 9 سنوات

I had a similar experience to this.

I think the difference is that FB was really focused on making sure HHVM ran for their internal use cases specifically, and broad compatibility was a secondary concern in the early days (and perhaps still is? I haven't looked at HHVM in a while).

To be fair, they were quite transparent about this, and published quite a bit of documentation around what worked and what didn't work when running PHP on HHVM so that was good.

chxقبل 9 سنوات

Another one of nikic's seminal guides into the workings of PHP. It was him who wrote the foreach guide on StackOverflow http://stackoverflow.com/a/14854568/308851 .

Another note: if I ever catch you using these cute "finally ... interesting edge-cases" described in this article, your PR will be refused. Yes, yes, it's very smart, and you might win an obfuscation contest but in a professional environment we like code that can be understood even when the emergency phone kicks us out of bed. If it's five times as long, I care not, but if it requires me to think hard on the code, I do.

_RPMقبل 9 سنوات

Great write up. Thank you for writing this. I've always been interested in the PHP VM, but it is not documented. Nikic is one smart dude.

Vogtinatorقبل 9 سنوات

That the smart branches optimization requires a workaround in the IR codegen concerns me a bit. It makes sense in a HW context, like MIPS branch delay slots, but not really here. There could be a flag in the branch instruction that disables the optimization at least.

DenisMقبل 9 سنوات

I wonder if it's possible to compile it for iOS?

I need a templating engine in my app, and php seems like the most popular one.

improv32قبل 9 سنوات

PHP is a whole lot more than just a templating engine. I think you would find that much more effort than is required just to make some templates.

krickقبل 9 سنوات

I actually assumed this is a joke/trolling attempt, since it was a common joke to despisingly call PHP a "templating engine" a few years ago. But the follow-up seems so sincere that I don't even know what to think anymore...

DenisMقبل 9 سنوات

In terms of community impact, assuming bad faith is not far removed acting in bad faith. Both will inevitably drag down the level of discourse.

mproyقبل 9 سنوات

That's the problem with trolling and hyberbole on any subject. People take it at face value and it becomes the popular narrative.

DenisMقبل 9 سنوات

Perhaps you can send me down the righ path?

I want my users to be able to send emails from their iPads, and those emails would be generated based on templates. There will be many such templates built in, and eventually users will be able to hire web developer-type person to make custom templates.

My thinking was that PHP is the most popular language for that sort of thing, so it would be nice if could support that. My second choice is handlebars. I'm not sure if JSX would do the job?

Any thoughts appreciated.

jawngeeقبل 9 سنوات

https://github.com/groue/GRMustache

https://github.com/groue/GRMustache.swift

my_gholaقبل 9 سنوات

PHP is not a templating language. You can build a template engine with it, but then, you can build one with any other language.

If your app is in swift or objective-c, look into template libraries for those languages. Simple Google search tells me there's a couple of options including one using handlebar's format.

DenisMقبل 9 سنوات

How is this not a template? It generates valId HTML out of data.

  <?php 
  for ($x = 0; $x <= 10; $x++) {
    echo "The number is: $x   <br>";
  }

nathan_f77قبل 9 سنوات

If you just need formatting without logic, then you could use something like Markdown.

Someone else already mentioned GRMustache [1], and that looks pretty good.

I'm not sure if there is an iOS version, but you could look for something like liquid [2]. I think liquid is usually a better choice for user-controlled templates, especially when you're rendering on a server. But if they're just compiling the templates on their own device, then handlebars (GRMustache) would be the right way to go.

[1] https://github.com/groue/GRMustache

[2] https://github.com/Shopify/liquid

jwdunneقبل 9 سنوات

If solely for templating emails, I would go with handlebars.

You could use PHP but then you have a whole host of other stuff that you don't want or need in a templating language.

LinuxFreedomقبل 9 سنوات

https://laravel-news.com/laravel-markdown-emails

fdsfsda7fsdaقبل 9 سنوات

https://twig.sensiolabs.org/

bencoderقبل 9 سنوات

I don't think there are implementations of twig outside of PHP, so this isn't useful for the op

fdsfsda7fsdaقبل 9 سنوات

there is I use JTwig with Java + Spring all time

same syntax