23 ms·

Things you should know about PHP 7

145 points by speg 12y ago

richthegeek 12y ago
Good to see PHP slowly improving, although I haven't used it for years now. On a side note, does anyone know why Drupal 8 is apparently so absurdly slow? I know it's not entirely fair to compare against D7 as it's still technically "under development" but it just seems insane to take that much of a performance hit for nicer OOP semantics...
- mgkimsal 12y ago
  I'd say it's to do with having been rebuilt with Symfony components. That's not to say symfony is, by necessity, slow, but I going to guess that completeness and stability was first for such a big change before performance. But... that's just a guess.
  - psaintla 12y ago
    I think it is exactly the fact that they are using Symfony components. Symfony and a lot of other PHP frameworks went head first into the non-sensical enterprise Java abstraction and IoC hell from 10-15 years ago that current Java developers are running as fast as they can from. That overhead comes at a cost.
    - mgkimsal 12y ago
      Hrm... I got a few down votes for my guess (well, I started with "I'd say that..." but it was later qualified as a supposition. I also wasn't making a judgement call that it was bad - just observing that they made a big architectural change, and performance probably wasn't the primary consideration for rev 1. Weird...
- pestaa 12y ago
  Drupal 8 is being developed in the Symfony framework. You may have been exposed to a deployment running in development mode (app_dev.php in the URL is a good sign even if not a necessity). Once the debug flag is turned off, Symfony won't check the freshness of the dependency container as well as templates, bootstrap caches, etc. (you clear the cache manually in production.) As to what the Drupal devs may have added on top of the framework, I have no idea. Being a generic CMS, I presume their abstractions are a little bit overengineered.
  - aikah 12y ago
    AFAIK Drupal doesn't use symfony "framework edition" , but symfony/http kernel library at its core to abstract the default PHP http api. So it is a Symfony app as much as Laravel is ... it's not Symfony full stack.
- jkoudys 12y ago
  D8's a work in progress, and if there's one thing I wouldn't be too critical of a wip for, it's performance. Frankly I don't really see drupal's place in the world anymore. It's so absurdly config-heavy, which may have made sense a decade ago but not now. Everyone will just install composer, put laravel/symfony on there, and be off to the races. The era of giant pages of drupal-managed plugins is over, and replaced by package managers + slimmer CMSes like joomla or concrete5.
  - dabernathy89 12y ago
    I'm a WordPress guy, so I am not a Drupal expert. But Laravel/Symfony and Drupal are targeting mostly different audiences (application developers vs website developers/website owners).
    - jkoudys 12y ago
      Laravel/symfony are just one component. It's the approach of organizing your site as packages, and properly namespacing and exposing well-documented class libraries of your own that's becoming the dominant approach even for websites. Even the concept of a 'website' as simply rendering pages is something fewer people need a custom install for - squarespace et al have the basic sites covered, and for anyone who needs a pretty specific feature there's plenty of other platforms: shopify (commerce), nationbuilder (nonprofits), etc. Having worked with many PHP CMSes, the config for managing various drupal plugins is often far more complex to setup, maintain, and migrate than simply writing that feature in my own little class in concrete5, joomla, or even without a CMS. I get the appeal behind wordpress (even if I think it's implementation is complete garbage), because non-technical people can still setup and manage their plugins. Most of my clients who are/were on drupal, became my clients after they were inevitably crushed under a pile of drupal config.
  - snuxoll 12y ago
    Drupal 8 actually using a lot of Symfony2 components internally now, and you should be able to manage your modules with composer if you so choose. I'm really excited for D8, no other CMS to date has been as easy to administer in my eyes, and now that they're dramatically revamping the module and theming stories I may even enjoy writing modules and themes once more.
- thejosh 12y ago
  Because it hasn't begun speed improvements yet. Basically once everything is "done", everyone will optimise it to run faster. There are lots of improvements going in to make it 'fast by default'.
- imakesnowflakes 12y ago
  If you consider bolting on whatever feature the php developers can wrap their heads half way around, as "improving", then sure.. See this reddit comment, http://www.reddit.com/r/PHP/comments/2zhg6z/how_true_is_this_php_bashing/cpjhx04 http://www.reddit.com/r/PHP/comments/2zhg6z/how_true_is_this... and tell me what you think about it. When stuff like this exist, does it matter if it gets all the shiny new features and speed improvements? Not to mention that by php's development culture, these new features probably end up half baked and with it's own set of weird behaviors...
- snowwrestler 12y ago
  I'm sure D8 is a lot slower--isn't performance usually the last thing worked before release?--but I don't think D7 has really been distinguished by its speed either. In my experience, D7 speed tuning consists almost entirely of inserting and tuning cache layers at every level. In other words, working around the slowness of the application. Drupal seems great for a content-heavy site that caches well. Personally, I would not build an account-based, heavily personalized web app in Drupal unless I knew the audience was pretty small. Even in the dinky D7 sites I've run, we got significant performance improvements just by handing off search and commenting to services other than Drupal (SOLR and Disqus).
