Insightful comment, with which I mostly concur.

What would be an ecosystem which is well ahead of PHP, in 2025?

Call me a boomer, but I hate the "Amazon Fresh" buying experience - I'll take any day a shop where
- I can pay with cash
- I can pay with a credit card
- I do not have to fear that, if I pick up an item and then put it back on the shelf, the system will think that I have taken it out anyway
- I am forced to use my all-encompassing online profile to buy bread and milk, and give away all my grocery habits to the same company who already has info on my online shopping and music/video listening
 

1. Use PHPStorm. If you contribute regularly to OSS, you can get a free license from them. If not, it is worth its every penny multiple times over. VSCode is nice, but it does not come close in the level of intelligence it has in analysing PHP code and figuring out the slightest mistake or code-smell. It also has great integration oob with the whole ecosystem, from grokking composer files to ofc git, rdbms and ssh support - but it does not force any of that on you, apart possibly for the "work on a project at a time, do not open a file at a time" paradigm.

2. About switching to a framework, as others have pointed out, the answer is "it depends":
- do you need to onboard junior devs? If so, using a well known framework will save them learning time
- is your own code high or low quality? would you throw it away and refactor it in any case, or is it good enough to only require minimal maintenance? if the latter, do not bother rewriting
- being able to rely on someone else's implementation for "tricky" bits such as authn/autz, rdbms abstraction etc... is a benefit in your situation, or is it a hindrance?
- what's the expected support lifetime of your code? can you find a framework which has the same lifetime and is not likely to disappear on a whim? what are its BC promises?
- do you have comprehensive testing, functional+integration, or not at all? if you have no tests, refactoring is a big gamble
- is your code already well separated into SOLID components, or is it an organically grown bowl of spaghetti? If it is, a framework can be introduced piecewise, sliding in one component at a time*

* = this is a bit of a stretch in fact. What you could use to piecewise-replace your own code is generally acknowledged as being a "library", whereas a framework is more of a coherent whole application which calls out your code here and there.

BUT

Symfony comes with both a framework and a set of independent, well tested, maintained and documented components.

A good "middle of the road" choice could be to start using piecewise those components, until all the pieces make sense and click together, and possibly introduce the full fledged framework in a later, final step. Begin with using eg. dotenv for managing the settings, twig to separate the presentation layer, psr/log for logging (and later introduce monolog), adopt an Entity/Repository pattern.

In a recent project I worked on, where the prime directive was "no external code, full auditability is required" I ended up implementing from scratch most of the components mentioned above. Just copying the necessary parts of the Sf components API gave me reassurance about the solidity of the patterns adopted, as well as keeping the door open for possible swap-out-this-component scenarios in the future.

PHP has evolved a lot since HACK was created.
Today it is much faster (eg. it does include JIT), flexible (eg. anonymous functions as first class construct), consistent (in every release a few warts get corrected), and safer (allowing more type hinting but also readonly attributes, enums, etc...).

Talk about battles lost ages ago...

Nowadays most apps are web apps, most actions in web apps happen via js code making http requests to retrieve or push data, and most of that code gives _zero_ feedback:
- no visual feedback such as graying out or change of colour of the clicked control
- double-clicking is not prevented
- cursor does not change to a spinner
- worst offender of it all: quite often there is no feedback at all if the http request fails for any reason, or if it brings back unexpected data

Japan begs to differ.

It has as much automation as any other country in the world, if not more, and it works 100% on cash.
Everywhere you would see a PoS system in the EU/US, they have an automaton taking both cash and cashless instead. Often just cash, or even, shudder, only coins!

I am not saying that this works better in practice: on one hand having to travel with pockets full of coins is something I don t long for, usually, and on the other hand I am not sure how much more resilient to network failures their cash handling machines are compared to a debit-card pos.

As for getting robbed or pulled-over with a large wad of cash: I think the most common "need to be able to do thing" in a 'global hack attack' scenario is not to book within the day your flight to the other side of the world or buy an high end stereo system, but rather to buy groceries and pay a cab to get home or to a nearby hotel. Something around $50 should be enough as emergency sum to be carrying around...

Must have gone to the same high school as ebassi... ;-)

That's in fact one of the things which eZPublish always did better than Drupal - have a great focus on BC.
Sorry you picked the wrong CMS ;-)

Fully agree.

Up to the move from 7 to 8, PHP had in fact quite a good track of keeping BC. The last time changed so dramatically was when switching from 4 to 5, in 2004.
I can not compare to all other widespread languages, as I don't use them on a daily basis, but much better than Python, for sure.

Sure, there are changes in each and every release, and as we know every bugfix can be perceived as a painful BC breakage by developers (cue the obligatory XKCD - nr. 1172...). But most of the time, if your program breaks in massive or unexpected ways on minor PHP version updates, it is because it was sloppily coded. The fact that PHP has always allowed coders to be sloppy can not really be argued... in fact it is a huge part of its original success, and at the same time it is most likely also a big driver behind the current maintainer's urge to make the language stricter! :-D

As a side note: I maintain a bunch of php libraries which are compatible all the way from PHP 5.4 to 8.3, within a single codebase, and with no IFDEFS in sight. So I know this is possible

