Brent (stitcher.io)

Pick one framework between Symfony and Laravel and follow the docs. Maybe read https://stitcher.io posts about the new features since 8.0 to have a grasp of the language changes.

You are probably talking about this: https://stitcher.io/blog/generics-in-php-3 . If I remember correctly, the author claims it will either cause runtime overhead or extreme memory overhead. The best solution is to introduce a typed superset of PHP like TypeScript was done for JavaScript.

He wrote some decent articles before, and he might write some good ones in the future, but this right here, this ain't it. Unlike other "x in 2022" articles (for example https://www.ncameron.org/blog/rust-in-2022-2/), this one doesn't actually give any insight into the future of the language. Not only that, but there is no original content in it. He's simply repeating what he's been writing about for the past year. Maybe he should've called it PHP in 2021? Oh wait, he already did that (https://stitcher.io/blog/php-in-2021) and it's eerily similar to this article. If there is nothing new to write about, why write? I'm glad you bring up the PHP Annotated Monthly blog, it's a great resource and definitely one of the blogs to follow to keep up to date with PHP.

> There's a reason it took a decade to get projects onto python 3, but PHP can swiftly move the entire ecosystem from v5 to v7 in a year. PHP did well with v5 to v7. It took more than a year but your point is well made. The PHP v7 to v8 move is not as easy [1, 2, 3]. Not having Python 2 to 3 fresh in everyone's minds is one reason; not having failed PHP v6 is another. The breakages that led to the downfall of PHP6 made backwards compatibility a focus in PHP7. Since PHP7 was released the contributors/voices who favour backwards compatibility have left or been drowned out. The emphasis on supporting legacy code has gone. [1] https://stitcher.io/blog/new-in-php-8#breaking-changes [2] https://24daysindecember.net/2020/12/21/a-perfect-storm/ (recommended reading) [3] https://developer.yoast.com/blog/the-2020-wordpress-and-php-8-compatib…

Can always have a look at this https://stitcher.io/blog/evolution-of-a-php-object Latest code sample is at the bottom, covers a single specific use case (DTO) and it's still old as last update is november 2022. PHP in general has managed to had great feature while cleaning up and keeping true to its mantra of "it should be simple and easy". Modern PHP is super fun to use, and whether you like the verbosity and completeness of symfony, the "take a shortcut around the things you don't care so you can focus on your stuff" of laravel, the event based system of swoole or similar, the microframework like slim or just raw php, it's hard not to find a shoe that fit. What's notably funny is how they managed to do that without breaking bc, and how that is perceived highly depend on who is reading. Take switch(). The original php version of it is rather terrible in what it does in term of "programming language correctness", but it worked and had its use. At the same time, a clean one that did what was needed was really wanted. So instead of breaking every single software out there, making wordpress and company stuck on old version forever, they added a match(), which is a bit different and much cleaner. It's not really "the broken one and the good one", as their feature is different, but it's obvious that people who look for something bad will see that as terrible. In reality, you mostly don't use switch() in new code, but its behavior is fully described and documented.

Almost all, actually. I wrote about it here: https://stitcher.io/blog/11-million-rows-in-seconds A couple of things I did: - Cursor based pagination - Combining insert statements - Using database transactions to prevent fsync calls - Moving calculations from the database to PHP - Avoiding serialization where possible

You'll be able to use it in PHP 8.5 :-) https://stitcher.io/blog/pipe-operator-in-php-85

8.5 notably includes the new pipe operator: https://stitcher.io/blog/pipe-operator-in-php-85

I work on multiple projects from PHP 5.2 to PHP 8.3 and everything in between. Statistics based on packagist(composer) https://stitcher.io/blog/php-version-stats-january-2024 Statistics based on web servers in the wild https://w3techs.com/technologies/details/pl-php https://w3techs.com/technologies/history_details/pl-php

Even PHP has enums now and they are pretty cool: https://stitcher.io/blog/php-enums

Not the poster, but I've seen a couple of these which cite papers and research: https://stitcher.io/blog/why-light-themes-are-better-according-to-scie… https://medium.com/codesphere-cloud/should-you-really-be-coding-in-dar…