babuskov 12y ago
TL;DR: 1. Scheduled to come out in Q4 2015 2. <=> operator, see https://wiki.php.net/rfc/combined-comparison-operator https://wiki.php.net/rfc/combined-comparison-operator 3. Return Type Declarations & Scalar Type Hints 4. Speed improvements (25-70%) 5. Yep, speed improvements are for real. You're welcome.
- xrstf 12y ago
  > 1. Scheduled to come out in Q4 2015 ... and available on general cheap webhosting sometime around 2020. If we're lucky. Thank god our company slowly moved away from building small PHP websites that have to run on the most fucked up PHP installations from the before-time. Now it's PHP 5.6+ everywhere :-)
  - mawburn 12y ago
    >... and available on general cheap webhosting sometime around 2020. If we're lucky. Shared Hosting needs to die off anyway.
    - CatsoCatsoCatso 12y ago
      Why?
      - pestaa 12y ago
        The security implications and unpredictable resource availability never made it feasible to run a real production site from shared hosting.
        andybak 12y ago
        Hmmmm. I've got about a dozen.
        stingraycharles 12y ago
        What? You are suggesting that everyone should run their own server? And you are suggesting that nobody even ran a real production site on shared hosting? You could say the exact same thing about VPS servers compared to dedicated hosting and be equally wrong. Please accept that there are different use cases that come with different solutions, of which shared hosting is one.
timepiece 12y ago
"You can put lipstick on a pig but it's still a pig" - Barack Obama on PHP in 2008
- xylodev 12y ago
  Barack Obama? Do you mean the most famous of the most brilliant hackers? https://www.whitehouse.gov/blog/2014/12/10/president-obama-first-president-write-line-code https://www.whitehouse.gov/blog/2014/12/10/president-obama-f...
  - timepiece 12y ago
    The man himself ... The Hacker in Chief println('I\'m fly, super high');
franciscop 12y ago
Seeing this: > function add( ... ): float {} I think a much better choice would have been: > float function add( ... ) {} Or just: > float add( ... ) {} Since that's how it's done in other languages and people would feel at home with it.
- Drakim 12y ago
  Haxe uses the first syntax, as does AS3. So it's not like "other languages" are universally opposed to this order.
  - allan_s 12y ago
    Rust also has this syntax if I remember correctly, for parsing reason
  - tne 12y ago
    AFAICT both Haxe and AS3 consistently put types on the right, including argument declarations. Other languages consistently put it on the left. Most languages make a choice like that; PHP mixes things up a bit. But then, it wouldn't be PHP if it was too consistent ;).
    - TazeTSchnitzel 12y ago
      To be fair, it's not the same as an argument type. The type of `foo()` isn't int, it's function. You're not specifying the type of the thing itself, merely the type of what it returns. Though this seems to have been lost on the creators of C. ;)
  - pilsetnieks 12y ago
    Go also has a similar syntax (except the colon)
  - aikah 12y ago
    sure but AS3, Go Haxe and others ARE consistant function foo(a:int,b:string):bool{} in PHP this will be function foo(int a,string b):bool{}
arthursilva 12y ago
Heck, I'm kinda felling bad as a Pythonista. We're lagging badly speed wise. Sure, there's PyPy but it's not compatible with the mainstream C-Extensions so pretty much a no-go for most of my projects. Hopefully Piston will come to rescue in the future.
- fijal 12y ago
  Well, maybe you should review your stack. Which C extensions are you missing? There are alternatives for the most part (barring GUI)
  - arthursilva 12y ago
    The ones I miss most frequently are a faster json parser (I use ujson), a faster msgpack parser and a faster database driver. The pure python versions (even on PyPy) don't make the cut :(
    - fijal 12y ago
      json parser on pypy is competitive, try it (or give us examples where it's not). msgpack needs a better impl, but can be done, database drivers seem to work over cffi at reasonable speed.
      - arthursilva 12y ago
        I just checked out and seems like pypy has made some good progress database driver wise! So I went ahead and installed pypy 2.5.1 to compare the json performance. It got better but ujson is just crazy fast. CPython (w/ ujson) is 70% faster to loads and 50% faster to dumps a sample json from my project (50~156kb json). I expect msgpack to be the same. Unfortunately seems like Pypy still doesn't pay off in this app, but it might in many others that don't spend as much time (de)serializing.
        fijal 12y ago
        ujson breaks the spec btw ;-) We tried doing the same thing but cffi callbacks are slow. We should maybe revisit that (and make callbacks faster, we did get better on that)
darrelld 12y ago
Being a PHP dev since the early 00's it's great to see the language moving forward with features and performance and seemingly less hate towards it from the developer community at large. For a while there seemed to be a "PHP-shaming" thing going around. If you did PHP you were sort of in an untouchable uncool class.
- arenaninja 12y ago
  > If you did PHP you were sort of in an untouchable uncool class. That's still around, even on Hacker News. Tons of comments in poor taste from posts about 3 months ago as I remember it
- teh_klev 12y ago
  Meh...PHP devs think they've got bad here? I still have to knock out Classic ASP now and again. My dad found out and won't even look at me or answer the phone :)
  - haroldp 12y ago
    I know that pain
ck2 12y ago
While I eagerly look forward to PHP7, you can get more than PHP7 speed now with HHVM, and HHVM has never been easier to use. But competition is good, great actually. HHVM recently folded in JIT regex like PHP7, so they are copying from each other.
- implicit 12y ago
  Hack is also a substantially better language than PHP. It, directly or indirectly, fixes a lot of horrible behaviour. PHP's absurd comparison operators, for instance, are safely usable once you drop them into a statically typed environment.
  - TazeTSchnitzel 12y ago
    Hack is merely PHP with poorly-enforced type hints Unlike PHP, Hack lets you, nay, encourages you, to turn off type checking in places
    - chupy 12y ago
      I don't believe it's just that. One of the coolest features which if it is used properly actually speeds up the response times of a normal blocking php script /app flow is the as async feature: http://docs.hhvm.com/manual/en/hack.async.php http://docs.hhvm.com/manual/en/hack.async.php.
