Eight PHP Myths That Need to Finally Retire

PHP left bad memories with a slice of its audience, 20 years ago. Indeed, some of it was earned. The language genuinely did ship some bad ideas in the ancient PHP 4 and early PHP 5 era, and recent memory-safety CVEs in the Zend Engine are a serious, ongoing concern worth patching today. None of that is in dispute, and neither should significant modernization be ignored.

A lot of what gets repeated about PHP in 2026 is just fossilized experience. Like mammoths, these claims teach us a lot about the past, and they belong in a museum. Some claims were true in 2008 and have been false for a decade, almost two. Other claims sound technical but are not. Still, they get repeated because they are fossilized and do not evolve anymore. Meanwhile, PHP cleaned its room, tidied its syntax, and got better with age.

This article attempts to straighten out eight of the stubborn ones. Its goal is to stop the same dead arguments from being used as if they are current. They are relics of the past.

Myth 1: “PHP is interpreted, so it’s slow”

This one is at least twelve years out of date.

PHP has shipped OPcache as a bundled default since PHP 5.5, released in 2013. OPcache is an opcode cache that eliminates the parse-and-compile step on every request. The PHP source you write is compiled to Zend opcodes once, cached in shared memory, and executed from there on subsequent requests. The first request is slow, and the second one is much faster.

Since PHP 8.0, released in November 2020, PHP also ships a JIT compiler. The JIT is configured through the opcache.jit family of ini settings, and it further compiles hot paths to native machine code at runtime. It is not AOT in the Rust/Go sense, but it is also emphatically not interpreted line by line on every request. Give it heavy loads of math and string work, and it gets noticeably more athletic.

The “PHP is interpreted” framing was reasonable in 2010, before opcode caching became the norm. In 2026, it is a category error. PHP is a managed runtime that compiles to opcodes and can use a JIT. It is usually still slower than Rust on raw CPU-bound benchmarks, but the gap has long moved away from what the “interpreted” label implies. For I/O-bound web work, the difference is dominated by network and database latency anyway. The “interpreted” label is a bit like a 2010 phone: still in the drawer, and nobody has used it in years.

Myth 2: “PHP is still dragging around all those awkward features from the PHP 4 era”

I have a whole book of arcane PHP features inherited from this era, and I now have a hard time finding new ones, since they get mercilessly removed from the code. I really wonder if there is a relationship between these two facts. Either way, this is the myth that ages the worst. If you actually list the cited awkward features, almost all of them have been gone for years, almost decades. The list shrinks faster than a sweater in a hot wash.

Consider the usual suspects:

• register_globals was removed in PHP 5.4, which shipped in March 2012. It had been off by default since PHP 4.2.0, released in 2002.
• magic_quotes_gpc was removed in PHP 5.4, which shipped in March 2012.
• Call-time pass-by-reference was deprecated in PHP 5.3 and removed in PHP 5.4, which shipped in March 2012.
• preg_replace with the /e modifier, often called the “hidden eval()“, was deprecated in PHP 5.5 and removed in PHP 7.0, which shipped in December 2015. Developers replaced it with preg_replace_callback.
• ASP tags <% %> and <script language="php"> were removed in PHP 7.0, which shipped in December 2015, through the “Remove alternative PHP tags” RFC.
• Dynamic properties on objects were deprecated in PHP 8.2, released in December 2022, and they will cause a fatal error in PHP 9.0.
• String increment, where 'AZ'++ produces 'BA', was deprecated in PHP 8.3, released in November 2023, through the “Path to Saner Increment/Decrement Operators” RFC. This one was a beloved PHP easter egg that people used to share while grinning. I did. I guess we are becoming more mature.

That is the entire usual list. Every single one of them is either removed or formally deprecated. The most recent two, dynamic properties and string increment, remain in their deprecation window, but they are on a clear, scheduled path out. Beware PHP 9!

When someone lists those features as evidence of PHP’s current dysfunction, what they are really showing is that they have not caught up with PHP since about 2015. The critique is historically accurate, and the framing as a present-tense problem is not valid anymore.

Myth 3: “PHP’s memory bugs come from being weakly typed”

This one is not just wrong. It goes well beyond PHP, and it is a category error.

