*I realize HipHop PHP did this already but it doesn't have it's own baked-in web server afaik. I'm thinking along the lines of compiling down to something small and fast to be deployed to K8S clusters without needing containers for Apache or nginx as part of the setup.

Sure - one could do what many folks in other environments are doing: node.js or go developers often implement a simple API endpoint and use a reverse proxy (nginx or something) in front of it for interacting with the outside world, but fpm is the more specialized protocol for that.

Then again PHP is driven by people contributing. If some folks contribute according infrastructure and push for it I could be proven wrong. :)

Sure, for most parts PHP can handle that, but for long running things some I/O event based context switching typically is more efficient and in a few error cases PHP deferrs cleanup to "request shutdown" which might be a while out with websockets.

In the end PHP is focussed on one role (serving "normal" HTTP requests in isolated contexts quickly) and other technologies do other things better. And I think focus is a good thing.

Then again: PHP is open and does whatever the contributors want it to do and I myself am not actively contributing much anymore :)

It does, actually: hhvm -m server -p 8080

Uses proxygen.

Proxygen is pretty cool, actually. Even does http/2 & https, and is suitable for production use. I'm somewhat surprised nobody's done the work to link it with PHP, Perl, etc, to provide what node.js does for js.

Edit: Also, on compiling PHP, there's a pretty good start here: https://github.com/ircmaxell/php-compiler/blob/master/README.... The FFI functionality in PHP 7.4, plus the internal use of an AST in php7.x, are what made it possible. Missing lots of functionality, but a neat proof of concept.

since 5.x (not production ready tough)

https://www.swoole.co.uk/docs/modules/swoole-http-server-doc

To these companies, PHP 7 is a hip new language that they're not using.

Is that true? PHP 5.6 and 7.0 were EOL'd in 2018, and acording to data at https://blog.packagist.com/php-versions-stats-2019-1-edition... the use of PHP 7 and later is ~90%. Web properties like DreamHost have supported PHP 7+ for years, and have deprecated versions before 7.1.

> Newer versions have breaking changes that make upgrading a large codebase difficult.

The documentation on this is pretty good[1], and there's some nice tooling that can help[2]. I wouldn't say that I've migrated "large" codebases, but FWIW in my limited experience this hasn't been particularly onerous.

[1] See https://www.php.net/manual/en/migration70.php and related appendices [2] https://auth0.com/blog/migrating-a-php5-app-to-7-part-three/

For Red Hat, that means there are places still on RHEL 5, 6, and 7, which is going to put them PHP at 5.4.

It looks like Ubuntu 16 is the oldest Ubuntu still under support. That had PHP 7.0. Ubuntu end-of-life (when they stop getting security updates) are later than end of support. Ubuntu 14 EOL is April 2022. That has PHP 5.5.9.

Debian 8 has long term support until June 2020, and PHP 5.6. Debian 9 has LTS to June 2022, and PHP 7.0.

For those who are on the latest LTS or equivalent:

RHEL 8 has PHP 7.2.

Ubuntu 18 has PHP 7.2.24

Debian 10 has PHP 7.3.

I can believe that, even if I don't understand the mindset. Unless they're ready to retire, you'd think they'd want to keep their toolboxes current.

A few other old sites, even relatively large ones, that were built from scratch or on homegrown CMS years ago, only took some minor fixes and mostly were up and running in couple of hours, some even worked right away without any issues.

С and С++ are holding their grounds, but they are more and more niche today. Facebook tried to domesticate PHP, but failed spectacularly. So it looks like PHP is most democratic and liberal programming language of today) I am glad it's getting steadily ahead.

Also, C and C++ are some of the most widely used languages in the world. I wouldn't call them niche.

Edit: according to the TIOBE C/C++ are ranked higher than PHP

Today, it's extremely diffuse; there are ~200 people on the various teams that hold decision making power over the project, and only like six are Mozilla employees. The core team has 3 Mozilla employees and 9 people total.

And, as someone who was involved before, during, and after working for Mozilla, Mozilla just plain doesn’t have interest in really guiding Rust development. If anything, it’s diminished over time, after all, when Rust started, it was sponsored by the CTO and a director, both of whom eventually left, but also that thought it was important for Rust to be as independent as possible.

Ruby is a brilliant language (pun intended), but from where I am (web- and mobile software development for last ~20 years) it seems to be steadily declining. Headhunters having a hard time looking for Ruby devs now.

Sounds like the supply is lower than the demand for Ruby devs, which sounds to be like the opposite from "steadily declining".

Also, one should look further than usage when it comes to evaluating a language.

IMO Ruby/Rails became legacy tech. Are you aware of any fresh significant projects on Ruby?

And in terms of numbers. If you look at e.g. number of repos on GitHub with at least 10 stars[0], Ruby comes in as #7 ahead of C# (#8) and Go (#9) and faaar ahead of Rust (#17).