itafroma 12y ago
Note this is just Zend's take on what's important in PHP 7: it's not a complete list. A more comprehensive list: - Dual-mode scalar type hints (weak by default, toggleable to strict via a per-file syntax) (https://wiki.php.net/rfc/scalar_type_hints_v5 https://wiki.php.net/rfc/scalar_type_hints_v5) - Return type declarations (https://wiki.php.net/rfc/return_types https://wiki.php.net/rfc/return_types) - <=> operator (https://wiki.php.net/rfc/combined-comparison-operator https://wiki.php.net/rfc/combined-comparison-operator) - Null coalesce operator (??) (https://wiki.php.net/rfc/isset_ternary https://wiki.php.net/rfc/isset_ternary) - Closure::call (https://wiki.php.net/rfc/closure_apply https://wiki.php.net/rfc/closure_apply) - Abstract syntax tree (https://wiki.php.net/rfc/abstract_syntax_tree https://wiki.php.net/rfc/abstract_syntax_tree) - Context sensitive lexer, allowing the use of reserved words in more places (https://wiki.php.net/rfc/context_sensitive_lexer https://wiki.php.net/rfc/context_sensitive_lexer) - Unicode escape syntax in strings (https://wiki.php.net/rfc/unicode_escape https://wiki.php.net/rfc/unicode_escape) - A uniform variable syntax (https://wiki.php.net/rfc/uniform_variable_syntax https://wiki.php.net/rfc/uniform_variable_syntax) - Expectations (https://wiki.php.net/rfc/expectations https://wiki.php.net/rfc/expectations) - Use declaration grouping (https://wiki.php.net/rfc/group_use_declarations https://wiki.php.net/rfc/group_use_declarations) - Removal of a ton of long-deprecated features - Massive speed improvements You can see everything that's been added to PHP 7 on https://wiki.php.net/rfc https://wiki.php.net/rfc (look under Accepted and Implemented - PHP 7.0)
- arenaninja 12y ago
  OH man I want that Null coalesce operator so bad...
  - smutticus 12y ago
    I feel like I've needed that since I first started coding PHP 17 years ago!
    - AlyssaRowan 12y ago
      I feel like I want to test what happens if you put values like "", false, " ", 0, an empty array, etc etc etc in front of ??. Because, you know, this is PHP.
systemtheory 12y ago
question. if, given a programming language is Turing Complete, is it possible that we might stop further development on some of the more,,, crappy languages that are already out there and adopt some of the less crappy ones to fill in any feature gap? i'm all for diversity and experimentation, but doesn't evolution say that some things just gotta die? EDIT: fixed some spelling errors
- krapp 12y ago
  People do already choose languages other than PHP because they find PHP crappy. But in evolutionary terms, clearly PHP (and by extension Hack) are evolving, and are successful in their niche. If you don't want to use PHP you don't have to, alternatives already exist in abundance - including, of course, the fork of PHP itself. So use Java, or Python, or Ruby or C# or whatever floats your boat. But if you're arguing that PHP should not be allowed to exist despite there still being a community that uses it and despite there still being improvements made to the language and despite its success, that's not an evolutionary argument, it's an elitist one.
  - TazeTSchnitzel 12y ago
    If you stop development on PHP then lots of your favourite websites will need to waste an awful lot of time and money switching to a new language and retraining developers.
jkoudys 12y ago
The spaceship <=> is actually a lot cooler than many PHP devs realize. Rails devs find it extremely handy. Now that my PHP apps are moving away from being big apps that render full web-pages, and towards being a thin application layer that just renders JSON, I'm finding a higher % of my code is just sorting operations. Closure has helped a lot with this, and nearly all my <=>s are almost certainly going to be in the form of `function($a, $b) { return $a->getThingy() <=> $b->getThingy(); }` Scalar type hints are a bit of a no-brainer. Type-hinting classes is nice, but there's a lot of sloppiness out there because if you can't type hint as a scalar, not only do you need a separate check to see if it's int or string, you also specifically cannot say it's non-object/array in your function declaration. One of the biggest inconsistencies I see, especially on old CMSes, is where you'd have a method in one class like `function doThing(Page $page) {`, and elsewhere as `function differentThing($page) {`, and sometimes differentThing's $page is a Page, other times it's an int with that page's ID or name. Yes there are all kinds of ways to check for that today, but it benefits everyone if the easiest way to do something is also the right way. Return type declaration has been in Hack for a while, and it's really handy there. Any C or Java programmers know how useful they are. My big hope here is that they encourage others to stop returning mixed-types, which is a pattern that inevitably just puts more control logic around every call to that function. I don't care too much about nullable type-hints on parameters (you can still set a default `= null` to allow nullable), but I'm _really_ hoping the nullable return-types passes. Having worked with this for a while in Hack, return types are far more useful if they're nullable. e.g. you say `function isUserActive(): bool`, that's totally fine since you're clearly expecting it to be true or false, but if you had `function getActiveUser(): User`, you'd want the option to return null if there is no active user, which could be done nicely as `function getActiveUser(): ?User` if this passes: https://wiki.php.net/rfc/nullable_types#return_types https://wiki.php.net/rfc/nullable_types#return_types Now that we're finally actually making a proper PHP spec, I'm not as excited about 4 and 5 as they'd like us to be. It's definitely faster, but if the Zend engine isn't the only game in town, it doesn't matter as much. All the HHVM benchmarks I've seen still put it way above PHP7.
- TazeTSchnitzel 12y ago
  > Now that we're finally actually making a proper PHP spec, I'm not as excited about 4 and 5 as they'd like us to be. I was the only person who seemed to care much about the spec, and I quit. The spec has several broken tests, numerous omissions and inaccuracies, and doesn't mention any of the really important PHP 7 features. I'm not too optimistic.
