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.

▲

muglug 3 days ago | parent [-]

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.

▲

hu3 3 days ago | parent [-]

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

▲

muglug 3 days ago | parent [-]

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.

	▲	hu3 3 days ago \| parent [-]
		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.