Interesting side-note. C and C++, which you called "niche", clock in at #6 and #5 respectively.

[0]: https://github.com/oprogramador/github-languages#10-stars

Thanks for the lunk though, it does shows some interesting stats.

More data here: https://githut.info/

I know this is meant as an insult but it's a poor one. There are programming languages features out there that are good on their own merits and PHP is incorporating those features. If they also happen to also exist in Java, or C++, or Haskell then they do. Adding those features might make a language more like X because X also has that feature but that doesn't mean it's the goal.

In many ways PHP does things better than Java by virtue of having hindsight on how those features exist in other languages. The way PHP handles nullable types is better than both Java and C#.

PHP JIT is intended to reduce latency and large codebase start-up delay, two biggest problems of modern PHP as for me. It's not about calculations.

I have some patches to improve the DOM API extension for example, simplify its usage which would make it much simpler to use.

I have not need to create a class to encapsulate a GET request parameter in PHP. In Java it was common the last time I used it.

Also, why do you say that Python is controlled by Google?

Python was influenced by Google and that influence is hard to wear. Until now Python is definitely not community-driven. Also, look at this version 2/3 snafu.

I too stick to the most explicit version (function($foo)).

It's the same for command line arguments, I have an easier time remembering words (--preserve-permissions for instancem --volume, etc.) than letters if I don't use the interface enough.

So that's why we now have half-assed OOP in Javascript, we have Scala which is basically all programming languages ever, etc. Meanwhile, Go is still fighting a lot of requests to add language features, knowing full well the complexity added to the compiler (and more importantly the cognitive overhead for developers).

Code documentation should be clear and concise, not to be deciphered through the code author's take on the meta meaning of reserved words.

    usort($data, fn($l, $r) => $this->foo($l, $r));

    usort($data, function($l, $r) use ($this) { return $this->foo($l, $r); });

    usort($data, [$this, 'foo']);

PHP arrow functions can only contain a single statement and always implicitly return, so that sort of thing is exactly what they're designed for.

Although worth noting with your second example that you haven't needed to capture $this in closures since 5.4, and in fact it is an error to do so now (though I'm not sure when that was introduced).

Anyways: People are capable of writing loooooong expressions (chaining with && can be good to handle errors from multiple operations in one place (till you have to figure out which specific condition broke)) Thus "single expression" isn't neccisarily short ;)

Anyways: Point is "it can be useful, but developers should think, what they are doing" Perl's "there's more than one way to do it" probably goes too far, but being able to focus on the relevant parts and being able to providing the amount of context needed are good things.

  array_filter(arr, fn)
  array_reduce(arr, fn)
  array_map(fn, arr1[, arr2, ...])
  array_walk(&arr, fn)

Happy to see the proc_open() feature of NOT spawning a shell, and interested in the FFI implementation.

This also seems like a first step toward fixing associativity of the ternary operator, one of the most ridiculous deficiencies of the PHP language.

"Future Scope: We could make the ternary right-associative in a later release, after it has been an error for a while."

https://wiki.php.net/rfc/ternary_associativity

Using getters and setters already got us type checking external to the class, and is generally good OO practice. Internally I think static analysis on documented types was a good enough solution.

the zend VM can specialize ops already, trading size of the op-implementations against type-check-elision/fusion by GCC/clang. I think eliding redundant type checks at least won't be hard when confined to a single php function.

That begs the question, what's PHP's value proposition for new projects? If PHP mostly chases feature parity with Java/.NET/TypeScript and doesn't attempt to do anything better/different (like Elm/Haskell/Rust/Go/Erlang arguably do), then why choose it?

I am having a complete joy building these components, and I find two things to be striking:

My base component does not use a single dependency and it accomplishes a lot! It is really amazing what can be done in PHP with very few lines of code without the help of ANY external libraries, efficiently. I use PDO for connecting to the my SQL database, which is available natively... It can all just be very simple.

On the flip side, my administrative component is driven by Laravel, which yes, took heavy inspiration from Ruby on Rails, but by this point has greatly surpassed it and is very powerful and enjoyable to use.

PHP is the only server side language I would say I have achieved mastery in, so while I am naive to what could be better in X or Y language, I never currently feel held back for what I need to do, and I enjoy doing it.

If you are working in the web niche, what are the reasons not to choose it?

With mainstream languages, there's rarely any single clear and/or insurmountable problem, it's all the little annoyances you run into every day that add up, plus the cognitive load imposed by the language directly as well as indirectly through the code it lets you write.

I'm not 100% up to date on how much PHP has closed the gap in the last few years, but subjectively I never found it anything but tedious due missing features, various unnecessary pitfalls (sometimes with security implications), silly limitations (you can write a static type in this case but not in that, you can catch this error but not that, no inner classes, etc etc.), and numerous other small cases of poor "ergonomics".

