FAQ
Maturity, compatibility, architecture and realistic expectations for the project.
No. It is an experimental runtime under active development. The language core is broad and real software already runs, but extensions, web SAPI, hardening, packaging and load performance have not reached the level required to replace PHP in production.
No. phpr parses PHP source, lowers it through intermediate representations, compiles bytecode and executes that bytecode in a VM written in Rust.
The project explores a modern, memory-safe foundation without linking PHP's C core. Compatibility is preserved by observing behavior rather than copying the internal architecture.
The snapshot published on this site uses PHP 8.5.7 as its oracle. The repository can move quickly; the Status page always includes the date and oracle version behind its metrics.
For a verified case, stdout, warnings, errors and expected formatting match the reference runtime under the relevant .phpt rules. It does not mean every part of PHP is compatible already.
Not directly. Several extensions are reimplemented in Rust or backed by targeted native libraries. An FFI compatibility layer for the PECL tail is a long-term option, not a current capability.
No. Rust provides memory-safety tools and architectural control, but performance must be measured. Correctness is the current priority; preload, VM pools, JIT and async I/O belong to later phases.
No. It is an independent project. PHP and Rust are referenced to describe the compatible language and the implementation technology.
The direct path is to pick a failing official test or missing builtin, reproduce behavior with PHP 8.5.7, implement the difference and verify that no green test regresses.