HHVM is an interesting data point too - kept PHP compatibility for as long as there were significant open-source users (eg wikipedia), but after PHP7 caught up with a lot of the performance gains, meaning there was little reason to use HHVM in PHP-compatibility mode, they then went off in their own direction with Hacklang (which is still actively developed) to get all the benefits of being PHP-like without the drawbacks of being PHP-compatible.

>get all the benefits of being PHP-like without the drawbacks of being PHP-compatible

I have a hard time understanding the benefit of using a language that’s almost like a very popular one, but not quite.

PHP has some benefits to its design that the vast majority of other languages don’t — deployment is as simple as “stick a .php file on in your website folder”, hitting the “refresh” button gets you the latest code with no “build” or “restart server” step, it’s all stateless shared-nothing so you won’t have data from one request changing the behaviour of another request, etc.

But the implementation has a lot of drawbacks - the language is painful, typing is bolted-on and still incomplete after years of work (eg there are no typed arrays), the standard library is an inconsistent mess thanks to its origins of “take several other language’s standard libraries and duct-tape them together”, etc.

Yes I’m well aware of the problems. I just seems to me that being PHP-like but incompatible is much more confusing than useful.

“PHP-like but incompatible” isn’t in itself a useful feature — it is the thing which unlocks a bunch of useful features (a sensible standard library, sensible list/dict datatypes, typed collections, XHP, async functions, generics)

I get that. A superset could be interesting. Downright incompatible seems to tip the balance the wrong way.

PHP is a fractal of bad design[0] and creating a superset will not enable you to create a better language.

[0]: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/