Weak typing and C-level memory unsafety are independent properties. They have nothing to do with each other. JavaScript is weakly typed, and in some respects it is looser than PHP, since [] + {} evaluates without error. JavaScript considers this a reasonable Tuesday. Yet JavaScript does not expose the same class of memory-safety bugs at the language level, because V8 is a virtual machine that never hands raw pointers to user code. Conversely, C is statically typed, and it is the single most memory-unsafe mainstream language in existence.

PHP’s memory issues, the kind that recent CVEs exploit, come from the C implementation of the Zend Engine. They do not come from == versus ===. The fix is to rewrite the runtime in a memory-safe language such as Rust or Go, not to make PHP strongly typed. Those are different conversations.

This conflation matters because it misdirects the diagnosis. If you think weak typing causes memory bugs, you will waste time arguing about type systems. If you correctly identify the C runtime as the source, you can have the actually useful conversation about whether the engine itself should be ported.

Myth 4: “PHP’s runtime is unmanaged, and that’s a PHP-specific problem”

No, this is both true and not unique to PHP. It is a property of every VM-based language, and every VM language keeps its C runtime in the basement, where nobody invites guests. It is easy to see the same feature in action in other VM languages.

Every widely used VM language has one or more runtimes written in C or C++:

• The JVM relies on OpenJDK, which is largely C++.
• The V8 engine, which powers Node.js, Deno, and Bun, is written in C++.
• CPython is written in C.
• MRI Ruby is written in C.
• The Zend Engine that powers PHP is written in C.

And every one of those runtimes has shipped memory-safety CVEs over the years. V8 has had critical remote code execution bugs, the JVM has had its share, and CPython and MRI Ruby have had them too. PHP is not unique here. It is a member of a category, and the category has a known property: the safety guarantees apply to user code, not to the runtime itself.

This does not make PHP’s runtime vulnerabilities side concerns. It does mean that framing “managed language, unmanaged runtime” as a PHP indictment is misleading. The same sentence describes Java, JavaScript, Python, and Ruby. If your critique applies equally to four of the most popular languages in the world, it is not really a critique of one of them.

Myth 5: “PHP is stuck in the LAMP era, and nobody does serverless or microservices in PHP”

This one is simply contradicted by several production-grade serverless and event-driven PHP stacks. The following list is short and non-exhaustive:

• Laravel Vapor runs serverless PHP on AWS Lambda and is officially maintained by Laravel.
• Bref runs PHP on AWS Lambda and predates Vapor.
• FrankenPHP is a Caddy-based PHP application server that runs PHP as a long-lived process, with built-in metrics and Mercure support.
• RoadRunner is a high-performance PHP application server written in Go and widely used in production. Cycle ORM is designed to work with it.
• Swoole and OpenSwoole provide async, coroutine-based PHP, with HTTP, WebSocket, and coroutine-aware database drivers.
• Laravel Octane runs long-lived PHP workers through Swoole, RoadRunner, or FrankenPHP, which dramatically increases throughput per instance.
• Symfony Runtime decouples the application from the runtime and supports worker modes and custom application servers.

The “ye olde LAMP” stereotype describes a deployment pattern that is still common. It is not the only one, and it has not been for years. Modern PHP can run as a long-lived process, in an event loop, on Lambda, behind a Go-based application server, or as a classic PHP-FPM pool. The choice exists, and it is sometimes difficult to make, which is a first-world problem for a language that was supposed to be dead.

Myth 6: “Nobody builds new apps in PHP anymore, you only use it because of WordPress”

Again, that claim is empirically false. Major greenfield PHP projects have shipped significant releases in recent years:

• Laravel 11, released in March 2024, and Laravel 12, released in February 2025, brought a restructured skeleton and first-class health checks.
• Symfony 7, released in November 2023, and the ongoing 7.x line form the foundation under Drupal 11 and many enterprise projects.
• Filament 4 forms a rapidly growing TALL-stack admin panel and application framework, and it enjoys adoption well beyond the Laravel core community.
• Pest 3 forms a modern testing framework built on PHPUnit, and developers actively choose its expression-based syntax over PHPUnit for new projects.
• Statamic 5 is a flat-first CMS that is gaining ground as a headless or hybrid option against WordPress.
• Craft CMS 5, released in March 2024, is a major release of a CMS that teams actively choose for content-heavy commercial work.
• FrankenPHP is a relatively young PHP application server that reached its first stable release in December 2023.
• Cycle ORM 2 is a DataMapper ORM designed specifically for daemonized PHP runtimes such as RoadRunner and Swoole.

