I wonder what PHP would win if the codebase was rewritten entirely in Rust.
My bet? Given the Rust ecosystem, we would be months away of truly async, green threads, non blocking IO, and a complete performant web server implementation.
Cc @thephpf @php @phpfig @phpc
#PHP #Rust #Programming #WebDevelopment #WebDev #Software #SoftwareDevelopment #Web #Internet #ProgrammingLanguages #WebServer #OpenSource #OSS #FOSS #ThePHPFoundation
Gina Peter Banyard
Als Antwort auf .:\dGh/:. • • •Why would Rust give any of those?
We already have green threads (Fibers).
"truly async" means what? Non-blocking I/O? If so, C is not the problem here.
And why should PHP provide a web server? Web servers are complicated things and you can a bunch of ways to run PHP (Apache, FPM/NGNIX/FrankenPHP).
I very much dislike C, but Rust doesn't solve any of these problems.
.:\dGh/:.
Als Antwort auf Gina Peter Banyard • • •@Girgias@php@fosstodon.orgc.social @thephpf@php@fosstodon.orgc.social @php @php@fosstodon.orgfig @php@fosstodon.orgc
I believe Fibers are not green threads but basically wrappers around Generators (cooperative multitasking).
There are a lot of operations that are blocking, like reading a socket or a file.
A fully configurable web server inside PHP would be great. Imagine authorizing file access based on reading a cookie, or the database.
Gina Peter Banyard
Als Antwort auf .:\dGh/:. • • •Then you don't understand what Fibers nor green threads are.
There are already proposals to add non-blocking I/O to PHP, one being very recent.
What does "inside PHP" even mean here? PHP sits "after" the web server traditionally, and again FrankenPHP allows you to effectively write wrapper stuff for Caddy.
Back to the main point, how does Rust solve ***any*** of the aforementioned issues. Because it doesn't.
.:\dGh/:.
Als Antwort auf Gina Peter Banyard • • •Larry Garfield
Als Antwort auf .:\dGh/:. • • •For which?
Fibers are just as async as JS, but nicer as they're not colored. Itd just a matter of tooling on top, which exists, but most sites don't actually need.
The existing IO layer is sync. Building a complete second async IO and streams suite is... Not for the faint of heart. Rust wouldn't change that much.
Baked in webserver, eh, why? There's already FrankenPHP if you want. It's not critical for an interpreted language like it is for Go or Rust.
.:\dGh/:.
Als Antwort auf Larry Garfield • • •@Crell @Girgias Well, my intention of an embedded web server is to allow the application to control the web server programmatically.
My mantra is to always try to make a project without language fragmentation. Since PHP is web-focused language, I've always criticised the lang because its brick-and-mortar approach and you always require "something else" to complement.
WebSockets for example, SSE too.
Larry Garfield
Als Antwort auf .:\dGh/:. • • •@Girgias So what you're really after is first party ReactPHP, or FrankenPHP.
I'm supportive of that, but C vs Rust is the least interesting part of the puzzle.
.:\dGh/:.
Als Antwort auf Larry Garfield • • •Larry Garfield
Als Antwort auf .:\dGh/:. • • •@Girgias That... Has nothing to do with it?
Ate weer even having the same conversation? 😀
.:\dGh/:.
Als Antwort auf Larry Garfield • • •@Crell @Girgias No, i mean... err.. My point is that PHP in Rust could benefit from the "modern" language (specially memory safety), but also Cargo to accelerate development on other areas that, as far as I know, must be done "by hand" in PHP.
I don't know if PHP source has too much dependencies at its core, buy my guess is that there is a lot of legacy approaches to what modern requirements are. My biggest beef? WebSockets and SSE. In 2025.