Comment by echelon
16 hours ago
It's time to have the conversation about killing PHP again.
We don't really need it anymore now that we have LLMs.
16 hours ago
It's time to have the conversation about killing PHP again.
We don't really need it anymore now that we have LLMs.
People love hating on PHP. But Go has CVEs like every week, and people are getting tired of updating it. I don't think there is a fundamental "PHP bad" argument beyond just "hating on it". While Go/Node have grown much more than PHP, PHP is definitely alive.
> Go has CVEs like every week
I don't have a problem with it.
govulncheck tells me if my codebase is actually affected by CVEs or not. So if there's 50 CVE'd modules but my codebase doesn't use them, I sleep.
Secondly, the fix is almost always "go get -u <affected module>", and because it's a CVE, it's usually just a bugfix release and still completely compatible with how I'm using it... but I run the test suite to be more certain.
I think the actual difference is that for Go there is likely a build pipeline set up, while for PHP most people can't even touch the binary, because they have a shared hoster. I would sure love to be able to just recompile PHP right now.
> While Go/Node have grown much more than PHP, PHP is definitely alive.
PHP still powers approximately 70% of websites
Replace it all with Rust. It's a fantastic server language.
Nobody needs to write any of this code anymore.
Rust is literally the best positioned language to handle the upcoming onslaught of CVEs.
> Rust is literally the best positioned language to handle the upcoming onslaught of CVEs.
Rust is also a language with no real stdlib, and so you have to import crates for everything including the kitchen sink.
Which opens you up to the very real risk of supply chain vulnerabilities unless you make an active effort to code review your imports and keep the length of your import list under control.[1][2][3]
Rust supporters also need to urgently realise that memory safe != secure. It is very much possible to have vulnerabilities in memory safe code.
This has been demonstrated by Cloudflare[4] and countless others.
Age-old vulnerability classes such as input validation, error handling and many others are still very much possible in a Rust codebase.
So please. Yes, I'm sure Rust is a fantastic memory-safe language. But do not portray it as being magically immune from CVEs.
[1] https://kerkour.com/rust-supply-chain-nightmare
[2] https://tweedegolf.nl/en/blog/119/sudo-rs-depencencies-when-...
[3] https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-...
[4] https://hackaday.com/2025/11/20/how-one-uncaught-rust-except...
7 replies →
The conversation should be about having more variety in structural components, not less: if you kill php and everyone starts using Go for example, the next CVE found in Go will impact as much. The real way is to have more widespread ecosystems.
Rust won't have as many CVEs, though.
I don't understand why PHP is redundant now that we have llms?
Not the one you are replying to, but an argument I heard is that
1) It is now much easier to work in a language with better security features such as Rust. Previously, there definitely was some kind of trade-off between accessibility, performance, and security, and some people argue that this is over. I don't know if this is true, but it seems plausible.
2) You can now translate your legacy projects to a different language much more easily. This is definitely true, but that doesn't mean it doesn't introduce new/other problems or that it is easy enough (again, I simply don't know).
Both are true. Our backend is Rust and anyone could maintain it.
1 reply →
2 makes sense. 1 is immensely scary as an argument.
If you don't understand the language(eg, not easy to work with), don't work professionally in it. All LLM work need audit, a second set of eyes, just as work from a coworker needs peer review prior to sign off.
How can one peer review an LLM without full, experienced knowledge?