Comment by doodlesdev
3 hours ago
I don't use any of those for anything running dynamically on the web or accepting untrusted user data. Unless it is a quick student project, there's rarely a reason to do that anymore. It's also not the same thing, both NodeJS and Python with ASGI handle less parts of web requests than PHP is meant to.
Meanwhile, there are different threat models to any type of web application, it's just that PHP has repeatedly failed us in any threat model, same as C in most threat models that don't involve compiling it to WASM or running it air-gapped.
Leaving memory unsafe runtimes and interpreters directly available to public web traffic is a liability I don't want for me and users don't deserve to face the consequences of it whenever they are trusting you with their data. Rust and Golang even with all of their design issues should be the baseline for internet facing software nowadays.
As for the Linux kernel, everything I run on it is inside a VM (or a microVM) instead of relying on containers exclusively, because I can't trust a C kernel to not have vulnerabilities.
Huh what :) And that VM/microVM is running on top of...Windows? :)
Most microVMs run on extremely stripped down versions of Linux or NetBSD. Not the same thing as relying on PAM, SystemD, namespaces and cgroups to protect your application
Funnily enough, regarding SoftTalker's point, just a few hours after my original comment, CVE-2026-110264 (a CVSS 10.0... worse than PHP's RCE) rolled in for GitLab, which would be prevented by using a memory safe language to write the interpreter instead of C.