8 ms·

> PHP is a nice language but is having trouble keeping up with modern languages It's only "having trouble" because it can't change its API from month to month

• vlunkr 8y ago
  > it can't change its API from month to month to match whatever's in vogue This is true of every language used on the web. That's why it's important to start out with the right choices, which in many instances PHP did not do, and is slowly trying to recover.
• jimnotgym 8y ago
  A majority of the web runs on one of a handful of programs that use php...WordPress, Magento...
  • tgtweak 8y ago
    While true, there is still a tremendous amount of the web that is powered by php and not using WordPress or Magento. Facebook, Yahoo, Wikipedia, even Google.
    • baroffoos 8y ago
      Facebook forked PHP to make Hack to try and make PHP usable. Yahoo is yahoo. Wikipedia wouldn't have the resources to change anything. Google has a wiki page for their developers telling them to never ever use PHP for any google project.
      • wolco 8y ago
        Those facebook improvements made there way back into the core. Google might be able to move quicker if they allowed php. Facebook killed them in social. The type of products google can offer is limited by this decision.
        • koudos 8y ago
          Not sure PHP is the reason reason why Google failed at competing at Social
          • Ayesh 8y ago
            It is not.
        • Operyl 8y ago
          HHVM can't make its way entirely back to core, and is in fact completely separating from PHP entirely now[1]. If I recall correctly, while PHP7 implemented better op-caching, it has _not_ implemented JIT compilation yet. 1. https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
          • muglug 8y ago
            It hasn't - a JIT compiler (if it comes) will come in PHP 8.
          • acomjean 8y ago
            This is true. But HHVM lit a fire under the php devs to get php7 out the door with significant performance improvements. (php6 never saw the light of day). Php has improved so much with the 7x releases.
            • tgtweak 8y ago
              Php7 is pretty damn fast with apc cache and some tuning. Not to mention it doesn't have any of the silly restrictions that hhvm had.
        • baroffoos 8y ago
          Google+ did not fail for technical reasons. Everything I saw about it was technically better. It failed for social reasons, facebook already exists and has everyone on it.
      • muglug 8y ago
        > Google has a wiki page for their developers telling them to never ever use PHP for any google project. I didn't know that, but it makes sense - the things that PHP's good for (getting a web-based service backed by some sort of datastore up and ready to receive requests) are not the things that Google (on the whole) cares about. Google instead cares that the thing can be improved and maintained by your colleagues, few of whom know PHP.
      • nicoburns 8y ago
        There's also Laravel, which is more popular than both Django and Rails on a worldwide basis (https://g.co/trends/9CGj5 https://g.co/trends/9CGj5). Rails and Django are more popular in the US where I hear PHP is not very popular...
        • ksec 8y ago
          Interesting, I have seen a surge of Laravel + Vue.js in recent projects. And many companies wanted to move back to PHP / Laravel from Ruby Rails / Django.
      • wwweston 8y ago
        > Facebook forked PHP to make Hack to try and make PHP usable. Facebook clearly found PHP usable before they created Hack, otherwise they would (a) not have bothered and (b) may well not have existed in the first place. The accurate statement is probably closer to "FB created hack to adapt to performance demands at an unusual scale and add some additional typing discipline bringing additional order across a large engineering team."
        • swsieber 8y ago
          I'd take it one step further: At Facebook scale, performance gains have huge returns (adding typing can improve pefromance), so they try to improve all parts of their infrastructure, not just PHP. For example, Facebook's bolt for native code: https://code.fb.com/data-infrastructure/accelerate-large-scale-applications-with-bolt/ https://code.fb.com/data-infrastructure/accelerate-large-sca... PHP probably did have more low hanging fruit than say C, I'll give them that.
      • partiallypro 8y ago
        Just because Google doesn't have a use for PHP doesn't mean it has no use or that it's dated or having "a hard time keeping up." Why would Google want to use PHP when it doesn't have a core competency that uses it? On the other hand Microsoft does use PHP in some cases, where it makes sense, like company blogs. What's wrong with that? Nothing. The right tool for the right job. People that hate on PHP are usually people that over engineer things. Why build something like Wordpress in .NET or Node.js...when you don't need that, because you already have Wordpress and it works fine for a small site or blog? People will spent 10x the amount of time trying to -not- use PHP on a simple project than to use that time doing something else. It's like this new "let's containerize everything" movement. Ok, you just spent an hour setting up something that would normally take 5 minutes, and you now have access to a bunch of features your little app will never ever use. Congrats. No one is saying use PHP to build a super complex webapp, (though you could do that if you wanted!) But for small project PHP is very hard to beat when it comes to time/benefit. Right tool, right job. Simple. Biggest complaint I have against modern developers is the tendency to make a simple thing complex because it's en vogue to use X, vs Y. Gotta build this small web app with 50 users and no need to scale, better build in Node and Kubernetes. So laughable.
    • jchw 8y ago
      Employee of Google here... really? Where does Google use PHP?
