# Executing PHP SAPI/runtime from Golang/Rust

- Thread: https://externals.io/message/118429
- Original archive: https://news-web.php.net/php.internals/118429
- Started by Paul Dragoonis on 2022-08-14T12:29:29+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #118429 — Paul Dragoonis — 2022-08-14T12:29:29+00:00

URL: https://externals.io/message/118429#118429

Hey,

So one thing that keeps me up at night (for a while now) is resisting the
urge not to venture down a rabbithole of writing code which is loading the
PHP runtime from Rust/Golang (up to MINIT)

And then at RINIT time, we load the right SAPI and pass across the SERVER
vars that's needed for it..

Here is a use case example. Golang concurrency model on the front, and it
can execute PHP CLI SAPI or HTTP SAPI on the back.

Moreover if you're looking at reasons people have previously or currently
moving away from PHP to other languages, due to limitations like pure async
or concurrency stuff .. then perhaps a new FRONTEND which can execute the
PHP runtime on the backend would be solving some things.

I appreciate this isnt a unique idea and maybe someone else from internals
has raised this before .. but I wanted to raise the topic to check the
viability of this if it is possible, and what blockers are in our way,
currently, if it's not even possible to share SAPI calls from another
language runtime.

Thanks for listening,
Paul Dragoonis.

I wrote this on my phone, so excuse typos and poor grammar :)

---

## #118430 — Thomas Nunninger — 2022-08-14T14:07:53+00:00

URL: https://externals.io/message/118429#118430 · In reply to: #118429

Hey,

Am 14.08.22 um 14:29 schrieb Paul Dragoonis:
> Hey,
> 
> So one thing that keeps me up at night (for a while now) is resisting the
> urge not to venture down a rabbithole of writing code which is loading the
> PHP runtime from Rust/Golang (up to MINIT)
> 
> And then at RINIT time, we load the right SAPI and pass across the SERVER
> vars that's needed for it..
> 
> Here is a use case example. Golang concurrency model on the front, and it
> can execute PHP CLI SAPI or HTTP SAPI on the back.
> 
> Moreover if you're looking at reasons people have previously or currently
> moving away from PHP to other languages, due to limitations like pure async
> or concurrency stuff .. then perhaps a new FRONTEND which can execute the
> PHP runtime on the backend would be solving some things.
> 
> I appreciate this isnt a unique idea and maybe someone else from internals
> has raised this before .. but I wanted to raise the topic to check the
> viability of this if it is possible, and what blockers are in our way,
> currently, if it's not even possible to share SAPI calls from another
> language runtime.

I'm not sure about the internals you mention. Are you looking for 
something like https://roadrunner.dev/

"RoadRunner is a high-performance PHP application server, load-balancer, 
and process manager written in Golang."

Best regards
Thomas

---

## #118431 — Rowan Tommins — 2022-08-14T20:05:30+00:00

URL: https://externals.io/message/118429#118431 · In reply to: #118429

> Moreover if you're looking at reasons people have previously or currently
> moving away from PHP to other languages, due to limitations like pure async
> or concurrency stuff .. then perhaps a new FRONTEND which can execute the
> PHP runtime on the backend would be solving some things.


There already are concurrent and asynchronous solutions for PHP: Swoole, 
Amp, React, etc

I think part of the reason they aren't more popular is simply that 
they're young compared to the language itself - one of PHP's big 
advantages is its thriving ecosystem of existing software, frameworks, 
and libraries. A lot of those need modifying to take advantage of a 
concurrent / asynchronous environment, or even to run safely at all, 
because they assume PHP's traditional "shared nothing" model.

By contrast, the ecosystems of node.js, Go, etc have been written with 
concurrent / asynchronous already "baked in", so are fully ready to take 
advantage of it. If you need to rewrite large chunks of your codebase to 
use an async-friendly framework anyway, it's less of a leap to switch 
language completely.

Regards,

-- 
Rowan Tommins
[IMSoP]