Psalm in another language

[muglug]

Broken off from a discussion.

Before I passed the maintainer torch I wrote up a document about where I saw Psalm's priorities. The first point was the most important priority: Psalm is a tool for PHP written in PHP.

I now have a bit of experience working in Rust, where I'm building a static analysis tool for Hack. Hack, for those who don't know, is a language that was once just "PHP with types" but has grown to be a somewhat different language with an engine (HHVM) which exhibits subtly different behaviour from PHP's Zend engine in a number of different areas (for example PHP_INT_MAX + 1 overflows into PHP_INT_MIN).

Psalm could be ported to Rust, but then it would no longer be Psalm, a PHP-based tool that anybody who knows PHP can theoretically contribute to. You'd get about a 5-6x speedup, but you'd have lost the soul of the project.

Besides that, there are two other major reasons why another language is not a good fit for Psalm:

Parsing

Psalm uses the semi-official PhpParser — semi-official because its creator is a longtime core contributor. The static analysis tool I'm building for Hack also uses the equivalent official parser, which happens to be written in Rust.

There's no official PHP parser written in Rust or Go, and the parsers that do exist are intermittently updated, mostly by hobbyists. If you wanted to write a static analysis tool for PHP in either of those languages you'd be on the hook for parser updates as well, and that's a real bore.

Plugins

Psalm benefits from a large number of plugins. Writing and maintaing plugins becomes incredibly difficult in Rust or Go — you basically have to compile your plugins into the binary before running it, which is another real bore.

[AndrolGenhald]

Psalm could be ported to Rust, but then it would no longer be Psalm, a PHP-based tool that anybody who knows PHP can theoretically contribute to. You'd get about a 5-6x speedup, but you'd have lost the soul of the project.

Agreed, this is important. I'm not really convinced it's the most important thing, learning enough syntax in a new language to contribute a few minor changes is probably significantly easier than trying to fix some of the issues with templates for example, even though the code is in PHP, but it is important to some degree.

If you wanted to write a static analysis tool for PHP in either of those languages you'd be on the hook for parser updates as well

Yep, that's a big hurdle. When I've spent some time thinking about this I've always thought the best approach would be to use tree-sitter, which has a PHP parser and a Rust binding, but the support for some PHP features is incomplete, so that would also mean learning how to work with tree-sitter and contribute fixes to that project. I think that would be worthwhile anyway, because it appears that parser is used for other notable projects (like Atom), but it would be additional work.

Psalm benefits from a large number of plugins. Writing and maintaing plugins becomes incredibly difficult in Rust or Go

I think this is the big sticking point. I've thought about maybe trying to see if you could use ext-php-rs to either distribute the majority of the code as a PHP extension and have a small PHP wrapper, or distribute it as a binary but use ext-php-rs to allow executing PHP plugins. The main problem with this is that I'm not sure how much PHP maintains ABI compatibility between minor versions. It would at least mean distributing a separate binary per major version, and likely per minor version. That doesn't sound like something that would play well with composer, and being able to add Psalm as a dev requirement to composer and just have it work is a huge plus imo.

---

Are you averse to publishing what you've got out of a worry of fragmenting contributions to Psalm, or some other reason?

[muglug]

learning enough syntax in a new language to contribute a few minor changes is probably significantly easier than trying to fix some of the issues with templates

yes, but then it’s extra hard when trying to fix issues with templates aka generics

because it appears that parser is used for other notable projects (like Atom)

Atom has been EOL’d, but if you have time you should contribute, because a Rust-based PHP parser is a good thing that could be used by linters that need to be super-fast.

Are you averse to publishing what you've got out of a worry of fragmenting contributions to Psalm, or some other reason?

A few reasons — I don’t own the code (I’m building the tool at work), so I’d have to get permission. It has also departed some way from Psalm in a similar fashion to how Hack has departed from PHP, and anybody wanting to have it work with PHP would have to add that stuff back in a somewhat painful trial-and-error fashion. And even if all that were to happen, due to the plug-in issue the best it could reasonably be is a starting point for a large well-resourced company to build their own custom PHP static analysis tool on top of, not a general-purpose tool for the PHP community as it exists today.