[jack_pp]

I worked at a startup, they built their API in PHP because it was easy and fast. Now they're successful, app doesn't scale, high latency etc. What does their php code do? 95% of it is calling a DB.

You're telling me today with LLM power multiplier it's THAT much faster to write in PHP compared to something that can actually have a future?

[frio]

“PHP was so easy and fast that they’ve built such a successful startup they now have scaling problems” is, as far as I can tell, an endorsement of PHP and not a criticism of it.

[skeledrew]

I think the point here is that the scaling problem is hard because of PHP.

[Imustaskforhelp]

Scaling can be hard in PHP at the same time GGP comment's about PHP being in productive hands and thus being one of the reasons why PHP worked for them. Both of these can be true at the same time.

And for what its worth, Typescript scaling, although better than PHP is still somewhat of an issue and If you want to have massive scaling, Elixir/ (to-an-extent gleam) are developed for solving the scalability problem especially with Phoenix framework in Elixir-land.

So I guess, jack_pp comment's about PHP can also be applied to an degree towards Typescript as well so we should all use elixir, and also within the TS framework the question can be asked for (sveltekit/solid vs next-js/react)

I am more on the svelte side of things but I see people who love react and same for those who love PHP. So my opinion is sort of that everyone can run in their own languages.

Golang is another language to be taken into consideration especially with Htmx/datastar-go/alpine.

[hparadiz]

Scaling in PHP is easy. Has never actually been an issue in my entire career unless it was a badly designed database.

[PUSH_AX]

Yes, startup success has a direct correlation to the language chosen for your CRUD api…

[duggan]

> I worked at a startup, they built their API in PHP because it was easy and fast. Now they're successful

You can stop there! Sounds like PHP worked for them. Already doing better than 90% of startups.

[watermelon0]

If 95% of what app does is calling a DB, then the bottleneck is in the DB, not with the PHP.

You can use persistent DB connections, and app server such as FrankenPHP to persist state between requests, but that still wouldn't help if DB is the bottleneck.

[imron]

Sometimes it’s still the app:

   rows = select all accounts
   for each row in rows:
       update row

But that’s not necessarily a PHP problem. N+1 queries are everywhere.

[silon42]

Depending on what you are doing, the above is not necessarily bad.. often much better than an SQL that locks an entire table (potentially blocking the whole DB, if this is one of the key tables).

[NorwegianDude]

> I worked at a startup, they built their API in PHP because it was easy and fast. Now they're successful, app doesn't scale, high latency etc. What does their php code do? 95% of it is calling a DB.

So PHP worked perfectly, but the DB is slow? Your DB isn't going any faster by switching to something else, if that's what you think.

PHP is the future, where React has been heading for years.

[usrusr]

> Your DB isn't going any faster by switching to something else, if that's what you think.

Only true if none of the DB accesses are about stuff that could live as state across requests in a server that wasn't php. Sure, for some of that the DB's caching will be just as good, but for others, not at all.

[graemep]

That is possible, but it sounds unlikely to me.

In most cases you could add a shared cache to fix the problem - e.g. put your shared state in Redis, or in a file that is synced across servers (if its kept as state in a long running process it cannot need to be updated frequently).

[nake89]

Not scaling and high latency sound like a skill issue, not a PHP issue.

[Chaosvex]

What does this even mean? If you've got scaling problems, it's not because you've used PHP.

[arjvik]

by future do you mean Future<T> or metaphorical future? :)

[withinboredom]

I see what you did there.

[rurban]

PHP did better than python and perl. Python is doomed. PHP got a good jit already, a good OO lately, good frameworks, stable extensions. It has a company behind.

Unlike python or ruby which break right and left all the time on updates. you have to use bunkers of venvs, without any security updates. A nightmare.

PHP can scale and has a future.

[Incipient]

Python is doomed? That's new.

You use python docker images pinned to a stable version (3.11 etc), and between bigger versions, you test and handle any breaking changes.

I feel like this approach applies to pretty much every language?

Who on earth raw dogs on "language:latest" and just hopes for the best?

Granted I wouldn't be running Facebook's backend on something like this. But i feel that isn't a problem 95% of people need to deal with.

[rurban]

No, only to python. And partially ruby and ocaml. Not to typescript, perl or PHP.

[pepoluan]

What's so bad about Python's virtualenv? It's a good way to have an LKGC (Last Known Good Configuration). When a CVE happens, you spin up a new venv and do smoke test, canary test, blue/green deployment, and so on.

If the update breaks things, you go back to the old venv. If the update goes well, then you just delete the old venv.

Not implementing security updates the right way is just human laziness and has nothing to do with the language in use.

[skeledrew]

Introducing uv...

https://docs.astral.sh/uv/

[rurban]

uv does not fix the need for venv's or docker containers. normal people update their libs with the hope to get problems fixed.

python people don't update their libs, because then everything will break right and left. so they keep their security problems running.

[skeledrew]

No matter how you look at it, the dependencies have to go somewhere. Node uses node_modules, most compiled languages require compiled libraries (or they're a huge blob), etc. Idk about PHP but I'm pretty sure 3rd party things for any given app also live somewhere. Different ways of managing dependencies. It's recommended that venvs are used in Python because you may accidentally nuke a system script by doing global installs, and otherwise there still needs to be some sort of 3p version handling when you have multiple projects going.

Once something works in Python (which uv now makes trivial; before it could be a pain), updating 3rd party packages rarely cause breakage. But yes, I think many who use it hardly update, because things usually continue to work for years and the attack surface is pretty narrow[0]. Heck just a few days ago I checked out a project that I hadn't touched in years, which I wrote in Python 3.7; updated to 3.13 and it continued to just work. Compare to PHP which has a far higher attack surface[1] and often has breaking changes. I've heard a couple nightmare stories of a v7.x -> v8.x move being delayed because it required a serious codebase rewrite.

[0] https://www.cvedetails.com/product/18230/Python-Python.html?... [1] https://www.cvedetails.com/product/128/PHP-PHP.html?vendor_i...