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.
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.
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.
I've just tried to apply it to a medium-sized project, and it spitted tens of thousands of errors where phpstan and psalm don't see any. At first glance, it's because Mago does not parse phpdoc. In its current beta state, Mago is meaningless for all the big PHP projects, which are its main target.
Mago might succeed, but I wouldn't bet on it. Its main selling point is that it promises to be faster than the usual static analysers-linters (phpstan and psalm). But if it does not reach feature parity with them, the speed gain probably won't convince PHP projects to drop the standard tools. Since phpstan and Co keep evolving, keeping feature parity will require constant work. And PHP is more niche than Python or JS, so contributors mastering Rust and PHP will be fewer, compared to phpstan/psalm which are written in PHP.
Seen this around quite abit over the past few days. I wish the github landing page/readme would actually substansiate why this is better beyond it being written in rust which seems to be the main argument for the tool right now. I make my money from PHP, I preffer stability.
With Phpstan and Psalm already in the space I'd like to see more differentiator features than 'written in Rust' - there are certainly advantages to that, but the disadvantage of not using PHP is it's harder to get contributions from the community using the tool.
11 comments
[ 3.3 ms ] story [ 25.0 ms ] threadTools 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.
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
If it has remotely the same success, that would be a huge win for the ecosystem!
I've just tried to apply it to a medium-sized project, and it spitted tens of thousands of errors where phpstan and psalm don't see any. At first glance, it's because Mago does not parse phpdoc. In its current beta state, Mago is meaningless for all the big PHP projects, which are its main target.
Mago might succeed, but I wouldn't bet on it. Its main selling point is that it promises to be faster than the usual static analysers-linters (phpstan and psalm). But if it does not reach feature parity with them, the speed gain probably won't convince PHP projects to drop the standard tools. Since phpstan and Co keep evolving, keeping feature parity will require constant work. And PHP is more niche than Python or JS, so contributors mastering Rust and PHP will be fewer, compared to phpstan/psalm which are written in PHP.
With Phpstan and Psalm already in the space I'd like to see more differentiator features than 'written in Rust' - there are certainly advantages to that, but the disadvantage of not using PHP is it's harder to get contributions from the community using the tool.
Cool project overall!