[arp242]

A lot of PHP usage is inherently multi-process; 100 users accessing your PHP app are essentially 100 processes, often with a few of them running in parallel. Doing any sort of file i/o really does require thinking about these sort of things, and it's something I've run into.

And this is not exactly a huge ask, or a very obscure function call. You can kind of work around all of this if you're careful, but it's not exactly brilliant is it? Literally every other mainstream language can do this. This is really a "only in PHP" type of thing.

Just say "yeah, this is still a downside of PHP; hopefully it will get improve one day!" Fine. Fair enough. No language is perfect and I'm not here to bash PHP. I consider this to be a major pain point, but other people do other things and maybe it's less of an issue for them. Also fine. What I don't get are these contortionist tricks – I already knew how this would go when I posted it: first there would be the "but you can do this", and then when mentioned that's not really sufficient the "yes but you don't need that anyway".

[trog]

We ran several quite popular (millions of monthly users) PHP websites for almost two decades and never ran into any issues of this nature, including a lot of local on-server file I/O. I don't recall doing anything specific or particularly advanced to deal with these issues, just some basic encapsulation was enough and it worked seamlessly.

[some_furry]

If it's a pain point, write an RFC. Make the language better. Don't just shrug and say "it sucks"

[arp242]

Eh, you can constructively critique things without spending tons of effort on fixing it.

What a painful and unpleasant conversation this is turning out to be.

[some_furry]

> What a painful and unpleasant conversation this is turning out to be.

Finally, something we both agree on