PHP 8.5

2025-11-206:07241189stitcher.io

A blog about modern PHP, the web, and programming in general. Follow my newsletter and YouTube channel as well.

Written on 2025-11-20

PHP 8.5 was released on November 20, 2025. It includes the pipe operator, clone with, a new URI parser, and more.

The pipe operator

PHP 8.5 introduces the new pipe operator that makes chaining output from one function to another a lot easier. Instead of deeply nested function calls like this:

$input = ' Some kind of string. '; $output = strtolower( str_replace(['.', '/', '…'], '', str_replace(' ', '-', trim($input)
        )
    )
);

You can now write this:

$output = $input |> trim(...) |> (fn (string $string) => str_replace(' ', '-', $string)) |> (fn (string $string) => str_replace(['.', '/', '…'], '', $string)) |> strtolower(...);

I've done a deep-dive into this new operator, and you can read about it here.

Clone with

There's now a way to assign new values to cloned objects while cloning them:

final class Book
{ public function __construct( public string $title, public string $description, ) {} public function withTitle(string $title): self { return clone($this, [ 'title' => $title,
        ]);
    }
}

I think this is a great feature. The only thing I find unfortunate is that it doesn't work when cloning readonly properties from the outside (which I think is a common use case). To do so, you have to specifically reset the propery's write access to public(set). I explained the problem here.

(void) cast and #[NoDiscard]

You can now mark a function with the #[NoDiscard] attribute, indicating that its return value must be used. If nothing happens with that return value, a warning will be triggered.

#[NoDiscard("you must use this return value, it's very important.")]
function foo(): string { return 'hi';
} foo(); $string = foo();

The warning can still be surpressed by using the new (void) cast:

(void) foo();

Closure improvements

Closures and first-class callables can now be used in constant expressions. In practice this means you'll be able to define closures in attributes, which is an incredible new feature:

#[SkipDiscovery(static function (Container $container): bool { return ! $container->get(Application::class) instanceof ConsoleApplication;
})]
final class BlogPostEventHandlers
{  }

Note that these kinds of closures must always be explicitly marked as static, since they aren't attached to a $this scope. They also cannot access variables from the outside scope with use.

Backtraces for fatal errors

A small but awesome change: fatal errors will now include backtraces.

Fatal error: Maximum execution time of 1 second exceeded in example.php on line 6
Stack trace:
#0 example.php(6): usleep(100000)
#1 example.php(7): recurse()
#2 example.php(7): recurse()
#3 example.php(7): recurse()
#4 example.php(7): recurse()
#5 example.php(7): recurse()
#6 example.php(7): recurse()
#7 example.php(7): recurse()
#8 example.php(7): recurse()
#9 example.php(7): recurse()
#10 example.php(10): recurse()
#11 {main}

Added array_first() and array_last()

Perhaps a bit overdue (array_key_first() and array_key_last() were added in PHP 7.3), but we finally get built-in functions to get the first and last elements from arrays! So instead of writing this:

$first = $array[array_key_first($array)] ?? null;

You can now write this:

$first = array_first($array);

URI parsing

There's a brand new URI implemention that makes working with URIs a lot easier:

use Uri\Rfc3986\Uri; $uri = new Uri('https://tempestphp.com/2.x/getting-started/introduction'); $uri->getHost();
$uri->getScheme();
$uri->getPort();


The #[DelayedTargetValidation] attribute