mischanix 12y ago
There are credentials for the HTTP Auth on a staging environment commented out in the source of this webpage (Line 317).
- TazeTSchnitzel 12y ago
  Email Zend.
  - mischanix 12y ago
    I looked around and couldn't find an appropriate e-mail address anywhere. If you have one, feel free to let them know.
    - TazeTSchnitzel 12y ago
      https://gwhois.org/zend.com https://gwhois.org/zend.com
moe 12y ago
And here is "Things you should know about PHP in general": http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
- kentt 12y ago
  That's not a very good list about things you should know about PHP. That's a rant about that the bad parts. You can Google '[x language] Sucks' or whatever other language and come up with a ton of good reasons why X sucks.
bovermyer 12y ago
Between PHP 7 and HHVM, and what appears to me to be an increasingly fragmented community, I decided to jump ship to Ruby on Rails as my development platform of choice for web apps. This is not to say that PHP won't work fine for many people; I just don't care for the (several) directions PHP is going in.
- jtreminio 12y ago
  Not sure what you mean. I have not detected any fragmentation. In fact, HHVM's speed of development has been a much needed kick in the pants to PHP.
  - bovermyer 12y ago
    The introduction of a language specification by Facebook is great. The fact that it took over a decade for a language specification to appear is less so. PHP-NG/PHP 7's troubled birth, and its contention with HHVM, does not bode well for PHP's future. I feel like it's going the route of Perl 5/6;Python 2/3.
