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.

▲

amiga386 a day ago | parent | next [-]

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

▲

1718627440 a day ago | parent | prev | next [-]

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.

▲

kllrnohj a day ago | parent | prev | next [-]

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

PHP still powers approximately 70% of websites

▲

echelon a day ago | parent | prev [-]

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.

▲

traceroute66 a day ago | parent [-]

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

▲

bombcar a day ago | parent | next [-]

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.

▲

ndriscoll a day ago | parent | prev | next [-]

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

▲

berkes a day ago | parent | prev [-]

No real stdlib? What are you talking about?

▲

sgarland a day ago | parent | next [-]

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.

▲

traceroute66 a day ago | parent | prev [-]

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

▲

berkes a day ago | parent [-]

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.

	▲	skydhash a day ago \| parent [-]
		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.