Hacker News Reader

Comment by juliusjh | Hacker News Reader

I would assume that in many (smaller, non-professional) systems/code bases, it is also possible to poison the backups and code base in general. This would have been a major effort in the pre-LLM age, but it should be pretty easy now. As soon as such instructions are out there, people (or rather LLMs) are going to find ways to make the threat persist.

View on HN

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.

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...

If you "really" want to secure the web you reduce the blast radius - there's absolutely no reason that most websites (99% static) are served live from CGI_BIN.

Well-architected solutions would have the static part broken out so only the dynamic content is on a separate domain/host and that part can be secured as needed. Then something like this only turns off your forms/upload dialogs.

No real stdlib? What are you talking about?

> No real stdlib? What are you talking about?

I'm not rising to that bait. I'm sure you know perfectly well what I mean.

So let's just be polite, cordial and leave that topic there there. I'm sure you know its a topic that attracts 'strong views', particularly from the Rust side, which is no doubt why you're trying to engage on it.

I honestly don't. It was a real question.

The only times I had to use third party packages for basic stuff, was when developing embedded software on limited hardware.

Do you mean that for async we need third party runtimes like tokyo? Or that types and utilities that many other languages ship by default in stdlib, like http aren't in rusts?

I'm sorry for the tone of my post. It was meant as honest surprise, but I clearly see now how it sounds baity and provoking.

This is the dependency list of the just command runner

https://github.com/casey/just/blob/master/Cargo.lock

And the helix editor

https://github.com/helix-editor/helix/blob/master/Cargo.lock

Compare them to the dependencies of gnu make (pretty sure it’s only posix)

https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/m...

And vim

https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/c...

###

Downloading the internet to build a smallish software is always bad in my opinion.

Not who you’re replying to, but Rust lacks things I assumed were basics in any modern language, like random number generation, JSON handling, and regex. I understood the reasoning once I looked into why, but it was still startling at first.

In contrast (I know this is apples to oranges), Python’s stdlib is incredibly broad. colorsys lets you convert between color spaces. plistlib lets you read and write Apple’s property list files. graphlib has a topological sorter, which can lead to hilariously short interview questions when the interviewer isn’t familiar with Python’s stdlib.

Other vulnerabilities are possible, but still much easier to rule out in a language with a decent type system and macros (e.g. Rust or Scala).

> While Go/Node have grown much more than PHP, PHP is definitely alive.

PHP still powers approximately 70% of websites

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.

> 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 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.

How can you maintain it if you can't read/understand it?

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?

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.

Reply on news.ycombinator.com