10098 12y ago
> Return Type Declarations & Scalar Type Hints Finally, this took them a long freaking time.
- chriswarbo 12y ago
  Disclaimer: I use the word "type" in the following to refer to types, tags and classes, because I'm feeling lazy ;) > Return Type Declarations & Scalar Type Hints This seems a shame. We can only add type hints to arguments and return types if we're writing arguments and return values, which is unnecessarily verbose. We should really add these types to the functions themselves. For example: $dbl = function(int $x) : int { return 2 * $x; }; $neg = function(int $x) : int { return -1 * $x; }; We've given types to the inputs and outputs, but the functions themselves still just have the type 'Closure'; there's no indication about what they accept or return. Functions are meant to abstract, but this implementation of type hinting forces us to go and read the implementation! For example, if we've written the following and we want to add types (where I've put "???"), we need to look at the implementations of $dbl and $neg: $dblneg = function(??? $x) : ??? { return $dbl($neg($x)); }; We could implement the same functions in a different way: $mult = function(int $x) : Closure { return function(int $y) : int use ($x) { return $x * $y; }; }; $dbl = $mult(2); $neg = $mult(-1); Now if we want to add types to $dblneg, the implementations of $dbl and $neg don't help; we have to dig even further and read the implementation of $mult. All of this would go away if we could hint the function instead, eg. $mult = function($x) : Closure(int, Closure(int, int)) { return function($y) use ($x) : Closure(int, int) { return $x + $y; }; }; $dbl = $mult(2); $neg = $mult(-1); Here I've used the ": ???" syntax to hint the whole function rather than just its return value, and I've written "Closure(x, y)" to mean a function type from argument type "x" to return type "y". This means if we have a function, like $dbl, we can query its type in the usual way (`typeof $dbl`) and get the argument and return types without having to read any source. Note that this doesn't require generics/parametric-polymorphism, since all of the types I've used are concrete. However, adding that would be the next logical step ;) Note that we can trivially extend this scheme to functions with multiple arguments, in all of the various, incompatible ways PHP lets us define them: function add($x, $y) : Closure(int, int, int) { return $x + $y; } $add = function($x, $y) : Closure(int, int, int) { return $x + $y; }; static function add($x, $y) : Closure(int, int, int) { return $x + $y; } public function add($y) : Closure(int, int, int) { $this + $y; } function add($x) : Closure(int, Closure(int, int)) { return function($y) use ($x) : Closure(int, int) { return $x + $y; }; } function add($args) : Closure(array(int, int), int) { return $args[0] + $args[1]; } $add = function($args) : Closure(array(int, int), int) { return $args[0] + $args[1]; } static function add($x) : Closure(int, Closure(int, int)) { return function($y) use ($x) : Closure(int, int) { return $x + $y; }; } function add() : Closure(int, int, int) { return func_get_args()[0] + func_get_args()[1]; } function add() : Closure(array(int, int), int) { return func_get_args()[0][0] + func_get_args()[0][1]; } // and so on This seems to me like another case of PHP ignoring decades of programming language research and development and instead just "doing it like <popular language from the 1970s> does it". It's like generators all over again :( (eg. see http://okmij.org/ftp/continuations/generators.html http://okmij.org/ftp/continuations/generators.html and http://parametricity.net/dropbox/yield.subc.pdf http://parametricity.net/dropbox/yield.subc.pdf )
brianpgordon 12y ago
This chart can't be right. It takes 12.6 seconds to render the Wordpress home page? http://i.imgur.com/k6Bq9Yz.png http://i.imgur.com/k6Bq9Yz.png

145 points by speg 12y ago

Good to see PHP slowly improving, although I haven't used it for years now. On a side note, does anyone know why Drupal 8 is apparently so absurdly slow? I know it's not entirely fair to compare against D7 as it's still technically "under development" but it just seems insane to take that much of a performance hit for nicer OOP semantics...

mgkimsal 12y ago
I'd say it's to do with having been rebuilt with Symfony components. That's not to say symfony is, by necessity, slow, but I going to guess that completeness and stability was first for such a big change before performance. But... that's just a guess.
- psaintla 12y ago
  I think it is exactly the fact that they are using Symfony components. Symfony and a lot of other PHP frameworks went head first into the non-sensical enterprise Java abstraction and IoC hell from 10-15 years ago that current Java developers are running as fast as they can from. That overhead comes at a cost.
  - mgkimsal 12y ago
    Hrm... I got a few down votes for my guess (well, I started with "I'd say that..." but it was later qualified as a supposition. I also wasn't making a judgement call that it was bad - just observing that they made a big architectural change, and performance probably wasn't the primary consideration for rev 1. Weird...
pestaa 12y ago
Drupal 8 is being developed in the Symfony framework. You may have been exposed to a deployment running in development mode (app_dev.php in the URL is a good sign even if not a necessity). Once the debug flag is turned off, Symfony won't check the freshness of the dependency container as well as templates, bootstrap caches, etc. (you clear the cache manually in production.) As to what the Drupal devs may have added on top of the framework, I have no idea. Being a generic CMS, I presume their abstractions are a little bit overengineered.
- aikah 12y ago
  AFAIK Drupal doesn't use symfony "framework edition" , but symfony/http kernel library at its core to abstract the default PHP http api. So it is a Symfony app as much as Laravel is ... it's not Symfony full stack.
jkoudys 12y ago
D8's a work in progress, and if there's one thing I wouldn't be too critical of a wip for, it's performance. Frankly I don't really see drupal's place in the world anymore. It's so absurdly config-heavy, which may have made sense a decade ago but not now. Everyone will just install composer, put laravel/symfony on there, and be off to the races. The era of giant pages of drupal-managed plugins is over, and replaced by package managers + slimmer CMSes like joomla or concrete5.
- dabernathy89 12y ago
  I'm a WordPress guy, so I am not a Drupal expert. But Laravel/Symfony and Drupal are targeting mostly different audiences (application developers vs website developers/website owners).
  - jkoudys 12y ago
    Laravel/symfony are just one component. It's the approach of organizing your site as packages, and properly namespacing and exposing well-documented class libraries of your own that's becoming the dominant approach even for websites. Even the concept of a 'website' as simply rendering pages is something fewer people need a custom install for - squarespace et al have the basic sites covered, and for anyone who needs a pretty specific feature there's plenty of other platforms: shopify (commerce), nationbuilder (nonprofits), etc. Having worked with many PHP CMSes, the config for managing various drupal plugins is often far more complex to setup, maintain, and migrate than simply writing that feature in my own little class in concrete5, joomla, or even without a CMS. I get the appeal behind wordpress (even if I think it's implementation is complete garbage), because non-technical people can still setup and manage their plugins. Most of my clients who are/were on drupal, became my clients after they were inevitably crushed under a pile of drupal config.
- snuxoll 12y ago
  Drupal 8 actually using a lot of Symfony2 components internally now, and you should be able to manage your modules with composer if you so choose. I'm really excited for D8, no other CMS to date has been as easy to administer in my eyes, and now that they're dramatically revamping the module and theming stories I may even enjoy writing modules and themes once more.
thejosh 12y ago
Because it hasn't begun speed improvements yet. Basically once everything is "done", everyone will optimise it to run faster. There are lots of improvements going in to make it 'fast by default'.
imakesnowflakes 12y ago
If you consider bolting on whatever feature the php developers can wrap their heads half way around, as "improving", then sure.. See this reddit comment, http://www.reddit.com/r/PHP/comments/2zhg6z/how_true_is_this_php_bashing/cpjhx04 http://www.reddit.com/r/PHP/comments/2zhg6z/how_true_is_this... and tell me what you think about it. When stuff like this exist, does it matter if it gets all the shiny new features and speed improvements? Not to mention that by php's development culture, these new features probably end up half baked and with it's own set of weird behaviors...
snowwrestler 12y ago
I'm sure D8 is a lot slower--isn't performance usually the last thing worked before release?--but I don't think D7 has really been distinguished by its speed either. In my experience, D7 speed tuning consists almost entirely of inserting and tuning cache layers at every level. In other words, working around the slowness of the application. Drupal seems great for a content-heavy site that caches well. Personally, I would not build an account-based, heavily personalized web app in Drupal unless I knew the audience was pretty small. Even in the dinky D7 sites I've run, we got significant performance improvements just by handing off search and commenting to services other than Drupal (SOLR and Disqus).

babuskov 12y ago

TL;DR: 1. Scheduled to come out in Q4 2015 2. <=> operator, see https://wiki.php.net/rfc/combined-comparison-operator https://wiki.php.net/rfc/combined-comparison-operator 3. Return Type Declarations & Scalar Type Hints 4. Speed improvements (25-70%) 5. Yep, speed improvements are for real. You're welcome.

xrstf 12y ago
> 1. Scheduled to come out in Q4 2015 ... and available on general cheap webhosting sometime around 2020. If we're lucky. Thank god our company slowly moved away from building small PHP websites that have to run on the most fucked up PHP installations from the before-time. Now it's PHP 5.6+ everywhere :-)
- mawburn 12y ago
  >... and available on general cheap webhosting sometime around 2020. If we're lucky. Shared Hosting needs to die off anyway.
  - CatsoCatsoCatso 12y ago
    Why?
    - pestaa 12y ago
      The security implications and unpredictable resource availability never made it feasible to run a real production site from shared hosting.
      - andybak 12y ago
        Hmmmm. I've got about a dozen.
      - stingraycharles 12y ago
        What? You are suggesting that everyone should run their own server? And you are suggesting that nobody even ran a real production site on shared hosting? You could say the exact same thing about VPS servers compared to dedicated hosting and be equally wrong. Please accept that there are different use cases that come with different solutions, of which shared hosting is one.

timepiece 12y ago

"You can put lipstick on a pig but it's still a pig" - Barack Obama on PHP in 2008

xylodev 12y ago
Barack Obama? Do you mean the most famous of the most brilliant hackers? https://www.whitehouse.gov/blog/2014/12/10/president-obama-first-president-write-line-code https://www.whitehouse.gov/blog/2014/12/10/president-obama-f...
- timepiece 12y ago
  The man himself ... The Hacker in Chief println('I\'m fly, super high');

franciscop 12y ago

Seeing this: > function add( ... ): float {} I think a much better choice would have been: > float function add( ... ) {} Or just: > float add( ... ) {} Since that's how it's done in other languages and people would feel at home with it.

Drakim 12y ago
Haxe uses the first syntax, as does AS3. So it's not like "other languages" are universally opposed to this order.
- allan_s 12y ago
  Rust also has this syntax if I remember correctly, for parsing reason
- tne 12y ago
  AFAICT both Haxe and AS3 consistently put types on the right, including argument declarations. Other languages consistently put it on the left. Most languages make a choice like that; PHP mixes things up a bit. But then, it wouldn't be PHP if it was too consistent ;).
  - TazeTSchnitzel 12y ago
    To be fair, it's not the same as an argument type. The type of `foo()` isn't int, it's function. You're not specifying the type of the thing itself, merely the type of what it returns. Though this seems to have been lost on the creators of C. ;)