Not sure you wanted to reply to my comment, or the parent.
As for me, eZPlatform (ex eZPublish) has been paying my bills since 2007.
To this day, I still find it a better CMS than Drupal - even though I think it peaked around version 4.7...

I sure hope that Poetry won't be the only Python package manager going forward, as I just settled on PDM instead - the feature set looked similar, but there were far fewer horror stories about bugs and disregard for api/abi breakages (which is paramount for any dev tool in daily use) :-D

As for Pip, it might be just me, but it seems stuck in the 90s, when it was not yet necessary to update your project's (transitive) dependencies every other week - which is sadly a fact of life for anything exposed to the web. It is incapable of catering to the very simple scenario where you specify in your requirements file only the 2-3 libs you are actively using in your code and it takes care of writing down in a lock file all the installed libs, allowing you to later run an update command which will update everything while respecting semantic versioning, or checking for available updates - ie. without forcing you to specify by yourself the desired version of transitive dependencies. The closest I could get to that is via other tools on top of pip, which do not seem to be as widely adopted or well maintained...

And about type coercion: it might be frowned upon, but is this not happening basically all the time, when you do f.e. `f"the chosen color is: '{color}'"` ? Also, considering that APIS such as the Django Models give you back DB data as either a string or None in case of a varchar column, one does have to always typecast, say for comparing the fetched value to another string (and that's without even taking into account all the databases who think that having '' != null for string columns is a sensible choice...)

Having recently started dabbling in Python after many years of PHP, I'm surprised to find it, despite its increasing popularity, less well architected, coherent and pleasant to use.
Starting from ecosystem issues such as the too many package managers, none of which is both fully featured and widely used, or the multiple datetime libraries, down to details such the weird ways of declaring static methods vs. static class members, how None converts to "None" instead of "", mutable default arguments or how type hinting seems to be a few years behind, just to name a few.
The docs on the internet seem to be split between "coding for noobz" and "architecture astronauts", ie. precious few of them target the proficient coder coming from a different ecosystem.

Still, I'd never touch JS with a ten-foot pole... (and I did try to pick it up)

ps: agree that recent PHP is too gung-ho on cherry-picking the ease-of-use of Java and the stability of the nodejs ecosystem... :-( ...but that might just be me having become an old fart :-D

My understanding is that a large part of the reason `apt` was developed was to allow breaking the output format without impacting the scripts consuming it, whereas `apt-get` is more or less frozen in time

The comments posted here so far seem to mostly agree on the moronic nature of the developer who committed the github token to the public repo.
But what about the fact that the other, private repos also contained a plethora of access tokens? Isn't it also a bad security practice?

The problem is that the issue is systemic, and it is disingenuous to blame it on developers.

Btw, a similar thing happened at company I was working for, which took pride in making its software Open Source: a dev commits an AWS key to a public github repo, and the next thing you know is you're hit with a $50K bill of EC2 instances mining bitcoin.

Heck, on the tiny, tiny project I am working on, for the smallest of charities, we use Twilio, Stripe, WooCommerce, What3Words, MapQuest, Google and a couple more obscure SaaS. The number of tokens required for all the sw pieces to authenticate calls to each other is about a dozen, times the number of environments we deploy (and let me not even start the rant on SaaS platforms which do not provide staging environments... why is a test env something every PaaS provider feels the need to reinvent differently?)

Preventing the tokens from ever hitting git code, and reducing attack surface in case of token leak means at the very least:
- setting up Vault or an equivalent store (it could be as simple has having a .env file with all tokens propagated around and never committed, plus lots of glue code moving it around)
- integrating use of said store in all your code - from infra management code to apps
- writing more infra code to insure key rotation
- setting up tooling to scan commits to prevent leaks
- figuring out how to safely store the master-key which decrypts the key-vault, taking into account both its utmost secrecy need as well as its utmost-availability need
- spending a lot of time reading docs about the privilege model of every saas in use and then testing it until one finds the tiniest policy which fits the needs of the api consumers
- educating every developer and tester

This is a huge chore, and, in my own experience, extremely hard to get right.

Strongly agree with the above.

I have no experience in formal proofs of code, but quite a lot in real-world software development.
For anything but the most trivial business-logic scenario, trying to write bullet-proof (aka. provably-correct) code means identifying all possible permutations of inputs and context. "Good enough" software will usually handle perfectly the most common situations, and cater to most known or plausible deviations, but there are always lots of data which make no sense at all to feed to the system, and are thus generally not taken into account, except maybe for software such as avionics and industrial control systems.

Handling _all_ kind of weird cases takes not only an herculean effort in terms of coding and testing, but it also requires spending a huge amount of time asking the stakeholders what is the expected response to them. And that usually leads to blank stares, head scratching and lots of bike-shedding. There is often no good expected-response, without even taking into account that crazy corner cases are hard to explain to coders, let alone they layman.

Managers in the end are probably right if they see little value in spending time thinking about situations which have an extreme low probability of happening - the correct approach would be to have a good estimate of the cost of catering for them vs. the cost of fixing the mess if they happen and then make an informed decision.
But that means identifying all the corners cases and estimate the cost to handle them, which brings us back to square one...