← Back to context

Comment by owenthejumper

20 hours ago

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

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

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