PHP 8.x vs 5.x is an order of magnitude performance increase [0] as long as you enable jit and opcache in php8 [1] [0]https://www.cloudways.com/blog/wordpress-performance-on-php-versions/ [1] https://stitcher.io/blog/php-8-jit-setup

Not as big a leap compared to 8.1 since Nikita left full-time development, but still a good trend. Lots of good changes to types (removing dynamic properties by default, redacted properties, readonly classes, more complex types etc). https://stitcher.io/blog/new-in-php-82

> It's pretty verbose, with lots of boilerplate We recently got constructor promotion which has been really nice https://stitcher.io/blog/constructor-promotion-in-php-8 > Installing extensions makes it difficult to configure environments. At least the way I do it, required extensions are just 1 line in a Dockerfile.

I use `match` like this a lot now, often with PHP 8.1's enums[1]. It makes it easy to write clean dynamic accessors, without all the extra blocks required with multiple `if` branches: /** Check the status of this Task instance. */ public function status(): Status { return match (true) { $this->inProgress() || $this->isInReview() => Status::Started, $this->isApproved() || $this->isRejected() => Status::Finished, default => Status::Planned, }; } [1] https://stitcher.io/blog/php-enums

See Preloading which landed in PHP 7.4 https://stitcher.io/blog/preloading-in-php-74

Updated in January but not really up to date. It doesn't mention union types, the nullsafe operator, matching expressions and a lot of other features you can find here: https://stitcher.io/blog/new-in-php-8 Maybe not everything is "the right way" but at least the nullsafe operator is, I think.

It's nice to see PHP adding useful things like enums and async (green threads). My foray into Web development started with Perl, but quickly segued into PHP with how much simpler it felt. The ability to hop into vim on your server (or use CPanel back in the day) and edit your site live was exciting back then – but now that very thought makes me shudder with what could go wrong, haha. While I've moved onto JVM languages and Rust professionally, I do hope PHP will continue getting future generations excited about Web development and building out their ideas quickly. FYI: Not sure if the author will see this but some spelling mistakes in the article. [0] E.g. s/reslease/release/ 0. https://stitcher.io/blog/php-in-2021#the-community

Finally, after all these years, Named Arguments! https://stitcher.io/blog/php-8-named-arguments

Maybe the article means that PHP interprets the OPCodes as opposed to java that uses a JIT compiler that produces machine code for part of the bytecodes. Anyway JIT is coming with PHP8 : https://stitcher.io/blog/new-in-php-8

Article with an overview of the changes: https://stitcher.io/blog/new-in-php-8 Some highlights are union types, a JIT compiler, named arguments, annotations, and match expressions. The approach to named arguments is interesting. It's nice that you don't have to change the signature of existing functions, but the downside seems to be that you can't enforce the usage of named arguments on callers, as in other languages like Ruby and Python where keyword arguments need to be declared as such. function foo(string $a, string $b, ?string $c = null, ?string $d = null) { /* … */ } foo( b: 'value b', a: 'value a', d: 'value d', );

The only benchmarks done before adding it to the core were on maths-heavy code samples, something PHP is seldom used for. You can read about it here: https://stitcher.io/blog/php-jit

Objects are enforced and a simple declaration can make PHP enforce the scalars as well. https://3v4l.org/6UU2v https://3v4l.org/q1PAq In PHP 7.4 due in a few weeks covariant return types / contravariant arguments will arrive. https://stitcher.io/blog/new-in-php-74#improved-type-variance-rfc

