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.
I would posit that you do not know what you’re talking about. Mayo is also a static analysis tool that does typechecking. It incorporates and is heavily influenced by code I wrote.
I'll assume you meant Mago instead of Mayo.
Why do you feel the need to personally discredit me instead of sticking to constructive arguments?
And where did I say Mago wasn't a static analysis tool?
I'm glad you wrote Psalm. However I and most of the PHP community use https://phpstan.org instead, as you may know.
At the time I made this choice on technical grounds. Then PHPStan found a way to stay profitable with PHPStan Pro while Psalm stagnated, which cemented my decision. Recently, vimeo being acquired by Bending Spoons doesn't help either since psalm still lives in https://github.com/vimeo/psalm
I wasn’t talking about Psalm - I was talking about Hakana, a Rust project that informs much of Mago’s type-checking architecture. Hakana was designed to analyse Hack, a fork of PHP that doesn’t support PHP magic methods and so is much easier to analyse statically.
The big challenge to typechecking PHP is that it’s essentially two different languages — there’s typechecking code like Laravel that makes heavy use of magic methods (effectively impossible statically) and typechecking code that doesn’t (very doable).
Psalm was mostly designed for the latter, whereas PHPStan excelled at the former with dynamic analysis in plugins like Larastan.
That dynamic analysis — where you have to run some PHP code to make sense of a PHP codebase — is another big reason a Rust-based tool will have a hard time becoming popular in the PHP ecosystem.
Thanks for the information. I understand the challenge now.
And yeah, the parts which I don't like about Laravel are usually related to magic. IDEs often need extensions to understand Laravel which imo is not a good look.
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.