The "batteries included" nature of the standard library is nice, and in contrast to the somewhat fragmented world of RubyGems or NPM it can feel downright pleasant, but finding a SQL library or such is a pretty small effort in the scope of a project, and (popular) 3rd party libraries tend in my experience to be better than the equivalent standard library stuff in most of the languages I know. Every time I wrote a non-trivial amount of code with PDO, I had to look up the correct initialization rituals to get sane settings and copy or recreate a bunch of more or less "obvious" helpers. I'm sure there's something better in Composer by now.

This fairly-recent hour long talk covering the 25 year history of PHP by its creator was very good, if you're into that sort of thing =)

https://www.youtube.com/watch?v=wCZ5TJCBWMg

As someone who works in web I have to deal with javascript also, and always enjoyed that too, until node and npm became standard tools. Now everytime I have a project that involves npm I end up wanting to tear my hair out eventually.. I have not had similar issues with Composer.

No other language can even come close.

I mean I get it. It's obviously a counter-reaction to all the PHP hate that has been with every PHP thread for 2 decades, and much of it has been unfair, especially for the last 5 or so years. But please let's not swing the pendulum all the way to the other side.

For example, PHP is complicated enough that people use WAMP/MAMP.exe just for local development.

I think that advantage may have been real at one time, when FTP deploys were a thing. The myth loves on. Folks that chant this praise are often not be the same folks that have to maintain the webserver side of things, though.

Easy to deploy looks like this: ./foobar --port=80 > Listening on port 80, ready for traffic

That could be Go, could be Rust. But not PHP.

PHP webserver / application separation does bring some advantages - for example if you bring your application to a corrupted state or crash it, it will go and die. Recovery is, well "implied". But deployment wise, no.

It actually seems to be a LOT harder to run PHP that at first blush. Take this example: https://github.com/laravel/valet/issues/290

Turns out if you php-fpm app one Tuesday at 15:43 starts to write more than 4k to stderr (maybe it writes some nice verbose logs after being hit by some recoverable error), you will find yourself wondering what does "upstream sent too big header while reading response header from upstream" imply while your endpoint responds with 502. This is just one possible footgun .. ekhm .. tuning option.

And for modern development environments, deployment complexity usually comes from managing virtualized hardware and CI/CD pipelines, which is independent of whatever language your app is written in.

Nowadays with something like Heroku or App Engine, language has almost no impact on ease of deployment, and even custom deployments are pretty easy once you've practiced the docker/systemd script + apache/nginx proxy dance once or twice.

From my experience, a huge % of PHP companies started out with a Wordpress site, added a few features then a few years later they are now hooked and are doing things more seriously with Symfony or Laravel.

* Strong community

* Mature frameworks and libraries

* Simple hosting model

Not sure if you meant this, but now that I think about it, the "one process per request" model is actually legit differentiator that obviates a lot of the concurrency trouble new developers can get themselves into with other languages. It makes good performance harder in some cases (though there are workarounds), but overall it's maybe the one thing in PHP that I'd like to see other languages make some note of.

The hosting model - what you said, plus not needing to think about memory leaks. There are so many Java and .NET boxes out there that need to be rebooted every 2 hours because of some insidious bug that nobody on the team can solve. It's also pretty easy to put PHP in a container, and scale horizontally.

