PHP 7.4

php also has one: php -S localhost:8000 -t foo https://www.php.net/manual/de/features.commandline.webserver...

since 5.x (not production ready tough)

Unrelated to the topic but why the fuck do those people need to set 600 different cookies?

Actual webserver may not be useful but it would open the door to out of the box support for servicing websockets which currently requires using things like Swoole to achieve in PHP.

> A lot of those large web properties are going to be using old versions of PHP.

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/

we upgraded a 100k lines PHP 5 codebase to PHP 7.1 in a month. if your php 5 code wasn't using any deprecated extensions (like the old mysql extension) upgrading is really easy. there are static analysis tools that spot the potential problematic code so you don't need to do it by hand. from that point on if you got any automation testing or unit tests you can have a good level of confidence that your upgrade was a success.

Migrated a few million lines of code spread over a few apps in a couple of days to php 7. Most of the time was spent setting up docker and migrating unit tests. There were literally zero code issues. Those are properly written and engineered apps written on top of proper frameworks as any professional would write them. There is another app that depends on a php 5 library that's still running on php 5 now, three years later. So the upgrade situation is extremely easy and simple if your code isn't total shit. With shit code, the migration is the least of one's worries.

In my experience I only had real problems with projects built on outdated frameworks, like cake 1.3, because the framework was not compatible with php7, and upgrading to latest version of framework meant basically a full rewrite.

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.

Probably because they employed GvR from 2005 to 2012.

See above: Ruby is good, but it's on decline and IMO soon going to be a niche legacy language for projects too big to rewrite, like Github and Gitlab.

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.

Google does not care about python is not the same as Python being controlled by a small no of Googlers. I don't know much about whether that is true or not though.

I know almost nothing about Elixir short of there is a language with this name and it related somehow with Erlang. It's a very niche language/VM good for high-load realtime events processing, thus only noticable project on Elixir is Discord (and on Erlang - WhatsApp, Facebook Messenger and RabbitMQ, which kinda gives a hint too).

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.

... and it's been that way for a long time; we operate on consensus, and in 2014, non-Mozilla folks were added to the core team.

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.

What would you like to see instead improvement wise? The typing features are optional, so everything that makes PHP simple to use is still there and available.

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

> keep making PHP more and more like Java.

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 feature development is driven by a rather considerable commitee of core devs and representatives of major frameworks and libraries. All features are undergoing a voting procedure.

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.

> keep making PHP more and more like Java

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.

This is the correct answer. Having the option of implicit by-value scope binding is nice. However, I do agree that having the two does add to the overall cognitive cost, albeit not significantly.

This is a matter of the situation. For a single statement this can be extremely clear, if the function becomes longer being explicit is nice. And at some length the thing should have a name.

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

vs.

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

vs.

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

This is a problem in a lot of programming languages nowadays; they borrow features and syntax from other languages without those new features superseding others, and without providing a mechanism to force one syntax over the other.

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).

That’s a weird choice. Arrow functions in JS don’t redefine ‘this’ like regular functions, so if you don’t use them, you waste time working around the redefinition.

That would give syntactic ambiguity, since the => operator is also used to separate keys and values in array notation.

I think you're the first to point this out. Thank you so much; I just uninstalled php.

Use eloquent collections instead of vanilla arrays and you'll be much happier

That's exactly the intent of this change.

"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

Looks like they're optional anyway so you're free to do things however you like

Setters and getters aren’t really object oriented. An object has behaviour, ensuring the inner workings of that object are protected is a good thing _even if_ the inner workings are only ever inner workings. There’s lots of valid and meaningful uses of this functionality.

I'd say that depends on implementation; a lot of languages will only check types on compile. If anything it's a hint for developers, something that their editor will error on if they try and do something wrong.

Fair, though I'd say 1-3 are more or less matched by Java/.NET and probably NodeJS.

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.

These PHP praises frankly sound like trolling. No other language can even come close? You must be kidding.

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.

In the past I sort-of agreed and even chose PHP in a few instances when the project was tiny enough that ease of deployment was a major factor.

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.

All of that can easily be done in Node by setting up the appropriate scripts in the "scripts" section of the package.json file.

You would also need a properly configured Apache server wouldn't you? I can see the ease of deployment argument in the context of old-school shared hosting providers, but nowadays how is starting a PHP application any harder than Rails or Django for example.

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.

> PHP's value proposition has always been one thing - ease of deployment.

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.

I mean, it's no longer horrible I guess :)

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.

If you don't have to mess around with PHP extensions, then it all works like magic. Depending on your environment and which extensions you need though, they can be a pain in the ass and then it's more or less the same as managing external libraries.

Thanks for the link.

Underscores in numeric literals are also now pretty much a defacto standard. Java, JavaScript, Perl, Python, C#, Ruby, Rust, Swift, etc, all support it.

That would be great. I would also love it if TS supported runtime checks like PHP.

But does it have to be =>? How about ~>?

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

Looks cool to me.

I think there is an rfc for object initialization similar to C#:

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

Edit: found it (and it uses = instead of :) https://wiki.php.net/rfc/object-initializer

would like if they'd just change the syntax to foreach(something as k,v) or $arr = ['something':'value']... or then could use => ...or they could just use -> and change -> to . notation.. I use js a lot more lately so having it closer resemble es6 would make jumping back and forth easier.. I often start writing a json object when I want an associative array.

I wonder why they didn't use `==>`, which PHP alternatives like Hack[1] already use.

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

I copied a tweet because I was lazy to write another text. Honestly.

Maybe they prefer optional OO over mandatory or no OO?

At least for Java, PHP has the massive advantage of "change the code, save it and hit cmd+r" while Java, JavaScript and .net require recompiling, repackaging and deployment.

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?

C# + .NET Core 3.x + Blazor server-side. This is modern PHP.

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.

Continuing to run with unexpected type coercion bugs could be worse than bailing out. So, worse than compile time checking, yes. But not the worst.

This will help you find type errors if you have good test coverage without explicitly testing for types. Makes tests shorter.

You can use third-party tools to check ahead of time, and you can fall back on the PHP runtime to catch what can't be caught in advance.

> A program that fails with type errors at runtime instead of compile time is the worst of all worlds

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.

In practice, you don’t do all your type juggling at compile-time in even moderately complex libraries or applications. So TypeScript could certainly use better RTTI, I think. design:type metadata is insufficient.

Reflection is really useful. Right now the only way to differentiate types at runtime is testing for the existence of a key, which is kinda hacky.

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

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