Back

@darkghosthunter @thephpf @php @phpfig @phpc 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.

@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.

@darkghosthunter @php 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.

@Girgias @php well, C haven’t. If it’s not the language nor ecosystem of the language, then what is it? Lack of contributors?

@darkghosthunter @Girgias @php 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.

@Crell @Girgias @php 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.

@Crell @Girgias @php Because of the ecosystem itself? Cargo is great from what I've heard. What does C uses as distributed packaging system?

@darkghosthunter @Girgias @php That... Has nothing to do with it?

Ate weer even having the same conversation? :-)

@Crell @Girgias @php 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.

@darkghosthunter @Crell @php You are aware that most of PHP are extensions, right? Extension that bind to ***C*** library (see ext/curl, ext/dom, ext/openssl, ext/pcre). Bundling a C library, or linking to it, is ***not*** the problem.

PHP (or any PL) is not some whack app that needs to be "accelerated". The complexity in adding new features ***never*** comes from a lack of libraries to pull in.

@darkghosthunter @Crell @php Features cannot be added and removed willy nilly, features are designed, talked through, go through discussions, redrafted, etc.
Hooks took 2y (and even then are still a contentious feature) not because of lack of "raw code", but because of the design space.

The project is conservative for *good* reasons, you don't exist for 30y without saying no and putting your foot down on any random proposal and feature.

@darkghosthunter @Crell @php Would PHP (the language) benefit from a Rust implementation, absolutely, even just as an experiment to learn new stuff and new approaches. But the VM is such a small part of the language in the grand scheme of things. Extensions is what powers PHP.

There exists a JVM and .Net VM, but who uses them? Most don't because you don't have access to any of the C extension that provide 90% of the features.