> What does it do better than other languages?
Shared nothing architecture. If you're using e.g. fastapi you can store some data in memory and that data will be available across requests, like so
import uvicorn, fastapi
app = fastapi.FastAPI()
counter = {"value": 0}
@app.post("/counter/increment")
async def increment_counter():
counter["value"] += 1
return {"counter": counter["value"]}
@app.post("/counter/decrement")
async def decrement_counter():
counter["value"] -= 1
return {"counter": counter["value"]}
@app.get("/counter")
async def get_counter():
return {"counter": counter["value"]}
if __name__ == "__main__":
import uvicorn
uvicorn.run(app, host="0.0.0.0", port=9237)
This is often the fastest way to solve your immediate problem, at the cost of making everything harder to reason about. PHP persists nothing between requests, so all data that needs to persist between requests must be explicitly persisted to some specific external data store.
Non-php toolchains, of course, offer the same upsides if you hold them right. PHP is harder to hold wrong in this particular way, though, and in my experience the upside of eliminating that class of bug is shockingly large compared to how rarely I naively would have expected to see it in codebases written by experienced devs.
Shared nothing architecture. If you're using e.g. fastapi you can store some data in memory and that data will be available across requests, like so
This is often the fastest way to solve your immediate problem, at the cost of making everything harder to reason about. PHP persists nothing between requests, so all data that needs to persist between requests must be explicitly persisted to some specific external data store.Non-php toolchains, of course, offer the same upsides if you hold them right. PHP is harder to hold wrong in this particular way, though, and in my experience the upside of eliminating that class of bug is shockingly large compared to how rarely I naively would have expected to see it in codebases written by experienced devs.