PHP.Watch

xdebug 3 has been released with great performance improvements. https://php.watch/articles/xdebug2-vs-3-benchmark And you actually can have xdebug installed without performance degradation if it is not automatically enabled on every request (think that was true for xdebug 2 as well). What you do is to send a special request payload to enable it when needed, can be done with a browser extension. There is also phpdbg, shipped with php, it does not suffer from the same performance penalties that xdebug prior to version 3 had (not sure how it compares to xdebug 3). However it is a command line debugger only, it does not support remote debugging or IDE integration. https://youtrack.jetbrains.com/issue/WI-21414

PHP is a great fit for most web projects. It is battle tested with great backwards compatibility, fast, offers the best deployment story and combines the advantages of dynamic and static typing with it's gradual typing system (Think Typescript without the complexity of Typescript.) The next version is even going to improve on its weakest point, concurrency, with Fibers: https://php.watch/versions/8.1/fibers Sure we all remember the bad old times and the horrible legacy projects that are still around but let's no forget PHP allowed the average Joe to hack up his own dynamic websites without jumping any hurdles. It helped democratize the internet for a while. I really don't get why PHP is not more liked in hacker circles. Probably needs some new languages with slightly different syntax that transpiles to it for it to be hip again.

I wish the <progress> tag receuves some love, from both users and browsers. I recently worked on a page (e.g https://php.watch/rfcs/fibers) that I didn't want to set inline CSS to set a dynamic width for an element. Helps me not use a strict CSP. I kind of abused the progress element because it has customizable width. Elements that support a width attribute (object, iframe, image, etc) didn't fit that well. Progress elements are pretty nice, supported almost everywhere it mattered to my audience, and with some pseudo properties I never heard before, I could customize the colors and other properties as well.

It's gotten a lot better since I started using it ~2009 and now. 7.4 added typed properties. 8 is adding better caching, a jit and my favourite feature match() https://php.watch/versions/8.0#match-expression for all the enterprise heavy stuff I write a nicer cleaner and safer (by default) alternative to switch is going to make some code much cleaner to write and read and really that is what I care about more than almost anything else. That it also returns a value is just the cherry on top. I am so tired of reading bad code with poor intent that has no comments and no documentation that's written in the most counter intuitive way.

If all the other reasons given here don't convince you already, I have one more to offer: Match Expressions[1]! [1]: https://php.watch/versions/8.0/match-expression

No, they made 8.4.0 2 days ago and fixed it before the offcial release: https://php.watch/versions/8.4/releases/8.4.0

Some interesting changes in this release, too: https://php.watch/versions/8.3

They are not. Attributes are metadata that can reflected/accessed at runtime: https://php.watch/versions/8.0/attributes

That’s a PHP attribute: https://php.watch/articles/php-attributes

Yeah, it's more like a switch but as an expression. Some more examples: https://php.watch/versions/8.0/match-expression It only executes the matching branch, ignoring the others. If you used an array/map + index, then it executes the right-arm of each of the options if they're functions for example, even if their result is thrown away.

https://betterprogramming.pub/a-look-at-the-new-php-8-1-fibers-feature… and https://php.watch/versions/8.1/fibers

N00b question: would the fibers being introduced in PHP 8.1 enable the same functionality in that language? https://php.watch/versions/8.1/fibers

For those who need them EDIT: Actually, there are polyfills here: https://php.watch/versions/8.0/str_starts_with-str_ends_with

"A major limitation of the pipe operator is that all the callables in the chain must accept only one required parameter. For built-in functions, if the function does not accept any parameters, it cannot be used in a chain. For user-land PHP functions, passing a parameter to a function that does not accept any parameters does not cause an error, and it is silently ignored. With the pipe operator, the return value of the previous expression or the callable is always passed as the first parameter to the next callable. It is not possible to change the position of the parameter." https://php.watch/versions/8.5/pipe-operator In the light of these limitations I would not call the Elixir implementation "slightly fancier". I'm not so sure I'll be upgrading my local PHP version just for this but it's nice that they are adding it, I'm sure there is a lot of library code that would look much better if rewritten into this style.

Bash script (without -e) continue merrily even if the last command's exit status is non-null. PHP also ignored errors out of the box (even has @ to suppress error output), but error_reporting(-1); is basically how every sane framework starts, and PHP 8 set the default level to E_ALL [1](in 5.3 accessing undefined variable was also ignored (notices - as far as I remember)[2]) Python and NodeJS by default aborts on error. (Python had exceptions before user-defined classes in the last millennia. [3]) ... Rob Pike said in 2015 "don't just check errors, handle them gracefully." [4] I think Scala/ZIO has the most powerful and comprehensive and compact [5] error handling machinery that I have experience with, that's where it's the easiest to live up to Mr Pike's admonition. ... All are fine. I hope/predict Go will pull a Bash or PHP and will introduce flags to turn some/most unchecked errors into aborts. (Or perhaps people will build tooling and alternative stdlib eventually.) Result types are nice because it allows library developers to encode a shitton of really useful semantic information into them, and it's really easy to handle them however the downstream user wishes. (Rust offers .unwrap(), TypeScript ! (assume non-null), and JS itself has the ? optional chaining operator.) [1] https://php.watch/versions/8.0/error-display-E_ALL [2] https://stackoverflow.com/a/69291454/44166 [3] https://python-history.blogspot.com/2009/03/how-exceptions-came-to-be-… [4]…

> You seem to be referring to an area where people pay pennies + have almost zero programming experience so they want to launch a project with clicks. Over my career, I've worked with companies using PHP in sales. One of those had over a million customer subscriptions, the other was a multi-national looking at PHP for a greenfield e-commerce project. I noticed working in Europe some high-growth agencies that use PHP. > So tell me again, why should I use PHP? How will it truly help me? What does it do better than everyone else? > But I thought we were discussing the actual programming? Your original question just said "use PHP". PHP is a general purpose web scripting language. It's similar to Python or Ruby. It is generally more performant and later versions have a gradual type system. It's traditionally run as a shared-nothing single-threaded script, which makes it easy to reason about, and in real life has proved to be a stable way to run things in production, as it avoid bugs that can arise around stale state, multi-threading and it keeps running if other libraries have bugs that leak memory. Later versions have introduced a JIT and support for concurrency concepts such as fibres, as in the upcoming PHP 8.1 https://php.watch/versions/8.1/fibers. Arguably, the thing that would make you use it over Python, or Ruby, is the ecosystem, especially around content management and e-commerce, as the language itself is roughly comparable to others. Also I think there are more…

> It's traditionally run as a shared-nothing single-threaded script, which makes it easy to reason about, and in real life has proved to be a stable way to run things in production. I think we have a vastly differing definition of "in production". I'll agree PHP was good enough for plenty of things, and likely still is. But good enough in general to run things in production as it's understood today? You'll find that many people will disagree with you here, not just me. > Later versions have introduced a JIT and support for concurrency concepts such as fibres, as in the upcoming PHP 8.1 https://php.watch/versions/8.1/fibers. That's what I mean, not only for PHP but for like 99% of all programming languages: they play catch-up, waaaaaaaaay too slowly and gradually, with things that should be baseline by now. Happily Erlang/Elixir are having lightweight and transparent parallelism and concurrency for a long time now. Languages like Go and Rust also progressed very well in this area so I am looking to work more with them in the future as well. --- I think you and I are not aligned on what is "successful" or "good enough". You seem to insist that statistical success speaks something of the merits of a technology, and this is where I and many others disagree: people just adapt to what's given to them. That doesn't say almost anything about if the thing is good or not. People simply get what they can. Back then PHP was available so they took that. The rest is post-hoc…