I've worked with PHP before and while Rust seems an odd choice, if the libraries are robust then having compiled code will be a lot faster then using an interpreter all the time. Would likely make updates a bit more inconvenient but the end result should be worth it.
I dislike these un-quantified sort of statements. I asked what version of PHP you worked with and I'm also curious the depth of your experience because you're making very sweeping assessments there. The likely slowest link in the chain for most web-forums would be the database and the connection thereof. With cached server-side pages (the model Null is looking at) response time for a request is going to be very fast with PHP and the real question would be simultaneous request handling which frankly is going to be as much or more on the web server (nginx, apache, lighttpd, tomcat - ha ha, just kidding about that last one) and the number of connections it can handle. Pre-interpreted PHP is fast. Especially with all the optimisations that have been coming in since 7.4 onwards.
With PHP you have a long-standing set of tools and support exactly for serving websites. Setting up a PHP backend for nginx, apache, whatever is a standard thing well-documented. You have packages available in PHP for pretty much everything you might want web-related or DB-related with mature version management solutions and security reviews. Meanwhile, I don't see many advantages that Rust has over PHP 8.0 beyond your unquantified "will be a lot faster than using an interpreter all the time". In fact just that statement puts the lie to your understanding of PHP because the PHP code will be interpreted once when updated, or at least infrequently depending on caching configuration, and thereafter just runs from the opcache very quickly. Rust
is faster, but in a webserver? Does that make any relevant difference to serving requests to the user? I very much doubt it. If you want to do some oddly computationally intensive stuff with direct memory access for some reason to do with your webserver, such as, I don't know, some odd computation of page sizes or reaction tallying, you
could just code that in C/C++/Rust and call that from PHP if needed and have the best of both worlds. Though I doubt you'd need to unless you're doing some atypically large and complex operation on your data.
I'm going to be brutally frank, I think your statement is un-quantified hand-waving and that your "I've worked with PHP before" is some light dabbling at best. You say "if the libraries are robust" ("if" They're going to be less mature and less focused on the web-domain than PHP), "will be a lot faster" (really? Than cached PHP? In what scenarios and how relevant is this to a scenario where you're overwhelmingly bottlenecked by DB and webserver networking and often just serving cached pages anyway?) and worst: "the end result should be worth it". On what basis do you take the added complexity of developing in Rust, the less mature libraries and ecosystem, working with a lower level language, put it all in a one-man-does-everything scenario and weigh all that against unquantified and unproven speed advantages in this context and say "should be worth it"? You don't know that it "should be worth it" at all.