- pilsetnieks 12y ago
  Go also has a similar syntax (except the colon)
- aikah 12y ago
  sure but AS3, Go Haxe and others ARE consistant function foo(a:int,b:string):bool{} in PHP this will be function foo(int a,string b):bool{}

arthursilva 12y ago

Heck, I'm kinda felling bad as a Pythonista. We're lagging badly speed wise. Sure, there's PyPy but it's not compatible with the mainstream C-Extensions so pretty much a no-go for most of my projects. Hopefully Piston will come to rescue in the future.

fijal 12y ago
Well, maybe you should review your stack. Which C extensions are you missing? There are alternatives for the most part (barring GUI)
- arthursilva 12y ago
  The ones I miss most frequently are a faster json parser (I use ujson), a faster msgpack parser and a faster database driver. The pure python versions (even on PyPy) don't make the cut :(
  - fijal 12y ago
    json parser on pypy is competitive, try it (or give us examples where it's not). msgpack needs a better impl, but can be done, database drivers seem to work over cffi at reasonable speed.
    - arthursilva 12y ago
      I just checked out and seems like pypy has made some good progress database driver wise! So I went ahead and installed pypy 2.5.1 to compare the json performance. It got better but ujson is just crazy fast. CPython (w/ ujson) is 70% faster to loads and 50% faster to dumps a sample json from my project (50~156kb json). I expect msgpack to be the same. Unfortunately seems like Pypy still doesn't pay off in this app, but it might in many others that don't spend as much time (de)serializing.
      - fijal 12y ago
        ujson breaks the spec btw ;-) We tried doing the same thing but cffi callbacks are slow. We should maybe revisit that (and make callbacks faster, we did get better on that)

darrelld 12y ago

Being a PHP dev since the early 00's it's great to see the language moving forward with features and performance and seemingly less hate towards it from the developer community at large. For a while there seemed to be a "PHP-shaming" thing going around. If you did PHP you were sort of in an untouchable uncool class.

arenaninja 12y ago
> If you did PHP you were sort of in an untouchable uncool class. That's still around, even on Hacker News. Tons of comments in poor taste from posts about 3 months ago as I remember it
teh_klev 12y ago
Meh...PHP devs think they've got bad here? I still have to knock out Classic ASP now and again. My dad found out and won't even look at me or answer the phone :)
- haroldp 12y ago
  I know that pain

ck2 12y ago

While I eagerly look forward to PHP7, you can get more than PHP7 speed now with HHVM, and HHVM has never been easier to use. But competition is good, great actually. HHVM recently folded in JIT regex like PHP7, so they are copying from each other.

implicit 12y ago
Hack is also a substantially better language than PHP. It, directly or indirectly, fixes a lot of horrible behaviour. PHP's absurd comparison operators, for instance, are safely usable once you drop them into a statically typed environment.
- TazeTSchnitzel 12y ago
  Hack is merely PHP with poorly-enforced type hints Unlike PHP, Hack lets you, nay, encourages you, to turn off type checking in places
  - chupy 12y ago
    I don't believe it's just that. One of the coolest features which if it is used properly actually speeds up the response times of a normal blocking php script /app flow is the as async feature: http://docs.hhvm.com/manual/en/hack.async.php http://docs.hhvm.com/manual/en/hack.async.php.