Has a decent track record for major version updates being easy to migrate to (even if many projects don't bother).

Works for quick and dirty bash-style scripting (not specially better than Phyton, but it does work).

Good.

Numeric literals can contain underscores between digits.

<?php 6.674_083e-11; // float 299_792_458; // decimal 0xCAFE_F00D; // hexadecimal 0b0101_1111; // binary ?>

PHP ....

... Doesn't ship with a production ready webserver. Yes, Python and Ruby also don't, but they have easy tools you can reach for (gunicorn, Puma) if you need to run them in a modern deployment stack where a whole nginx isn't really necessary.

... Doesn't have basic collection types in the core language. It's 2019 and PHP still thinks it's logical for the standard language to throw all Map, Set, List semantics into a single PHP array type. You can install the "phpds" native extension (and polyfill it from Composer) to get some passably usable implementations. But coming from Golang / Rust (or hell, even ES2015) I find them frustratingly limited.

... Doesn't have any sort of threading / async support. Even in a modest-scale webapp, this is going to hurt you when you want to do things like deploy PHP as a job queue handler. Or fan out even a trivial number of HTTP-client API calls from a PHP controller in a microservice-y world. The latter can be sort-of achieved with naive hacks like the cURL client concurrency support (Symfony HTTP-client supports it: https://symfony.com/doc/current/components/http_client.html#...) but that's a hack at best.

... Doesn't ship with a debugger out of the box. Even with great tooling like phpstorm IDE, you have to actually rub braincells together to be able to get xdebug installed / configured and ready to use.

... Has a somewhat decent package manager (Composer). But it doesn't ship with the language. Also, it's kinda crappy. It's painfully slow to do a composer install/update on anything larger than a toy project. It has all sorts of weird non-determinism issues (the composer.lock file flails around wildly between runs, changing case of metadata fields, etc).

... Has semi-decent static analysis tools (Psalm, phpstan), but they're pretty garbage compared to a proper compiler, or the quality of static analysis tools in other dynamic languages like Ruby / Javascript.

I could keep going. Profiling, code formatter, library ecosystem quality, and so on.

Where am I going with this? Honestly, I wish PHP would just die. It has some pros, but overall it's a terrible language that has no hope of modernizing enough to be relevant in 2019 and beyond. There's plenty of other excellent languages that do a better job in any category that PHP attempts to be good at. The effort being spent to maintain PHP as a language/runtime could be better spent on other languages that have made better choices in language design.

The developers who have become proficient in PHP, should continue to use their employable skills to maintain existing PHP codebases, but take a bit of time on the side to get proficient with another popular language if not already. And for the love of god, stop starting greenfields projects in PHP! Let it fade away peacefully.

    Javascript: $square = $x => $x*$x;
    PHP       : $square = fn($x) => $x*$x;

    $a=[fn($x)=>$x*2,fn($x)=>$x*$x];
    echo $a[1](5); // 25

Since we are talking about new features of PHP: Does anybody else wish there were named parameters?

I think PHP is pretty complete. It is my favorite language and I don't really wish for anything added to it. Except for two things:

1: The named parameters of Python:

    def paint(what,color='blue',tool='pen',layers=1)
        ...
    
    paint('house',tool='brush')

    city={name: 'Berlin', population: 3748000}

The fn() syntax was a non-conflicting alternative, which got most support for being not too weird.

[1] https://docs.hhvm.com/hack/functions/anonymous-functions

Bike shedding can certainly be done infinitely and sometimes one has to make a choice and move on.

(I have been release manager of PHP in earlier times and helped to steer through the namespace seperator debate and did the decision to not do short array syntax, yet, but wasn't involved in the short function syntax debate)

I'd love to have a shorter object syntax, too. For the time being, I'll make do with

    $city = (object)['name' => 'Berlin', 'population' => 3748000];

    $city = new City {name: 'Berlin, population: 374800};

https://www.reddit.com/r/PHP/comments/50xcmi/what_happened_t...

Perhaps php should also drop all type information so it can be more like the cluster fuck that is “modern” JavaScript too? Maybe change “const” so the constants it declares aren’t... constant?

There would be ambiguity without it: https://wiki.php.net/rfc/arrow_functions_v2#syntax

    $a=[$x ~> $x*2, $x ~> $x*$x];
    $a[1](5); // 25

Also PHP tries to be "googlable". Typing "fn PHP" into Google should bring relevant hits, for people never seen such a construct.

If not insisting on the "google" part, there always is http://symbolhound.com/?q=php+%7E%3E

[0] https://wiki.php.net/rfc/arrow_functions_v2#x_x_y1

What's the point of keeping this information around at runtime if you do all your type checks at compile time?

Based on this categorisation, Haskell for example isn't a strongly typed language, and yet Haskell's type checking is one of its biggest selling points, so this doesn't seem quite right.

It forces you to write input validation code that stays in sync with your types. Otherwise bad input can invalidate all your type guarantees.

Better than silently failing! + if code fails early as these type checks can enable, then bugs are often (not always) picked up just by running the code once.

At work I develop for both PHP and Java projects and... it's cumbersome to develop for Java projects, to say it nicely. Ever tried developing for Jira, Jenkins or enterprise CMSes?

Not to be a pedantic curmudgeon... actually, precisely to be a pedantic curmudegon... javascript does not require any of that.

The byzantine and asinine ecosystem that has sprouted like a cancer around javascript when SV and Node noticed the language and its profit potential, fueled by hype and unnecessary complexity? Yes. But the ecosystem is not the language.

Javascript itself is exactly like PHP in this regard - you edit a file, upload to the server, refresh the browser.

Everything else is unnecessary. Useful? Maybe. Bullshit? Probably. But not necessary.

That use case, the one for which the language was intended, does indeed work as described, and has for decades.

"strongly typed mainstream high level language" does not say anything about that, hence my question.

I've gone all-in on the Microsoft stack and have not regretted a single moment of this decision. If one can put aside the "big evil company ecosystem bad" argument for just a moment, I think it would be very difficult to say another ecosystem is superior in terms of actual time-to-market for your product.

And some of the best libraries which did exist were under commercial licenses! Which generally isn't an issue in other ecosystems.