I initially thought this was a PHP implementation in Rust.... but it's not
Will Mago implement a PHP runtime?
Absolutely not. The PHP runtime is incredibly complex. Major efforts by large companies (e.g., Facebook's HHVM, VK's KPHP) have struggled to reach full parity with Zend Engine. Achieving this as a smaller project is infeasible and would lead to community fragmentation. We are focused on tooling, not runtimes.
Not really? .NET has a "Common Language Runtime", which you can think of as analogous to the Java VM or to Beam.
A transpiler might read PHP and spit out C, or Java or some other existing programming language, spitting out the code for a virtual machine doesn't make you a transpiler unless you're going to argue that all compilers are just transpilers, it's like one of those "Actually goats are fish" arguments. OK, but now the word "fish" is useless so why go to this bother ?
All the language tools that are being displaced by newer rust replacements were definitely not written in C/C++. They were/are written in the host language (js/java/python/php/ruby).
To be fair it is pretty significant. Especially uv. I don't know anything about PHP's existing toolchain but I do know that Python's is a horrifying mess, and uv basically fixes it.
It's a small thing in the Rust community but it's pretty huge in the world simply because there are so many Python developers (and also because of the extreme magnitude of improvement). Probably wouldn't have happened without Rust.
Thanks to Rust, there are heaps of next generation CLI utilities that have come onto the scene in the past decade. Cross platform by default, UTF8 aware, more likely to be multi-threaded, simple distribution, and most importantly - improving on some unfortunate legacy API decisions.
Ripgrep, fd, tokei, Just, zellij, uv, and so forth. Porting languages has given the opportunity to remove some of the cruft decided on a whim in the 70s. None of these are world changing, but they do make life easier than the originals.
Not the biggest, but definitely the most visible to people who aren’t dialled into Rust news. For example, many people use Android but they wouldn’t know or need to know that their Bluetooth stack is written in Rust.
Whereas anyone who uses Python would have heard of uv and why it’s much faster than other tools.
It is very cool that this exists, but the PHP community lacks the resources to see a non-PHP tool thrive.
Tools like Sorbet (C typechecker for Ruby) or tsgo (Go-based successor to TypeScript's typechecker) are only viable because big profitable companies can back them up with engineering hours.
True but TypeScript and Sorbet are magnitudes above linting and formatting PHP, in terms of challenge size.
TypeScript is a very complex language with a huge mission. From the same creator of C#.
Sorbet is trying to tame a dynamically typed language which supports monkey patching. Stripe can get away with it because they have close to infinite money and a large Ruby codebase.
Meanwhile PHP is stable and typed. Parsing AST, linting and formatting are trivial in comparison to the examples you cited. Their package manager, composer, is also boring a stable, in a good way. Prime target for a second pass if need be.
All of this already exists and each separate product is actively developed, keeping up with all of the changes in PHP. This toolset looks too ambitious.
Astral did something similar for the Python ecosystem (Rust-inspired tooling built in Rust, replacing a lot of pre-existing - bad - tooling) & the impact has been revolutionary. Python had some of the worst tooling of any popular language & now has some of the best.
Composer is one of the best package managers in any language ecosystem but beyond that, other PHP tooling, while technically well maintained, aren't particularly great at what they do. It's an ideal starting point for positive disruption.
I initially thought this was a PHP implementation in Rust.... but it's not
Will Mago implement a PHP runtime?
Absolutely not. The PHP runtime is incredibly complex. Major efforts by large companies (e.g., Facebook's HHVM, VK's KPHP) have struggled to reach full parity with Zend Engine. Achieving this as a smaller project is infeasible and would lead to community fragmentation. We are focused on tooling, not runtimes.
https://mago.carthage.software/faq
> The PHP runtime is incredibly complex
Say this to the team behind Ladybird browser: https://awesomekling.substack.com/p/how-were-building-a-brow...
They have the benefit of a project leader with many years of browser implementation experience AND much lower performance goals.
(Items 5 and 3 on the list in the linked page.)
80/20, also they're not implementing JIT and such because of complexity.
https://www.peachpie.io compiles PHP to .NET.
Isn't this more transpiling than compiling?
Not really? .NET has a "Common Language Runtime", which you can think of as analogous to the Java VM or to Beam.
A transpiler might read PHP and spit out C, or Java or some other existing programming language, spitting out the code for a virtual machine doesn't make you a transpiler unless you're going to argue that all compilers are just transpilers, it's like one of those "Actually goats are fish" arguments. OK, but now the word "fish" is useless so why go to this bother ?
seems rust's biggest win was improving other languages toolchains and bringing increased productivity to those languages.
Not a bad win so far, right? One hand washes the other and both wash the face.
I am waiting for someone to build a modern scripting language in Rust that has the popularity and rich tooling and capabilities of Rust as a result.
Like Gleam?
It doesn't have imperative constructs I think. So half of developers or more are out front the get go.
You're wrong because it's also incrementally replacing individual, high-risk components in Windows and Linux.
But even if you're not wrong, a major mission of Rust was to be a safer C/C++, and language tooling used to be dominated by those languages.
All the language tools that are being displaced by newer rust replacements were definitely not written in C/C++. They were/are written in the host language (js/java/python/php/ruby).
Do you really think that this is Rust's biggest win or are you just joking/trolling?
To be fair it is pretty significant. Especially uv. I don't know anything about PHP's existing toolchain but I do know that Python's is a horrifying mess, and uv basically fixes it.
It's a small thing in the Rust community but it's pretty huge in the world simply because there are so many Python developers (and also because of the extreme magnitude of improvement). Probably wouldn't have happened without Rust.
Thanks to Rust, there are heaps of next generation CLI utilities that have come onto the scene in the past decade. Cross platform by default, UTF8 aware, more likely to be multi-threaded, simple distribution, and most importantly - improving on some unfortunate legacy API decisions.
Ripgrep, fd, tokei, Just, zellij, uv, and so forth. Porting languages has given the opportunity to remove some of the cruft decided on a whim in the 70s. None of these are world changing, but they do make life easier than the originals.
Not the biggest, but definitely the most visible to people who aren’t dialled into Rust news. For example, many people use Android but they wouldn’t know or need to know that their Bluetooth stack is written in Rust.
Whereas anyone who uses Python would have heard of uv and why it’s much faster than other tools.
So I guess this is `uv`, but for PHP?
If it has remotely the same success, that would be a huge win for the ecosystem!
It's more like `ruff` for PHP.
No its different, php already has a good package manager, this is about formatting, linting and type checking
Love seeing some Tunisian representation here ! Kudos on the project !
It is very cool that this exists, but the PHP community lacks the resources to see a non-PHP tool thrive.
Tools like Sorbet (C typechecker for Ruby) or tsgo (Go-based successor to TypeScript's typechecker) are only viable because big profitable companies can back them up with engineering hours.
> PHP community lacks the resources to see a non-PHP tool thrive.
Why do you think so?
The PHP Foundation has raised over 2 million USD in contribution and has over 500K in their balance currently according to:
https://opencollective.com/phpfoundation
PHP has some well funded groups using it like Wordpress, Wikipedia, Laravel to name a few.
And recently the PHP Foundation started officially sponsoring a Go project, FrankenPHP.
https://thephp.foundation/blog/2025/05/15/frankenphp/
So PHP looks like a friendly and well supported community to foster tooling made in other languages.
> The PHP Foundation has raised over 2 million USD in contribution and has over 500K in their balance
This is great, but it is still dwarfed by the amount Microsoft has spent on TypeScript and also by the amount Stripe has spent on Sorbet.
500k is roughly comparable to the amount my previous company spent (grudgingly) to keep me employed and working on PHP tooling for a couple of years.
True but TypeScript and Sorbet are magnitudes above linting and formatting PHP, in terms of challenge size.
TypeScript is a very complex language with a huge mission. From the same creator of C#.
Sorbet is trying to tame a dynamically typed language which supports monkey patching. Stripe can get away with it because they have close to infinite money and a large Ruby codebase.
Meanwhile PHP is stable and typed. Parsing AST, linting and formatting are trivial in comparison to the examples you cited. Their package manager, composer, is also boring a stable, in a good way. Prime target for a second pass if need be.
Interesting. Do you have any thoughts to share along the same lines about FrankenPHP?
It's cool that it's part of the PHP foundation, but it's not all that complex.
FrankenPHP has >100 contributors, including 3 very frequent ones, and about 17k lines of Go.
Mago has 11 contributors, with just 1 very frequent one, and about 135k lines of Rust.
All of this already exists and each separate product is actively developed, keeping up with all of the changes in PHP. This toolset looks too ambitious.
Astral did something similar for the Python ecosystem (Rust-inspired tooling built in Rust, replacing a lot of pre-existing - bad - tooling) & the impact has been revolutionary. Python had some of the worst tooling of any popular language & now has some of the best.
Composer is one of the best package managers in any language ecosystem but beyond that, other PHP tooling, while technically well maintained, aren't particularly great at what they do. It's an ideal starting point for positive disruption.
I really wasn't using Composer for last couple of years. Did it already stopped eating 2GB RAM for any project that use framework like Laravel?
Composer is a good tool, but it's resource usage was abysmal.