Start shipping the compiler with your code for infrastructure-agnostic RCEs
Anyway, turns out that shelling out to an external binary fed with bytes from the Internet is good fun
b) It's a legacy misfeature that I hope new compiled languages don't copy. There are much much better better interfaces for running processes that don't rely on an intermediate shell.
c) Shell escaping is much more stable than some hipster language like PHP where you'd need to update your escaping for new language changes all the time.
https://duckduckgo.com/?q=crypt+site:reddit.com/r/lolphp
>crc32($str) and hash("crc32",$str) use different algorithms ..
>Password_verify() always returns true with some hash
>md5('240610708') == md5('QNKCDZO')
>crypt() on failure: return <13 characters of garbage
> strcmp() will return 0 on error, can be used to bypass authentication
> crc32 produces a negative signed int on 32bit machines but positive on 64bit mahines
>5.3.7 Fails unit test, released anyway
The takeaway from these titles is not the problems themselves but the pattern of failure and the issue of trusting the tool itself. Other than that if you've used php enough yourself you will absolutely find frustration in the standard library
If you're looking for something more exhaustive there's the certified hood classic "PHP: A fractal of bad design" article as well that goes through ~~300+~~ 269 problems the language had and/or still has.
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Though most of it has been fixed since 2012, there's only so much you can do before the good programmers in your community (and job market) just leave the language. What's left is what's left.
Lingering bad reputation, from the bad old days
Minimal barrier to entry - which both makes it a go-to for people who should not be writing production code in any language, and encourages many higher-skill folks to look down on it