7.4 has been especially exciting with the introduction of FFI. Few other languages even have runtime FFI, and in most cases you have to do the binding stuff in C.
I even ported a terminal-mode text editor (which uses FFI somewhat) from C to PHP: https://git.timshomepage.net/timw4mail/php-kilo
I would guess most of the PHP haters got stuck working on Wordpress, or someone's old business app, or they just hate PHP because it's popular to do so.
So, kudos for PHP for doing this. Not exactly a game changer, though. The performance cargo cult dislikes libffi as it can be relatively slow compared to an inline binding (static or dynamic) due to the need to copy input parameters (by reference, not by value) to an intermediate data structure on every invocation, and due to the fact that some JIT'd languages can JIT through the external function invocation (LuaJIT can do this, IIRC). It's ridiculous, but it is what it is; libffi effectively "taints" FFI support as non-native, which is a death sentence these days.
I think PHP is a horrible, cobbled together language. If the core maintainers had a strong grounding in language theory, design, and practice, they do an impeccable job filtering it out of the final product. It's been this way from the very beginning, and by everything I see today, remains so. That said, it's the first thing I turn to when I need to put up a simple web page with server-side logic! I have absolutely no desire or tolerance to fsck around with CGI, modules, packages, or anything else, and the PHP ecosystem Just Works out-of-the-box on every system (Linux, BSD, Windows) I've ever tried it on.
[1] Such parsers are kind of useless. Better to provide built-in sizes for core system data types like time_t and then, optionally, provide a simple, quasi-C grammar for expressing redundant definitions that you parse inline. Which is presumably how such parsers are used in practice, notwithstanding the pretense. Plus, I run all my web applications in jails (chroot, pledge, seccomp, etc). If system and library headers are visible at runtime, something is broken. If someone really wanted to go the extra hundred miles for proper automagic bindings, one could use ELF symbol information, for example debug symbols (e.g. DWARF) or simpler symbol info (e.g. BTF on Linux, derivative of Solaris' ABI metadata, which was directly supported by OpenBSD before the Linux project got started).
urg and then ?? We will have just another Python, C, .Net or Go, which are all good for some ppl and some things.. Sometimes you just need some outside the box thinking...
PHP is great despite itself. But great it is. You can say that about many popular software tools, but PHP is unique in effectively going unchallenged in its domain, iteration after iteration, decade after decade, quirk after quirk. ColdFusion was the only real competitor, but it died when they tried to replace CFML with CFScript. (Well, also because ColdFusion was proprietary.)
People believe languages become popular because of their design features, but if that were true we'd all be writing in Haskell and Scheme with shims for C-family, imperative-style syntax. In truth language features, including syntax, are usually driven by implementation barriers that arise early in a language's evolution, starting with the choice of GC or no GC. The language succeeds despite itself. Lua is a uniquely elegant language precisely because the Lua authors eschew backwards compatibility between every significant release. Every major release of Lua (which looks like a minor release if you expect SemVar) involves a wholesale refactor of the implementation, and syntax breaks are judiciously allowed (i.e. more weight is given to implementation complexity than to compatibility convenience, relative to other languages). It drives people nuts, but the product of this process is the only reason one comes to use Lua in the first place. Functional language families have a leg up in this regard, but ultimately it still plays out the same way, which is why not all functional languages are the same. PHP stands out for having no legitimate excuse for its quirks beyond, "we don't need to bother because we're unchallenged [for myriad accidental reasons]."
[1] For example, JavaScript's lexical scoping quirk derives from its original half-baked implementation. But the Lua authors published a paper many years before PHP got closures (possibly more than a decade before?) that explained their technique for implementing proper, quirk-free lexical closures in just a handful of lines of C-like example code. And Lua's compiler compiles to bytecode as it parses, much like early C compilers, so it doesn't have the benefit of arbitrary lookahead or multiple passes. Someone elsethread asked why PHP (and some other languages) require explicit variable bindings for closures. People like to say that they prefer this syntax, but regardless of whether it's preferable, the fact of the matter is that in practice it happens because it's easier to do it that way, especially for statically typed languages. (Except it's not necessarily easier, as Lua shows.)
That sounds interesting, do you have a link to that paper? (I couldn't find it with a quick Google.)
The most often cited siblings to PHP have ffi implementations. Built into python now. Ruby, Perl, and Node.js all have popular extensions for it. Libffi opened this up for a lot of languages.
[1] https://en.wikipedia.org/wiki/Foreign_function_interface
Not even technically correct: I mean, Windows for IoT doesn't even need to have any windows, therefore it's not actually Windows, eh? (No. That was a joke.)
In other words, PHP is still "PHP hypertext preprocessor", even though it is used far more generally.