• JadeNB 8y ago
  > A majority of the web still runs on some variant of PHP, and that guarantees that it's not dying anytime soon. The same is true of Perl, but (depending on your definition of "not dying") it's not clear that Perl isn't dying.
  • wolco 8y ago
    PHP is growing these days. Some of the hip crowd are coming back, small business never left and globally it is gaining as more developers come online. PHP offers so much so easily it's hard to replace.
    • cglace 8y ago
      Why choose PHP over python, node, ruby, elixir, go, etc. There are just so many great choices that offer just as much and more than PHP. I get that PHP has made major strides over the years. I just don't see why you would choose PHP for a greenfield project.
      • insulanus 8y ago
        Well, my guess is that PHP offers a lot more to the beginner. When you've been doing this a while, you can appreciate what e.g. Python gives you in structure, maintainability, and lack of foot-guns. But when you're still in the "how does this work? Why won't this work? It worked!" phase, having less boilerplate, and fewer non-problem domain concerns (types? modules? tuples? Say what you mean, Old Man!) might be really valuable. I think the best thing I remember about PHP is probably its online manual. Each library function had a few full use cases underneath.
        • Mave83 8y ago
          best documentation in my opinion
        • cglace 8y ago
          > But when you're still in the "how does this work? Why won't this work? It worked!" phase, having less boilerplate, and fewer non-problem domain concerns (types? modules? tuples? Say what you mean, Old Man!) might be really valuable However, modern php isnt being sold as index.php and a mysql connection. It's Doctrine, composer and laravel/symphony. Which have their fair share of boilerplate. >I think the best thing I remember about PHP is probably its online manual. Each library function had a few full use cases underneath The problem with PHP is that you need the online manual everytime you want to use a function because the argument order is so inconsistent.
• wwweston 8y ago
  I might even go so far as to say that the contention isn't true. In fact, these days I tend to assume the word "modern" is a developer thought-smell. Unless its user can explain what they mean by modern, it's best to assume it's a set of personal aesthetics informed largely by available fashions/habits in the first half decade of a developer's career (which can be fine, it's just the term modern carries waaay more weight than it should). ( -smell can also be a thought-smell, but that's another discussion.) I'd guess the author means "modern languages have a reasonably simple concurrency paradigm supported by language or standard library primitives," which would be about the only reason other than the interest in the task itself I can imagine reimplementing PHP in Go. I wouldn't buy that definition myself (and as the parent says, it's less clear whether it's the right fit for PHP) but it's a place to start in addressing the relative merits the project might actually be claiming.