itafroma 12y ago

Note this is just Zend's take on what's important in PHP 7: it's not a complete list. A more comprehensive list: - Dual-mode scalar type hints (weak by default, toggleable to strict via a per-file syntax) (https://wiki.php.net/rfc/scalar_type_hints_v5 https://wiki.php.net/rfc/scalar_type_hints_v5) - Return type declarations (https://wiki.php.net/rfc/return_types https://wiki.php.net/rfc/return_types) - <=> operator (https://wiki.php.net/rfc/combined-comparison-operator https://wiki.php.net/rfc/combined-comparison-operator) - Null coalesce operator (??) (https://wiki.php.net/rfc/isset_ternary https://wiki.php.net/rfc/isset_ternary) - Closure::call (https://wiki.php.net/rfc/closure_apply https://wiki.php.net/rfc/closure_apply) - Abstract syntax tree (https://wiki.php.net/rfc/abstract_syntax_tree https://wiki.php.net/rfc/abstract_syntax_tree) - Context sensitive lexer, allowing the use of reserved words in more places (https://wiki.php.net/rfc/context_sensitive_lexer https://wiki.php.net/rfc/context_sensitive_lexer) - Unicode escape syntax in strings (https://wiki.php.net/rfc/unicode_escape https://wiki.php.net/rfc/unicode_escape) - A uniform variable syntax (https://wiki.php.net/rfc/uniform_variable_syntax https://wiki.php.net/rfc/uniform_variable_syntax) - Expectations (https://wiki.php.net/rfc/expectations https://wiki.php.net/rfc/expectations) - Use declaration grouping (https://wiki.php.net/rfc/group_use_declarations https://wiki.php.net/rfc/group_use_declarations) - Removal of a ton of long-deprecated features - Massive speed improvements You can see everything that's been added to PHP 7 on https://wiki.php.net/rfc https://wiki.php.net/rfc (look under Accepted and Implemented - PHP 7.0)

arenaninja 12y ago
OH man I want that Null coalesce operator so bad...
- smutticus 12y ago
  I feel like I've needed that since I first started coding PHP 17 years ago!
  - AlyssaRowan 12y ago
    I feel like I want to test what happens if you put values like "", false, " ", 0, an empty array, etc etc etc in front of ??. Because, you know, this is PHP.

systemtheory 12y ago

question. if, given a programming language is Turing Complete, is it possible that we might stop further development on some of the more,,, crappy languages that are already out there and adopt some of the less crappy ones to fill in any feature gap? i'm all for diversity and experimentation, but doesn't evolution say that some things just gotta die? EDIT: fixed some spelling errors

krapp 12y ago
People do already choose languages other than PHP because they find PHP crappy. But in evolutionary terms, clearly PHP (and by extension Hack) are evolving, and are successful in their niche. If you don't want to use PHP you don't have to, alternatives already exist in abundance - including, of course, the fork of PHP itself. So use Java, or Python, or Ruby or C# or whatever floats your boat. But if you're arguing that PHP should not be allowed to exist despite there still being a community that uses it and despite there still being improvements made to the language and despite its success, that's not an evolutionary argument, it's an elitist one.
- TazeTSchnitzel 12y ago
  If you stop development on PHP then lots of your favourite websites will need to waste an awful lot of time and money switching to a new language and retraining developers.

jkoudys 12y ago

The spaceship <=> is actually a lot cooler than many PHP devs realize. Rails devs find it extremely handy. Now that my PHP apps are moving away from being big apps that render full web-pages, and towards being a thin application layer that just renders JSON, I'm finding a higher % of my code is just sorting operations. Closure has helped a lot with this, and nearly all my <=>s are almost certainly going to be in the form of `function($a, $b) { return $a->getThingy() <=> $b->getThingy(); }` Scalar type hints are a bit of a no-brainer. Type-hinting classes is nice, but there's a lot of sloppiness out there because if you can't type hint as a scalar, not only do you need a separate check to see if it's int or string, you also specifically cannot say it's non-object/array in your function declaration. One of the biggest inconsistencies I see, especially on old CMSes, is where you'd have a method in one class like `function doThing(Page $page) {`, and elsewhere as `function differentThing($page) {`, and sometimes differentThing's $page is a Page, other times it's an int with that page's ID or name. Yes there are all kinds of ways to check for that today, but it benefits everyone if the easiest way to do something is also the right way. Return type declaration has been in Hack for a while, and it's really handy there. Any C or Java programmers know how useful they are. My big hope here is that they encourage others to stop returning mixed-types, which is a pattern that inevitably just puts more control logic around every call to that function. I don't care too much about nullable type-hints on parameters (you can still set a default `= null` to allow nullable), but I'm _really_ hoping the nullable return-types passes. Having worked with this for a while in Hack, return types are far more useful if they're nullable. e.g. you say `function isUserActive(): bool`, that's totally fine since you're clearly expecting it to be true or false, but if you had `function getActiveUser(): User`, you'd want the option to return null if there is no active user, which could be done nicely as `function getActiveUser(): ?User` if this passes: https://wiki.php.net/rfc/nullable_types#return_types https://wiki.php.net/rfc/nullable_types#return_types Now that we're finally actually making a proper PHP spec, I'm not as excited about 4 and 5 as they'd like us to be. It's definitely faster, but if the Zend engine isn't the only game in town, it doesn't matter as much. All the HHVM benchmarks I've seen still put it way above PHP7.