Aside from the LLM smell, the most egregious thing about this article to me is simply implying that it's going to be much of a surprise to people that PHP has improved since the "fractal of bad design" days. The most popular Hacker News post that matches "php" in HN Algolia is this post from 2019: https://stitcher.io/blog/php-in-2019 https://news.ycombinator.com/item?id=19917655 And while sentiment is understandably mixed even then, I actually think a lot of people have already come around on PHP as being "not as bad as it once was", if not even "good". Some of its reputation, though, hinges not on out-of-date internet commentary, but instead on the fact that in practice a lot of the PHP code that's still in production today is simply legacy code and not up to modern standards, and most of the time when someone says PHP, they really mean that PHP. I think that is actually the thing that is holding PHP back hard outside of bubbles like HN. And honestly, even though I don't hate modern PHP, I don't have many codebases that come to mind when I think about modern PHP that are exemplary. I actually was relatively impressed with the s9e TextFormatter library used by phpBB3 when I looked at it, but even that is dated by today's standards. Still, I think that PHP has an undeservedly bad reputation relative to other languages. I've recently come back into Python lately after having not really touched a ton of Python in a while and I gotta say, other than `uv` and `ty`, I don't…

Counterpoint (from the same website): https://stitcher.io/blog/evolution-of-a-php-object PHP 8.2 has this: ``` readonly class BlogData { public function __construct( public string $title, public State $state, public ?DateTimeImmutable $publishedAt = null, ) {} } ``` Whereas in php 5.6, to accomplish the same you need all this: ``` class BlogData { /* @var string / private $title; /** @var State */ private $state; /** @var \DateTimeImmutable|null */ private $publishedAt; /** * @param string $title * @param State $state * @param \DateTimeImmutable|null $publishedAt */ public function __construct( $title, $state, $publishedAt = null ) { $this->title = $title; $this->state = $state; $this->publishedAt = $publishedAt; } /** * @return string */ public function getTitle() { return $this->title; } /** * @return State */ public function getState() { return $this->state; } /** * @return \DateTimeImmutable|null */ public function getPublishedAt() { return $this->publishedAt; } } ```

I've been using PHP professionally since ~1999. I remember ripping the Perl fanboys in the early 2000's until the foundations of PHP started to crumble with what are issues that stick in peoples minds today; so I do wonder if we brought it on ourselves sometimes. But PHP moved on carefully to preserve backwards compatibility. I still have a SaaS first developed back in 2005 on the latest version of PHP that's happily ticking over with the minimal of maintenance required - the code base is horrendous but that's because a developer I had with me at the time made a massive case for "software design patterns" that he crowbarred into every nook and cranny regardless of if it was required or not. I've done things with PHP that would give people nightmares. It's a far more capable language [1/2] than most realise and with version 8 bringing us JIT things just keep getting better. Would I use PHP if I was starting out today? Unlikely, but I know PHP inside out and can wield it to my wicked ends with ease so won't be dropping it anytime soon. [1] https://stitcher.io/blog/php-in-2019 [2] https://stitcher.io/blog/php-in-2020

Honestly most of what you consider to be good or bad is a personal preference. But what I can say for certain is that framework-less modern PHP is 10x less ugly/complex and an order of magnitude more performant. There are a ton of new language constructs and features which puts it on par with, if not ahead of, most other languages. Here are some of the most recent feature additions: https://stitcher.io/blog/new-in-php-8 https://stitcher.io/blog/new-in-php-81 https://stitcher.io/blog/new-in-php-82 https://stitcher.io/blog/new-in-php-83 If you're looking for some fun content to watch about PHP while eating dinner: https://www.youtube.com/watch?v=WsnHWxO7Krw

Don't forget, much of that effort has now trickled down into the PHP language itself. We've long had scalar types for function parameters and return values, but with 7.4 and 8.0 we've added union types[1], nullable types[2], and typed properties[3]. While not a part of the language yet, generics can be annotated with the linting tools PHPStan and Psalm[4], and native support for these annotations is coming to the next release of PhpStorm[5]. Using PhpStorm, I've worked with 100 kloc PHP codebases where almost every type was inspectable. And the language support and tooling are only getting better all the time. 1: https://stitcher.io/blog/new-in-php-8 2: https://www.php.net/manual/en/migration71.new-features.php 3: https://stitcher.io/blog/typed-properties-in-php-74 4: https://phpstan.org/blog/generics-in-php-using-phpdocs 5: https://blog.jetbrains.com/phpstorm/2020/07/phpstan-and-psalm-support-…