• mholt 8y ago
  > a version of PHP that's not focussed on web requests, which is sort of the entire point of PHP. But even for web requests it's terrible. Or at least, it was, last time I used it years ago. Couldn't really do any long-running tasks in response to an HTTP request, or load a single data set into memory to share among all the HTTP requests over the lifetime of the server. (Maybe you could, but I couldn't figure out how.) I'm quite happy that I haven't touched PHP in years. As fun/cool as this project is, there's nothing I miss from PHP that isn't present -- or even better -- in Go.
  • nicoburns 8y ago
    PHP has gotten a lot better. New APIs have been added on top of features like classes. And many of the worst of the older APIs have been deprecated. It still works on the "new interpreter per request model". But that has advantages in the multicore world: everything is thread-safe by default, and will scale to N cores without any extra work (for shared state people tend to use something like Redis). It's by no means perfect. But if you stick to the modern bits and use one of the nicer frameworks (like Laravel), then I think I'd prefer it over something like Ruby.
    • debaserab2 8y ago
      > use one of the nicer frameworks (like Laravel) Yikes
      • cityzen 8y ago
        And?
  • deleted 8y ago
    [deleted]
  • muglug 8y ago
    > But even for web requests it's terrible Maybe you have specific needs? At Vimeo it runs reasonably well, with median response time around 30ms. > Or at least, it was, last time I used it years ago Ah, PHP 7 was released three years ago and made some massive improvements to performance. > Couldn't really do any long-running tasks in response to an HTTP request We add something to a queue, and handle those tasks offline. Pretty simple. > or load a single data set into memory to share among all the HTTP requests over the lifetime of the server apc_store does that: http://php.net/manual/en/function.apc-store.php http://php.net/manual/en/function.apc-store.php (it's part of a very popular extension) > I'm quite happy that I haven't touched PHP in years. Cool, it's not for everyone and all use cases. But it's always there if you need it.
• jchw 8y ago
  It feels like you are downplaying decades of genuine improvement in web development under the guise that it's all just fashion, flavor-of-the-week stuff that has no substance. I get that people have an inverse reaction to hype, but I am disappointed that this is the top comment. There's a reason why the world moved on from CGI, even PHP moved on from CGI - and yet, its request model is still based on CGI, executing a script for each request. People are still relying on a webserver to rewrite URLs because PHP doesn't have the concept of an application server with a router. How is that superior to the more modern paradigm? Despite this, the most largely used pieces of PHP software, MediaWiki, Wordpress, etc. tend to use things like the front controller pattern that actually invert the old CGI model into something more like what you would see with application servers in Ruby on Rails, Django, even Go to a degree.
  • muglug 8y ago
    > its request model is still based on CGI, executing a script for each request And it turns out to work incredibly well for the most part. It's serverless by design! > People are still relying on a webserver to rewrite URLs because PHP doesn't have the concept of an application server with a router Again, I don't see how this is a problem. Routing is likely to be the most trivial part of your app, but it's also tied to business logic and should (IMO) be part of the checked-in code.
    • jchw 8y ago
      >And it turns out to work incredibly well for the most part. It's serverless by design! Worked incredibly well compared to what? CGI was a performance nightmare, forking per request. CGI and FastCGI have both been a security nightmare. HTTPoxy, Shellshock, Pathinfo, and more. Setting up PHP correctly is cumbersome and depends on a complex interaction between sometimes confusing php.ini options and fairly complex configurations with your webserver. Check out, for example, this article on configuring PHP properly with Nginx: https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-and-nginx-dont-trust-the-tutorials-check-your-configuration/ https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an... So other than that, yes, it worked. Incredibly well? Not compared to application servers which don't have the kinds of vulnerabilities and configuration complexities caused by the weird impedance mismatch between webservers and FastCGI workers. The jab about serverless is really condescending and unrelated, but I feel it necessary to point out that I am not really especially a proponent of serverless as it is today. I much prefer long-running application servers. PHP-FPM gives you a bit of both worlds, a combination of them that is far from ideal in my opinion. >Again, I don't see how this is a problem. Routing is likely to be the most trivial part of your app, but it's also tied to business logic and should (IMO) be part of the checked-in code. I am having difficulty responding to this because I think you misunderstood what I meant. I do think the routing logic should be part of the code. Which means, not part of the webserver configuration. If you're using Nginx, which is the server I currently use with PHP, checking your rewrite configuration in with your code is difficult, because there's no `.htaccess` mechanism like Apache, and so you have to deploy the configuration separately.