Ruby, Python, C#, Java, and JavaScript are all are more predictable and just as useful. Go, Elixir, Clojure, and probably others are more predictable while being less "useful" only in the sense that they may have less convenient deployments or less mature web libraries.

I've used Python, C#, Java, JavaScript and PHP, and in my experience Python is the most unpredictable of these languages. Just to name a few: - mutable default arguments - late binding closures - typings that are purely documentation instead of being enforced

Labeling these things as "gotchas" doesn't make them predictable imo.

Python less predictable than PHP? In what world? In PHP standard library functions silently take a null instead of a string, even though they are string handling functions, hiding that mistake for the user of the language, until a later point in time, when the context has been lost and one needs to do silly debugging, until one finds the place where the null first was handled, while it should have raised an error. Such is the silly character of PHP standard library. Many functions also have multiple return types, which makes it difficult to simply use the result of one as input to another.

If predictability means to predict, that standard library will behave nonsensically, then yes, PHP has the one high predictability.

> silently take a null instead of a string

Oh, so you _haven't_ used any of the recent versions of PHP, then. You're just talking shit with no actual recent experience. Gotcha. Well, thanks for your input.

Look what I got here for you:

    docker run -it php:8.0 bash
    # php -a
    Interactive shell

    substr("abcdef", 3);
    // no result

-- Ah right, PHP does things differently than other almost every other language that has a REPL and I have to echo a value, which was just returned, even on the REPL ...

    php > echo substr("", 3);

-- Silently hiding the error. Idiocy.

    php > echo substr(null, 3);

-- Silently hiding the error. Idiocy.

    php > echo substr("abcdef", 3);
    def

Who is shit talking now? Are you suggesting, that all this is normal and OK? Nothing is fixed. It's still badly designed and probably will remain shitty like that, until PHP programmers finally realize, that this needs to be properly fixed.

EDIT: Of course the docs also do not mention this to happen at all and tell you, that the first argument must be a string. So I guess that means, that in PHP terms, null is a string. Great for type safety!

These problems were fixed in PHP 8.0 and 8.1

https://wiki.php.net/rfc/engine_warnings

https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_a...

Go is more difficult to deploy than php? php.ini files and php extension installations to get to production is what I remember

No, I was thinking 'less mature web libraries' for Go. It's hard to talk about groups of languages in broad strokes when there are various tradeoffs and each language has its own strengths and weaknesses, and I painted two possible weaknesses broadly across several languages that don't strictly apply to all of them.

I am starting to find PHP bearable as soon as they are starting to follow Python language and precepts (like libs for humans, code readability instead of shorthands,...)

Python covers many of the same use cases and is much more consistent/predictable. TCL if you want to go back a bit further.

I've never experienced the same kind of out-of-the-box problems with PHP as I have Python. I seem to suffer constantly from python/python3, pip inconsistencies and stuff just breaking constantly.

Python build/package management tooling is a joke, but Python the language is very consistent and usable.

Ooh, now that's a good question.

Which is more important really? I genuinely don't know the answer to this.

I don't think it's an either/or; more like both language and tooling can eat into your annoyance budget and you look for the combination that has the lowest overall cost.

With Python one never knows when a particular feature code depends on will be removed. With PHP code written 15 years ago still works.

> With PHP code written 15 years ago still works.

If you never upgrade, sure. PHP 7 and each minor version in it have deprecated and removed plenty of stuff that was legal in 5.6. PHP 8 is on track to do more of the same. I think the backwards incompatible changes are pretty much all good for the language, but claiming backwards compatibility in PHP is completely wrong.

If you aren't on PHP 8, you aren't supported, and if you're on anything earlier than 7.4, you aren't getting security releases. And the new versions released yearly all have breaking changes, and get three years of security support. It's not 2015 anymore.

What features have been removed from Python?

Besides the obvious 2 to 3 transition, cpython has obsoleted or renamed stdlib modules several times between 3.x versions. For example, the collections.abc change causes several common Linux bits to break if you change the system default to 3.8.

Which is a double edged sword. How many ways can one escape a string, and for how many of them will you find a stack overflow comment from a decade ago saying are the secure option to use?

ruby...