undefined | Better HN

0 pointspdimitar4y ago0 comments

> It's traditionally run as a shared-nothing single-threaded script, which makes it easy to reason about, and in real life has proved to be a stable way to run things in production.

I think we have a vastly differing definition of "in production". I'll agree PHP was good enough for plenty of things, and likely still is. But good enough in general to run things in production as it's understood today? You'll find that many people will disagree with you here, not just me.

> Later versions have introduced a JIT and support for concurrency concepts such as fibres, as in the upcoming PHP 8.1 https://php.watch/versions/8.1/fibers.

That's what I mean, not only for PHP but for like 99% of all programming languages: they play catch-up, waaaaaaaaay too slowly and gradually, with things that should be baseline by now. Happily Erlang/Elixir are having lightweight and transparent parallelism and concurrency for a long time now. Languages like Go and Rust also progressed very well in this area so I am looking to work more with them in the future as well.

---

I think you and I are not aligned on what is "successful" or "good enough". You seem to insist that statistical success speaks something of the merits of a technology, and this is where I and many others disagree: people just adapt to what's given to them. That doesn't say almost anything about if the thing is good or not. People simply get what they can. Back then PHP was available so they took that. The rest is post-hoc rationalization. Stretching the simple and isolated historical fact "people used PHP because there was nothing else viable at the time" to mean that "PHP is good and successful" is where I'll disagree with you.

But yep, we severely digressed from the original discussion. I am OK with that though.

0 comments

heurisko4y ago

> I think we have a vastly differing definition of "in production".

Running software that customers use, directly or indirectly.

I've supported servers running PHP and Java software in production. The shared-nothing per-request nature of PHP meant I didn't have to deal with a bug in a misbehaving library causing memory leaks and taking down the application server.

> That's what I mean, not only for PHP but for like 99% of all programming languages: they play catch-up, waaaaaaaaay too slowly and gradually, with things that should be baseline by now.

PHP's problem domain has been web-based e-commerce and content management systems. In this area, PHP powers most of the web. You'd want to use PHP in this field, over other languages. Every improvement around PHP has been to advance this goal, such as the recent addition of gradual typing. There's no question of "catching up" in this area. That it is broadening out into different areas, great.

> You seem to insist that statistical success speaks something of the merits of a technology.

If the technology doesn't have a marketing department, or large companies forcing people to use it, then arguably, this does, as otherwise people would just use something else.

There have also been many other qualitative improvements to PHP over the years. I also mentioned its shared-nothing architecture, which is a qualitative, not statistical aspect behind PHP's success, as it has proven to provide stability in production. People use PHP because in certain problem domains, it is qualitatively, and statistically (assuming you mean, it benefits historically from a wide number of successful, maintained libraries) the best tool for the job.

j / k navigate · click thread line to collapse