TazeTSchnitzel 12y ago
> Now that we're finally actually making a proper PHP spec, I'm not as excited about 4 and 5 as they'd like us to be. I was the only person who seemed to care much about the spec, and I quit. The spec has several broken tests, numerous omissions and inaccuracies, and doesn't mention any of the really important PHP 7 features. I'm not too optimistic.

mischanix 12y ago

There are credentials for the HTTP Auth on a staging environment commented out in the source of this webpage (Line 317).

TazeTSchnitzel 12y ago
Email Zend.
- mischanix 12y ago
  I looked around and couldn't find an appropriate e-mail address anywhere. If you have one, feel free to let them know.
  - TazeTSchnitzel 12y ago
    https://gwhois.org/zend.com https://gwhois.org/zend.com

moe 12y ago

And here is "Things you should know about PHP in general": http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

kentt 12y ago
That's not a very good list about things you should know about PHP. That's a rant about that the bad parts. You can Google '[x language] Sucks' or whatever other language and come up with a ton of good reasons why X sucks.

bovermyer 12y ago

Between PHP 7 and HHVM, and what appears to me to be an increasingly fragmented community, I decided to jump ship to Ruby on Rails as my development platform of choice for web apps. This is not to say that PHP won't work fine for many people; I just don't care for the (several) directions PHP is going in.

jtreminio 12y ago
Not sure what you mean. I have not detected any fragmentation. In fact, HHVM's speed of development has been a much needed kick in the pants to PHP.
- bovermyer 12y ago
  The introduction of a language specification by Facebook is great. The fact that it took over a decade for a language specification to appear is less so. PHP-NG/PHP 7's troubled birth, and its contention with HHVM, does not bode well for PHP's future. I feel like it's going the route of Perl 5/6;Python 2/3.

10098 12y ago

> Return Type Declarations & Scalar Type Hints Finally, this took them a long freaking time.

chriswarbo 12y ago
Disclaimer: I use the word "type" in the following to refer to types, tags and classes, because I'm feeling lazy ;) > Return Type Declarations & Scalar Type Hints This seems a shame. We can only add type hints to arguments and return types if we're writing arguments and return values, which is unnecessarily verbose. We should really add these types to the functions themselves. For example: $dbl = function(int $x) : int { return 2 * $x; }; $neg = function(int $x) : int { return -1 * $x; }; We've given types to the inputs and outputs, but the functions themselves still just have the type 'Closure'; there's no indication about what they accept or return. Functions are meant to abstract, but this implementation of type hinting forces us to go and read the implementation! For example, if we've written the following and we want to add types (where I've put "???"), we need to look at the implementations of $dbl and $neg: $dblneg = function(??? $x) : ??? { return $dbl($neg($x)); }; We could implement the same functions in a different way: $mult = function(int $x) : Closure { return function(int $y) : int use ($x) { return $x * $y; }; }; $dbl = $mult(2); $neg = $mult(-1); Now if we want to add types to $dblneg, the implementations of $dbl and $neg don't help; we have to dig even further and read the implementation of $mult. All of this would go away if we could hint the function instead, eg. $mult = function($x) : Closure(int, Closure(int, int)) { return function($y) use ($x) : Closure(int, int) { return $x + $y; }; }; $dbl = $mult(2); $neg = $mult(-1); Here I've used the ": ???" syntax to hint the whole function rather than just its return value, and I've written "Closure(x, y)" to mean a function type from argument type "x" to return type "y". This means if we have a function, like $dbl, we can query its type in the usual way (`typeof $dbl`) and get the argument and return types without having to read any source. Note that this doesn't require generics/parametric-polymorphism, since all of the types I've used are concrete. However, adding that would be the next logical step ;) Note that we can trivially extend this scheme to functions with multiple arguments, in all of the various, incompatible ways PHP lets us define them: function add($x, $y) : Closure(int, int, int) { return $x + $y; } $add = function($x, $y) : Closure(int, int, int) { return $x + $y; }; static function add($x, $y) : Closure(int, int, int) { return $x + $y; } public function add($y) : Closure(int, int, int) { $this + $y; } function add($x) : Closure(int, Closure(int, int)) { return function($y) use ($x) : Closure(int, int) { return $x + $y; }; } function add($args) : Closure(array(int, int), int) { return $args[0] + $args[1]; } $add = function($args) : Closure(array(int, int), int) { return $args[0] + $args[1]; } static function add($x) : Closure(int, Closure(int, int)) { return function($y) use ($x) : Closure(int, int) { return $x + $y; }; } function add() : Closure(int, int, int) { return func_get_args()[0] + func_get_args()[1]; } function add() : Closure(array(int, int), int) { return func_get_args()[0][0] + func_get_args()[0][1]; } // and so on This seems to me like another case of PHP ignoring decades of programming language research and development and instead just "doing it like <popular language from the 1970s> does it". It's like generators all over again :( (eg. see http://okmij.org/ftp/continuations/generators.html http://okmij.org/ftp/continuations/generators.html and http://parametricity.net/dropbox/yield.subc.pdf http://parametricity.net/dropbox/yield.subc.pdf )

brianpgordon 12y ago

This chart can't be right. It takes 12.6 seconds to render the Wordpress home page? http://i.imgur.com/k6Bq9Yz.png http://i.imgur.com/k6Bq9Yz.png