Some built-in attributes (like #[Override]) are validated at compile-time rather than at runtime when being called via reflection. The #[DelayedTargetValidation] allows you to postpone that validation to a runtime:

class Child extends Base
{ #[DelayedTargetValidation] #[Override] public const NAME = 'Child';

	
}

This attribute is added to manage backwards compatibility issues. You can read a concrete example here.

Smaller changes

Deprecations and breaking changes

Those are the features and changes that stand out for PHP 8.5; you can find the whole list of everything that's changed over here.

What are your thoughts about PHP 8.5? You can leave them in the comments below!

Things I wish I knew when I started programming cover image

This is my newest book aimed at programmers of any skill level. This book isn't about patterns, principles, or best practices; there's actually barely any code in it. It's about the many things I've learned along the way being a professional programmer, and about the many, many mistakes I made along that way as well. It's what I wish someone would have told me years ago, and I hope it might inspire you.

Read more


Read the original article

Comments

  • By inovica 2025-11-209:244 reply

    I still love PHP. 23 years ago we created some encryption software for it and it is still going. I also run a PHP newsletter. There's still a strong community of people and whilst there are other languages which I also use (Python, Node.js) I still find myself gravitating towards PHP for fast and simple work

    The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since the launch of PHP 5 and so it isn't as easy to understand from scratch as it used to be

    • By LexiMax 2025-11-2019:231 reply

      PHP is a perfect example of how to undergo major transitions correctly.

      In the time that it took Python to go from Python 2 to 3, PHP underwent 5.2 -> 5.3 and 5.6 -> 7.0. 5.3 changed how you write PHP in a fundamental way by introducing namespaces and PSR0 autoloading. Then, 5.6 -> 7.0 cleaned up the parser, resulting in massive speed improvements.

      They did this by not breaking the universe in these major updates...or really, any of there updates. Each update would break a few specific things, warn you about a few other things that were going to break in the near future, while giving you ways to shim the old behavior if you _really_ needed it.

      They also gave you ample carrots reasons to update - aside from what was already mentioned, my personal favorite update was PHP 5.4 because it introduced short array syntax, made UTF-8 the default charset, introduced traits, and finally put register globals and magic quotes out of their misery...but giving you a shim if you had some ancient project that needed it.

      If you're wondering why PHP 6 was abandoned, it was because it was an update in the style of Python 3 by breaking strings everywhere. In retrospect, I think the decision to cancel 6 was the right one. Somehow, I doubt that PHP would've had the influx of data science and AI that saved Python 3.

      Hats off to the project - I've long been off of the CGI-style web development narcotic, but the language put food on my table for quite some time, and the people steering the language treated their community well.

      • By oconnor663 2025-11-2020:211 reply

        > They did this by not breaking the universe in these major updates

        I don't think the amount of breakage per se was the problem with Python 3. I think the problem was that for a long time (until u"" strings in 3.3? four years after 3.0?) there was ~no way for a library to support both 2 and 3 in a single codebase. That meant that each project had to either maintain a fork, or do a "flag day" migration, which in practice meant you couldn't migrate until all your dependencies were migrated. Big mistake in retrospect.

        • By deanishe 2025-11-217:10

          > I don't think the amount of breakage per se was the problem with Python 3.

          The lack of u"" is just another manifestation of the complete breakage they wrought upon Python's string handling, isn't it?

          It was closer to a decade (3.7) till they'd put enough of the bits they'd ripped out back in for Py3 to be suitable for the things I used Py2 for.

    • By matula 2025-11-2015:341 reply

      I've seen a few other comments also talk about PHP becoming more complex. However, I have "simple" code built using 5.3 and it works perfectly fine in 8. So I guess it CAN be complex, but doesn't really need to be. The biggest changes I would make to that code are fixing the multiple 'switch' and 'if/else' blocks to an anonymous function or some mapping... but it's not required.

      • By jaredklewis 2025-11-2018:50

        This is true. As long as only one person interacts with the code, all languages can be simple. C++ can be simple.

        But once multiple people are involved and I have to read someone else's code, then I really start to appreciate languages with less features. There are some language I love to write code in, like Ruby or Haskell, where I feel like a damn genius when I write it, but want to pull my hair out when I have to read someone else's code.

    • By dijit 2025-11-2011:56

      > 23 years ago we created some encryption software for it

      ZEND?

      I remember "nulling" software in the mid-00's and Zend was always a terrible ball-ache.

      Which, if that was your project, is high praise. :)

    • By johnisgood 2025-11-2014:06

      I think PHP 8 is easy to understand if you write it from scratch, you just have to learn doing things the right way, read up on PSRs and so on. It is a bit more complex but much more secure and supports quite a lot of things now that are definitely helpful to have.

  • By darkamaul 2025-11-209:1612 reply

    PHP's evolution since PHP 5 has been substantial, and I think this is a real problem. As someone who learned the language years ago, the pace of change (generics, attributes, match expressions, typed properties) makes modern codebases genuinely difficult to follow.

    I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for the community but a barrier to re-entry.

    • By gramakri2 2025-11-209:341 reply

      IMO, newer PHP is still very readable. I programmed with C++ for a decade, but I can safely say that I cannot understand a modern C++ code base anymore.

      • By idoubtit 2025-11-2015:272 reply

        Are the new features really readable? I have no idea what this code from the OP is meant for:

            #[SkipDiscovery(static function (Container $container): bool {
                return ! $container->get(Application::class) instanceof ConsoleApplication;
            })]
            final class BlogPostEventHandlers
            { /* … */ }
        
        As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#". See https://wiki.php.net/rfc/closures_in_const_expr

        • By TimWolla 2025-11-2015:471 reply

          The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.

          Given that the cat effectively is out of the bag, does the example on the release page (sneak preview) make more sense to you: https://www.php.net/releases/8.5/en.php#closures-in-const-ex...?

          > As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#"

          Yes, unfortunately the off-the-shelf software of the Wiki uses a custom-built highlighter instead of the `highlight_string()` function that is bundled with PHP: https://www.php.net/manual/en/function.highlight-string.php

          • By rafark 2025-11-2116:30

            > The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.

            Clout.

        • By attendant3446 2025-11-2019:35

          I'm glad it's not just me who finds the syntax of some of the new PHP features confusing and complicated. And it's not just this version either, they keep adding weird "sugar" in each new release.

    • By johnisgood 2025-11-209:391 reply

      I think PHP is way better now than it used to be. Learn PHP 8 and you are good to go.

      • By erickf1 2025-11-2014:503 reply

        Until two years later the same thing is said about PHP 9, 10, 11. Constant change is not good.

        • By johnisgood 2025-11-2015:08

          People still complain about PHP saying how it is not secure at all, how shitty of a language it is, and so on, because they are stuck at PHP 5. Everyone should just start from PHP 8.

          I have no clue what the future brings for PHP, but PHP 8 is definitely a good start, and we should put PHP 5 to rest.

          PHP 10 might not be that different from PHP 8 for all I know.

          We do not know if there will be "constant change". Out of curiosity, what programming language do you use that you also love?

          FWIW, if by "constant change" you mean improvements or bug fixes, then I do not see why we should not have those. I do not even mind breaking backwards compatibility if the reasons for breaking justifies it, but it has to be a really good reason.

        • By kyriakos 2025-11-2019:16

          It gets updated but breaking changes are not that many and always well justified. Most breaking changes I've seen the past decade only broke if your code was already bad relying on non standard ways of using language features. There are tools that help with migration.

        • By tedd4u 2025-11-210:01

          People also hate how _slowly_ Python moves and complained forever about that. They also complained forever during the many years of 5.x PHP releases that PHP was moving too slow. It was only after Facebook forked first the runtime (HHVM) and the language (Hacklang) and showed how fast and advanced PHP could be made that the PHP team started accelerating. Which I think has been a boon to the community. This is all given away for free as open-source after all.

    • By segmondy 2025-11-2014:151 reply

      It's a real problem with almost all software today, nothing ever gets done. they just keep piling unto it no matter how great it was. the idea of simplicity as a goal and feature is lost on this generation.

      • By tim333 2025-11-2015:172 reply

        Simplicity may often get ignored but I think it's been a big reason for Python's success which has gone from about #10 on the TIOBE language list to #1 since when I started learning it, which was probably around when the XKCD "everything is so simple" cartoon came out. (https://xkcd.com/353/)

        • By okeuro49 2025-11-2015:402 reply

          Doubtful it is anything to do with simplicity.

          Python's success is explained by it being the language of choice for AI.

          • By aj_hackman 2025-11-2119:36

            Python has been massive since the 2000s. When AI rolled around, it was already there, a bunch of people knew it, and it was Good Enough (tm).

          • By graemep 2025-11-2019:23

            I think its the other way around. Python became the language of choice for AI because it was already popular. Lots of things made it popular: use for systems management scripts, web apps (Django, especially), then numerical stuff,...

            I think the reason is that it is easy to learn enough to get things done, but it is very flexible, very readable, and once the ecosystem started gaining momentum (which it clearly had by the time of the XKCD cartoon) that became an advantage too.

        • By segmondy 2025-11-2015:25

          I have been programming in python since the 90's too. The success IMO is still that it retains the simplicity and CFFI. Moving up TIOBE is more of CFFI and the ecosystem.

    • By danaris 2025-11-2015:34

      I dunno; I started with PHP 5 (actually, I think I started in late PHP 4), and I've only been happy with the changes as it's evolved.

      The only one that's caused me any significant stress is the deprecation of the old `mysql` DB interface; I had to refactor a whole bunch of code for that, since I'm maintaining a codebase that's been in continuous use & development since 2001.

      The additions to PHP since 5 add more things you can do, but they don't really change the simple things you can do to first learn PHP. You can still just create a .php file and start interspersing HTML and <?php script tags with basic operations.

    • By woodrowbarlow 2025-11-2013:48

      but would you even be considering re-entry if it hadn't improved dramatically?

    • By jm4 2025-11-2014:00

      To be fair, that’s true of many languages and programming domains. The web, in particular, is one where you have to keep pace or end up out of the field.

      Java and C# are a couple other popular languages where the same is also true.

    • By ivolimmen 2025-11-2011:08

      Most likely this can be said about a lot of languages, most languages are being maintained and improved. I am an hired expert in Java and I needed to explain some new languages features to some colleagues that have been introduced recently, I only mention them if they actually improve readability though. I think PHP might be slightly different than other languages as a huge amount of people use this to create their first website as a hobby.

    • By pjmlp 2025-11-209:542 reply

      This is true for most languages though, compare C# 14 with C# 1.0, Java 25 with Java 1.0, C 23 (plus common compiler extensions) with K&R C,....

      • By deaddodo 2025-11-2010:564 reply

        C hasn’t changed all that much, and someone who coded in C99 would take about 30mins to catch up to a modern C23 codebase’s changes. Famously so, as conservatism to change is the main friction in the community for about two decades now.

        If you pull out examples of the earliest C, sure, it looks weird. But that C was already obsolete in 1989. Since then, it’s had a minor iteration (e.g. five-eight additions/modifications) every decade-ish (99, 11, 17, 23). Has it changed? Sure. Can it be compared to the iteration and speed of things like C#, Java, C++, etc? No way.

        • By array_key_first 2025-11-2015:171 reply

          C, as a language, is very simple. Which leads to horribly complex and monsterous code, especially in large projects. The language makes even simple paradigms impossible to represent, forcing you, instead, to just remember what to do and then do that every time, forever.

          • By deaddodo 2025-11-215:05

            I made no value judgement of the language. Simply an assessment of its simplicity. I’m glad you agree with that. Feel free to let the other commenters know, not me.

        • By pjmlp 2025-11-2012:201 reply

          I am quite sure many people would fail Pub Quizzes related to C, when taking into account the whole language alongside compiler extensions, regardless of the compiler.

          • By deaddodo 2025-11-2012:562 reply

            To learn all of the common GCC and MSVC extensions would make up a fraction of the language features of C# or Java. You’re really overstating the complexity to make some invalid point.

            “Actually, one of the most notoriously conservative and simple (in feature set) languages is really super complex and has evolved a ton because it has _Generic and varargs now, and __packed__ exists as a compiler feature.”

            And to further double down, that minor evolution is over 36 years (arguably a decade longer, but I’m being generous with your argument). Not the 12-16 years (depending which 5 point release you wanna start with) that PHP has morphed into an entirely different language.

            • By pjmlp 2025-11-2014:221 reply

              A pub quizz would consider more than GCC and MSVC, and still I would bet many would fail if talking only about those two.

              And I would double down on my bet regarding ISO C related questions, as I have met a few folks that contrary to myself as language nerd, hardly know what is written there or have even opened the PDF drafts at least once in their life.

              • By deaddodo 2025-11-2014:291 reply

                [flagged]

                • By pjmlp 2025-11-2015:471 reply

                  It definitely is, because we are discussing knowledge of programming languages specification across their whole lifetime.

            • By johnisgood 2025-11-2014:08

              Yeah, it does not take a long time to learn GCC / Clang extensions, IMO. Have an LLM give you a list of these with examples, really. :P

        • By rini17 2025-11-2013:291 reply

          You can learn everything about undefined behavior in 30mins?

          • By deaddodo 2025-11-2014:111 reply

            It's moot to the aforementioned point. Undefined behavior wasn't introduced as a new language "feature" between C89 and C23; it's existed the whole time. We're talking about specification deltas, not the entire corpus.

            But, if you want an answer to your question:

            You can learn to avoid undefined behavior in about 30 seconds.

            If you're purposefully fiddling with undefined behavior, it's because (ideally) you're A) an advanced developer and you know exactly what you're trying to achieve (and inspecting the generated code) and/or B) you're using a specific compiler and don't plan on porting your code elsewhere.

            • By rini17 2025-11-2018:342 reply

              Before you could assume signed arithmetic overflow will be whatever the CPU does, or null pointer derefs will be trapped by the OS. That is pretty big difference from what can happen now, moved C away from that "portable assembler" moniker so very not moot. Even if it was never explicitly standardized.

              > You can learn to avoid undefined behavior in about 30 seconds.

              Source? I mean, if it's really that simple then someone already compiled that 30 second advice and you can simply link it here for us. Ideally including examples how to actually do signed arithmetic safely. You can't avoid negative numbers lol.

              • By jasomill 2025-11-2116:511 reply

                Before you could assume...null pointer derefs will be trapped by the OS

                Before when?

                  Microsoft(R) MS-DOS(R) Version 6.22
                               (C)Copyright Microsoft Corp 1981-1994.
                  
                  C:\TMP>type foo.c
                  void main() {
                      long q = 0;
                      q = 0/q;
                  }
                  
                  C:\TMP>cl /Od foo.c
                  Microsoft (R) Optimizing Compiler Version 5.10
                  Copyright (C) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights reserved.
                  
                  [...]
                  
                  C:\TMP>foo
                
                  run-time error R6003
                  - integer divide by 0
                  
                  C:\TMP>type bar.c
                  void main() {
                      long far *p = 0;
                      long q = 0;
                      *p = 0;
                      q = 0/q;
                  }
                  
                  C:\TMP>cl /Od bar.c
                
                  [...]
                
                  C:\TMP>bar
                (system hangs)

                • By rini17 2025-11-2122:17

                  In DOS you always had to manage your expectations, not sure what you're trying to prove here?

              • By deaddodo 2025-11-215:041 reply

                [flagged]

      • By ffsm8 2025-11-2010:321 reply

        I think he's thinking more along the lines of PHP 5-8.5

        That version 1-latest is understandingly highly different, but these are all decades old languages, which barely changed for some time, but are now all introducing new syntax.

        Which I think makes sense, but it's obviously going to leave 9-5 devs behind that don't particularly care for coding and want to invest as little time as possible into their language knowledge.

        • By rytis 2025-11-2011:242 reply

          And what exactly 9-5 has to do with caring for coding or time investment in language learning?

          • By ffsm8 2025-11-2018:38

            A person that cares for coding will inevitably code more then 9-5 and consequently get familiar with new syntax

            A person that invests time into their language knowledge will not have issues handling new syntax because they spend as much time as necessary to get familiar with the new syntax

            So the criteria is being a 9-5 who doesn't particularly care about coding and doesn't invest time into their language knowledge

          • By monooso 2025-11-2013:16

            Not GP, but I assume the suggestion is that it's difficult to stay abreast of new developments within the constraints of a typical work day. Especially if your job utilises older technologies, as most do.

    • By Capricorn2481 2025-11-2017:22

      I work on projects from PHP 5.6-8.4 and I can't say it feels that different. It's mostly just type differences.

      But PHP 5 was released 21 years ago and is unsupported. Companies using it are putting their customers at risk.

    • By _DeadFred_ 2025-11-2017:181 reply

      I used laracasts.com plus AI code assistants to bring myself back up to speed pretty quickly.

    • By tehbeard 2025-11-2015:14

      You can still write php 5-esque slop and have it run... mostly (some particulars like the half dozen ways of interpolating a variable into a string have been paired down, some extensions left in the dustbin, but the fundamental "shit out a script and run it" capability still remains doable).

      non of the "modern" things are particularly taxing to teach someone with more than two braincells. If they don't understand them then they haven't kept up with ANY programming trends in the past decade and are best placed infront of the TV with an iPad than left to mess with the possible critical infrastructure of a business.

    • By phplovesong 2025-11-209:383 reply

      PHP has no generics? I read somewhere that is was "too hard" to get right in PHP land, mostly because of how primitive the typesystem is.

      • By deaddodo 2025-11-2011:151 reply

        It has nothing to do with being “too hard”, and everything to do with not making sense to the type system. PHP is weakly-typed and heavily reflection-based (so everything is aware of it’s and each other’s type at all times).

        Adding generics to PHP would make CS fundamentalists somewhat happy, but do nothing to change the fundamental design of PHP nor offer any of the traditional benefits that generics offer to strongly-typed and compiled languages. And would be a massive headache to implement, while bulking an already heavy VM implementation.

        • By phplovesong 2025-11-2012:364 reply

          > And would be a massive headache to implement

          Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen.

          > Adding generics to PHP would make CS fundamentalists somewhat happy

          PHP has really only one collection datatype (the infamous array), so having generics would be tremendously useful, as an example you cant return an typed array from a function, witch is just really bad.

          For an counter example, Python managed to do this, while also being a dynamic language, although having a stronger typing than PHP.

          • By duckerude 2025-11-2014:381 reply

            Python managed to do this by not actually checking the types at runtime. If you declare a list[int] return type but you return a list[string] then nothing happens, you're expected to prevent that by running an offline typechecker.

            PHP chose to check types at runtime. To check that a value is really an array<int> the runtime could have to loop through the entire array. All the types PHP currently implements are simple and cheap to check. For more elaborate cases you need an offline checker like PHPstan and comment-based type annotations. (PHPstan catches 99% of issues before the runtime gets to it so for my own code I'd prefer the Python approach with its cleaner syntax.)

            The runtime checking seems the key difference, not so much the historical strength of the type system. Python's language implementation does very little typechecking itself and PHP's third-party offline typecheckers are respectably advanced.

            • By phplovesong 2025-11-2015:532 reply

              Precisely. PHP has tools for this too, but lack the syntax. Right now you need to to all typings in comments, and thats just as bad as jsdoc was in 2005.

              This could be the way PHP could go, they just need the lexer to handle types, and not do any runtime checking at all.

              But i guess that goes against what the php devs want, but it sounds so wasteful, to typecheck the same code time after time even if it passed some sort of initial "compile time step".

              • By duckerude 2025-11-2016:161 reply

                The current amount of typechecking might be a net efficiency improvement AFAIK. It provides a hard runtime guarantee that variables are certain types while Python has to check whether something is supported at the last possible moment. But I don't know how much use the optimizer makes of that.

                • By phplovesong 2025-11-214:57

                  Python is not (usually) run like PHP. Python programs (like most other languages) "run", compared to PHP where you in 99% of all cases instead "execute". (run = the program is running for a long period of time, and execute = run/die immediately).

                  This subtle difference has huge implications. You could in theory have an "compile step" in. Python, but in PHP you really cant as the program is never "running".

                  Python built syntax for types / generics etc. Its actually a quite capable typesystem (im not a python developer, but use python on some occasions). Python then has tools for static typechecking that can be run outside execution.

                  This means that if python would do actual static typechecking on runtime it would be nothing more than wasted cpu cycles.

                  Thats why python opted for the syntax only, as its basically zero cost. In php land the typechecking is done on EVERY execution, even if the code was unused. (a void functions that has an int param, but gets passed an string, that just discards the parameter). Even worse, a type error thats not executed wont be caught by every execution.

                  In short PHP typesystem is just runtime checks for primitives / classes and wont catch errors where not executed. Its like the worst of both worlds.

              • By johnisgood 2025-11-218:43

                > Right now you need to to all typings in comments

                What do you mean by this? The types of variables in PHP >8 are not in comments. Or did I misunderstand something?

          • By danaris 2025-11-2015:391 reply

            > you cant return an typed array from a function, witch is just really bad.

            Why is it bad?

            In particular, why is it worse than not being able to declare a typed array in your current scope? (I understand the basic argument in favor of typed arrays, but I also understand why PHP would choose not to go that route; I'm not sure I see how it's worse to not be able to return one from a function, given that they don't exist elsewhere.)

            • By phplovesong 2025-11-2015:561 reply

              I often return some collection of types in an array eg [User, Config]. Right now my return type is just "array". To get this to work i need to build yet another wrapper class and all that, and thats just wasteful and totally unnecessary.

              A even more simpler example is An array of some sort of Item. I cant return array(Item), but i only can return an array.

              • By danaris 2025-11-2017:101 reply

                What do you mean, "to get this to work"? It's a PHP array. It will return whatever you need it to.

                What is not working?

                • By phplovesong 2025-11-214:591 reply

                  The parts thats not working is if i return a plain "array" i can then put whatever inside it. Its basically the same as "any" but wrapped inside an array.

                  • By danaris 2025-11-2113:53

                    Sure.

                    But that is no different than if you created the array in that scope.

                    So, again: Why is it "really bad" that you can't return a typed array from a function? What is worse about that than not being able to create a typed array in the current scope?

                    Also: What, exactly, about that is "not working"? As I said above, I understand the basic arguments about typed arrays; they're conceptually equivalent to weak/dynamic types. And there is value in having strong and static types. But it's hardly a showstopper not to, and PHP works just fine even if you don't use any. It just...makes it easier for us, as programmers, to make mistakes.

                    So to say it's "not working" simply because it's possible to add elements to the array that don't match the types you want seems like an exaggeration.

          • By array_key_first 2025-11-2016:181 reply

            PHP typing is most definitely stronger than python overall.

            Yes array is the evil collection type of everything, but that's how it's meant to work. Array is the quick and dirty 'throw everything in there' thing. PHP has classes and they're very full featured and offer lots of type safety - use those.

            • By phplovesong 2025-11-216:551 reply

              > PHP typing is most definitely stronger than python overall.

              LOL, no its not. PHP has an weak type system, while python is strong. Both are dynamic.

                  $sum = 10 + "50"; // 60 in PHP
                  sum = 10 + "50"   // TypeError in python

              • By array_key_first 2025-11-2114:171 reply

                I mean from a static analysis perspective - type annotations in PHP actually do stuff, and you can type annotate pretty much everything. And people actually do it.

                Also, you can just flip on strict typing in PHP, and you should know that.

                • By tuqqu 2025-11-2118:121 reply

                  Strict types determine whether a function accepts a variable of a certain type, casts it, or throws a TypeError. It does not affect int + string operations or anything else really

                  • By array_key_first 2025-11-224:39

                    Kind of but not really. Even without strict types, functions will throw a type error if you give them the wrong thing for almost all types, except primitives, which will be automatically coerced. Strict types turns that coercion off.

                    Really, that's probably enough for a lot of cases, because PHP doesn't have operator overloading. Yes, you can add '10' + 10 and get 20, but not if either of those go into any function. If you have a function that needs to do string stuff, you take string stuff in, and you don't have to worry about string operations or coercing ints or anything.

      • By senfiaj 2025-11-2014:02

        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.

      • By dreadnip 2025-11-2011:101 reply

        If you're interested about generics in PHP, you can read this blog post by the PHP foundation: https://thephp.foundation/blog/2024/08/19/state-of-generics-... or this PR by Nikita: https://github.com/PHPGenerics/php-generics-rfc/issues/45.

        TLDR: The PHP compiler isn't really suited for the job, it would introduce a lot of complexity to an already complex codebase and the memory/performance hit would be substantial.

        • By phplovesong 2025-11-2012:39

          Yup, this was pretty much what i recalled. The typesystem, while being incredibly "unintelligent", somehow still is so complex that generics are not going to happen.

  • By calpaterson 2025-11-207:167 reply

    A lot of people are too proud to be associated with PHP. I am ready to admit that know nothing about the language except that a lot of people make cool things with it.

    My favourite PHP product at the moment is BookStack (https://www.bookstackapp.com/), a really good wiki. I run an instance for my family and it's great.

    But there are loads of things. And I notice that many of the sites I like using...are built on well maintained PHP stacks.

    • By jjice 2025-11-2014:28

      Modern PHP is a damn fine, fast language. I wrote production PHP from 2021 to 2023. The problem with PHP wasn't the language or the ecosystem (PHP community packages are very solid in my experience), it's the existing PHP code you'll work with and the people that hire for PHP.

      My salary literally doubled within two years of getting a gig that wasn't PHP. If you see a listing for PHP dev work, there's a good chance it's notably lower salary. There are still solid gigs for it, but I swear they lean lower.

      The other problem is the existing codebases. There is some awful legacy PHP 4 era code. There are also a lot of practices that old PHP had that are just awful to work with, and there's a bit of variety in there. So many bad data access patterns out there. Many of old PHP codebases have their own spin on that kind of thing.

      I understand this isn't actually due to the language, but there is a real correlation (in my experience) between old bad code and it being in PHP. Which is totally fair because it was a good tool to reach for to "get shit done (r)" and that code was successful enough to have to continue to live.

      Modern PHP has, thanks to the core language and the big frameworks, made it wonderful. I lead a big push to go from PHP 5.8 to PHP 8.1 at the time at my last company. It was wonderful. The quality of the code we were enabled to write was huge.

      If I was starting a new project today, I probably wouldn't reach for PHP, but I'd gladly join in on a modern (last ten years) Laravel project.

    • By nusl 2025-11-208:093 reply

      PHP is a very pleasant and straight-forward language to work with. I enjoyed my time working with it, though I did also see quite a lot of very poor code.

      I think the danger with PHP is more its ability to easily cause *very bad things*.

      This would partially be poor training (my University literally taught PHP with SQL-injectable examples), and I think the language itself making it very easy, such that less-experienced developers using it - most of them, early on - don't realise what's wrong until it's gone wrong.

      With PHP being such an early tool online, and the above properties existing, it earned a reputation for being insecure and bad.

      • By ale42 2025-11-208:162 reply

        > I think the danger with PHP is more its ability to easily cause very bad things.

        Is there any language where you can't?

        • By homebrewer 2025-11-208:28

          It's like walking on minefields with very different "mine densities"; when using something stricter, you would have one mine per acre, with PHP you would have ten.

          For the longest time the language had been developed with this mentality that it's okay to continue running if something broke, that it's better to print out something than to do nothing and bail out.

          Which means that for things to run reliably, you have to write very defensive code that checks everything you can think of. Which is probably a good idea with any language, but I find that old PHP requires much more of this.

          Thankfully, they've been changing that over the past decade while still maintaining decent compatibility with old code. I just recently finished porting a pretty large project (~2 mil SLoC) from the ten year old 5.6 to the currently latest 8.4, and it's been pretty painless. The only things that broke were those that were never actually properly implemented and worked by pure chance.

        • By jojobas 2025-11-208:181 reply

          Probably not, but not most languages are not inviting to do them.

          • By s1mplicissimus 2025-11-208:222 reply

            Give me an example where PHP invites developers to do terrible things and I'll show you 2 other popular languages that invite equally bad or worse things :)

            Or as Bjarne Stroustrup put it: There's two types of languages: The ones people complain about and the ones noone uses

            • By Yokolos 2025-11-209:161 reply

              You can do crazy things in every language. However, in a language like Java, the crazy things are more conceptual (factory for factory of factories) and not basic things like what does == mean or problems with weak typing and implicit conversions. A lot of the issues with PHP can be avoided in modern PHP using things like strict_types=1, but most of the time, we don't get to work with projects using best practices. And I'd rather work with a bad Java project than any bad PHP project (which I have had the misfortune of maintaining).

              • By babuskov 2025-11-209:513 reply

                Funny that you picked == as an example when == is very counter intuitive in Java and is one of the common pitfalls for beginners:

                    String a = new String();
                    String b = new String();
                    a = "test";
                    b = a + "";
                    
                    if (a == "test")
                    {
                        // true
                    }
                
                    if (b == "test")
                    {
                        // false
                    }
                
                    if (a == b)
                    {
                        // false
                    }
                        
                Just like PHP, you have to read the docs to use it properly.

                • By philipallstar 2025-11-2010:06

                  This is a decade-old PHP defence fallacy. No one says other languages have no problems, so "disproving" that is the fallacy. PHP just has far more problems and footguns. Maybe now it has fewer, but still. Far more.

                • By Yokolos 2025-11-2010:23

                  So you're going to ignore the rest of what I wrote? I'll just assume you agree with me and the rest of my comment, but you don't want to admit it. Works for me.

            • By greiskul 2025-11-2010:093 reply

              The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate.

              PHP has an operator for something you should never do in a sane codebase.

              You know that python wants good good to look good?

              PHP was written in a way that makes bad code look good. And if we want Software Engineering to be a serious field that evolves, we have to be able to be honest with ourselves. It is a bad tool. Good programmers can even write good programs with bad tools. Doesn't mean you shouldn't avoid bad tools given the option.

              There probably is a "PHP the good parts". But Javascript actually had a pretty nice core, and an utility of being in all web browsers that no other language could replicate. What niche does PHP have where it brings more value there other nicer languages can't be used instead?

              • By onli 2025-11-2010:431 reply

                You absolutely can use @ in sane codebases. And you give the example yourself: In other languages you often enough see that boilerplate where thrown exception is discarded, because there is no sane reaction to some edge case and you just want the program to continue, because you know it will work anyway. And that's @.

                Note though that @ was already neutered in some earlier recent PHP releases.

                • By djxfade 2025-11-2011:24

                  This.

                  One common use case for the @ operator, is when "destructuring" array members into variables. In some cases, you can't know if the member will be available, but it's not important if it's missing. In that case, you can silence the warning.

                  $array = ['apple', 'pear']; @list($mainFruit, $secondaryFruit, $tertiaryFruit);

                  Since I suppress the warning that would occur due to the third member not being present, the program will continue executing instead of halting.

              • By bawolff 2025-11-2012:58

                > The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate.

                The @ operator doesn't get rid of exceptions it get rids of "warnings" which are basically built in log messages.

                It used to get a bad wrap for also silencing fatal errors, but it stopped doing that a while ago.

                The @ operator is something that should only be rarely used, but it is no way comparable to catching exceptions and doing nothing with them. There are sane uses for it.

              • By s1mplicissimus 2025-11-2010:46

                The claim was "PHP invites bad code" - but your point is for "bad code can be written in PHP" which is really not the same thing. A quick google for the @ brought up https://stackoverflow.com/questions/136899/suppress-error-wi... where the highest voted response is ~"NO, don't use it please". No use case I've come across during the past 10 years has required or even nudged me in the direction of @. It's an ancient relic that the whole community considers a no-no. I'd be curious if you really want to argue that this state of affairs "invites" using the @.

      • By Cthulhu_ 2025-11-209:00

        At least in my experience, the early years of PHP was lacking more enterprisey users; back then there was a small revolution when RoR came out and introduced the MVC pattern to a lot of (web) developers, who didn't have as opinionated a pattern / architecture up until then.

        During that same period, there were a lot of mediocre tutorials and documentation online, including on the PHP website itself which allowed people in comments to post code examples, but as far as I know there wasn't a lot of moderation on those.

        And finally, a lot of people ended up writing their own frameworks and the like, because they could. But also because there weren't any or not many good and widely adopted frameworks out there, that came later with first Zend Framework and then Laravel, the latter being the de-facto standard nowadays.

      • By khannn 2025-11-2013:52

        I miss doing drive-by SQL injection attacks against my classmate's string concatenations with bonus no input validation queries

    • By rob74 2025-11-209:431 reply

      I'd take PHP instead of JS/TS + framework-of-the-day on the backend anytime. Ok, PHP is usually also paired with a framework (cough Laravel cough), but at least there the situation is more stable, not to mention more mature. Unfortunately, I'm not the only one making the decisions...

      • By kijin 2025-11-2010:211 reply

        PHP is a reasonable choice if you care about writing something that will still work out of the box 10 years from now.

        But of course this assumes that you work with a team that can see a year ahead, let alone 10.

        • By dgb23 2025-11-2012:573 reply

          PHP has introduced breaking changes, deprecations etc. in a somewhat rapid fashion.

          PHP doesn't prioritize stability, but language features and cleanup. It's an impressive technical endeavor that has its merits, but comes with a tradeoff.

          Within the last 10 years, the language itself broke twice. And that's not counting the ecosystem on top of it. Common frameworks, libraries etc. tend to break relatively often as well.

          There are languages that are _much_ more stable and reliable than that.

          • By conradfr 2025-11-2013:15

            That has not been my experience and I have a project that started in 2017 with PHP 7.1 & Symfony 3.3 and is now at PHP 8.4 & Symfony 7.3 with plenty of dependencies.

            Not everything will always update flawlessly but with Composer and a popular framework with planned depreciations and releases the ecosystem tends to sync fairly well.

          • By hu3 2025-11-2020:14

            This has not been my experience at all.

            PHP code requires very little maintenance to keep working for a decade+.

          • By stefanfisk 2025-11-2013:41

            Which specific deprecations and breaking changes are you referring to?

    • By etothet 2025-11-2012:52

      I’ve made my living amd career off of PHP and I enjoy its modernization.

      Coding in PHP can be a lot like playing the guitar or writing poetry: many people can do it, but it’s easy to do very badly.

    • By ThatMedicIsASpy 2025-11-2011:41

      https://github.com/AzuraCast/AzuraCast

      AzuraCast because I like learning by looking at code and hosting my own radio/music

    • By nake89 2025-11-207:582 reply

      > A lot of people are too proud to be associated with PHP.

      How so?

      • By misiek08 2025-11-2117:27

        A lot of mediocre devs sitting at corporations that migrated from PHP to Java and currently can’t write relatively good code in any language make jokes of PHP, because it was popular for some time. They won’t admit the language gave them food, they have no idea how language looks today and are way too proud to admit any of that.

      • By type0 2025-11-2011:21

        Vanity, it's "PersonalHomePage" language

    • By bawolff 2025-11-2012:511 reply

      > My favourite PHP product at the moment is BookStack (https://www.bookstackapp.com/), a really good wiki.

      Another wiki that uses php is Wikipedia.

      People like to shit on php but it powers some of the largest sites in the world.

      At the end of the day, programming language doesn't matter much. You can be a good programmer in any language and a bad programmer in any language.

HackerNews