Recently, PHP has shipped on microcontrollers, in Rust application servers, in online games, and in CLI and TUI applications. It turns up in more places than its critics ever look.

You can absolutely argue that PHP’s greenfield share is shrinking relative to TypeScript, Go, and Rust. That claim is defensible. A shrinking share is partly a matter of arithmetic, since a language that already powers a large share of applications has less room to grow. Arithmetic is not a conspiracy, and it is not an obituary. The statement “no one starts new projects in PHP” is simply not true. The ecosystem above is actively maintained, actively shipped, and actively adopted.

Myth 7: “Writing Rust or Go today is sometimes even faster than writing PHP”

Sometimes it is, yes. As a general statement, it is not.

For systems work, such as daemons, CLI tools, networked services, and embedded software, Go is competitive with PHP on developer speed. Rust has also gotten dramatically better with cargo, clippy, and AI assistance. If the workload is “build a TCP server” or “write a Kubernetes operator,” the comparison favors Go.

For typical web application work, which includes forms, authentication, CRUD, ORM, templates, queues, mail, jobs, caching, sessions, file uploads, pagination, and admin interfaces, PHP remains dramatically faster to develop in than Go. It is also much faster to develop in than Rust. This is not a controversial measurement. It shows up consistently in framework benchmarks, in developer surveys, and in the simple empirical observation that the overwhelming majority of CRUD web apps in production are still written in PHP, even at companies that employ Go and Rust engineers for other parts of their stack.

The claim that AI assistants make Rust as fast to write as PHP is the kind of thing that sounds plausible at a whiteboard and falls apart the moment you try to ship a multi-tenant SaaS in both and time it. An AI can draft a mail queue in Rust, and then you get to debug it. AI assistance compresses the gap on syntax. It does not compress the gap on ecosystem maturity for the typical CRUD workload. Laravel’s auth, migrations, mail, queues, broadcasting, and Eloquent still have no real Rust equivalent. Asking an AI to write them is not the same as having them already exist and documented.

Myth 8: “PHP has no cost or security advantage over Rust or Go”

The security comparison is debatable and workload-dependent. The cost comparison is not.

On cost, shared PHP hosting remains dramatically cheaper and more widely available than Rust or Go hosting. PHP developer labor is also more abundant and, in most markets, cheaper than Rust or Go developer labor. This is not a marginal difference. The salary gap between a senior PHP engineer and a senior Rust engineer is often substantial, and the talent pool for PHP is meaningfully larger in essentially every major market. For an organization optimizing for cost-to-ship, this is a real, durable advantage that no amount of Rust enthusiasm erases.

On security, PHP has had serious runtime-level CVEs, including recent ones, and the Zend Engine’s C-level memory safety track record is real. These are well documented. The comparison only works when Rust and Go have no equivalent, and they do. Rust’s unsafeblocks have produced their own CVEs, and popular unsafe crates have shipped memory-safety bugs. Go has had its share of standard library vulnerabilities. Both languages also carry supply-chain risk through crates.io and the Go module proxy. The shape of the risk differs, but “Rust has no security disadvantages relative to PHP” is not a defensible statement. It is a marketing line, and marketing lines do not pass code review.

The honest version of this comparison is that PHP has a different security profile than Rust or Go, with a worse memory-safety history in its runtime and better tooling maturity for typical web workloads. That is a real conversation worth having. The phrase “PHP has no security advantage” is a slogan, not an argument.

What’s actually true

None of the above means PHP is perfect. The Zend Engine’s memory safety record is a real problem. WordPress plugin security is a swamp, and the alligators are mostly plugins. Legacy PHP codebases from 2008 are, in the long term, awful to maintain. PHP is not always the fastest language on raw CPU benchmarks: it might never be.

And the eight myths above do not help anyone fix those problems. Myths 1, 2, and 5 are factually outdated. Myths 3 and 4 are conceptually confused. Myths 6, 7, and 8 are empirically false. Repeating them does not make PHP better, and it does not make the critic look informed. It just makes the conversation slower.

If you want to criticize PHP in 2026, criticize it for what it actually is. It is a managed, JIT-compiled, increasingly typed language. It has a real memory-safety problem in its C runtime, an enormous installed base, a thriving modern framework ecosystem, and a long tail of legacy code that nobody enjoys maintaining.

That is a real critique. And, in the end, PHP delivers.