Maybe it’s the frequency that you use the language? I go maybe 5-10k loc between needing to lookup anything in the docs at all, and 5-10x that where the issue I need guidance on isn’t in the formal doc.

Much more frequently I’m looking up something related to the tools and libraries I’m using.

The only surprising thing I’ve learned about PHP at the language level in the last 6-10 months is that you can call array_filter() without a callback to cull nulls.

It could be, but I also never felt like I really got to the point you're talking about in 2 years or so of moderate usage. I've been productive in it, and it's not like I'm hung up on control flow or something. I don't hate the language either. I still have to use it from time to time, but it just doesn't seem like it makes sense for a lot of green field work due to this.

It's mostly things like parameter order for certain built-ins that aren't intuitive and/or finding built-ins I've never used or heard of because there are so many obscure ones (there are nearly six thousand) that keep me coming back. For example, how do you disable errors in a DOMDocument? It ought to be as easy as DOMDocument->setAttribute("errors", "false"), but no it's a separate function call to libxml_use_internal_errors(true). There are like five other similar function calls for this too. PHP has abstraction leaks and little inconsistencies like this everywhere.

Granted, languages with small standard libraries, like JavaScript, by contrast get an easy cop out to blame the community of various package maintainers here. But at least in that case someone can always just write a better library.

Does that only cull nulls, or also zeroes, falses and empty strings?

Anything "falsy" -- any item that, when cast to boolean results in false. So, also zeroes, falses and empty strings.

That was my point - OP said it "culls nulls", and the pitfall is that kind of thinking - if you think of it as removing nulls and you're not mindful, you might be deleting things from the list you don't want to be deleting.

Do you really though, or are you being a bit hyperbolic? It's really not that complicated or arbitrary. If you find yourself hitting idiosyncrasies so often you've got the docs open you might just be doing it wrong. There's also some learning to do for any language, no language is so intuitive that you know it without any effort or learning.

All the above said, do enough real work in any language and you'll find cases where the idioms of the language don't map to your work.

PHP isn’t consistent with itself and has abstraction leaks for things that it shouldn’t. PHP does not bring me joy.

Of course I’m speaking succintly above. It’s not that bad, but it’s not that much better either. I’m not going to stockholm myself into using a language just because it’s “mature” if I don’t have to. I may have that relationship with JavaScript but at least in that case resistance is somewhat futile and there are practical benefits to be had.

I don't know any language that this statement isn't true about unless either:

(a) you're a true, deep expert who uses the language all day every day

(b) the docs are so poor it's not even worth having them open

Go might be a contender save for a couple weird features. JS might be with a few ground rules and/or enough tooling.

I’m also willing to grant implicitly that there are tradeoffs here. Languages with small standard libraries usually have big community libraries and vice/versa.

JS isn't directly comparable due to the very delineated nature of ECMA -vs- DOM/NodeJS APIs - ECMA is pretty easy to internalise but you'd be hard pressed to get by without MDN DOM or NodeJS core API docs open (unless as you say you're abstracting them with community libs as you say).

I've only used Go sparingly - I heavily relied on docs, but yeah it may have a shallow learning curve. It's certainly much saner than Python (which seems to be the other language used in my "space" for e.g. ad hoc ops tooling, etc.)

Get a better IDE. Visiting docs for checking return values should be a thing in the past.

My approach (very similar than when I write C or raw JS) is to use a few "cleanup" APIs or libs that hide the nasty stuff (string handling / array iteration / SQL building), because I know I don't want to deal with all the footguns. There were rarely is a performance argument that would need me to do otherwise.

I use PHP daily at work, haven't had to check the docs for quite a while