Combining Golang and PHP can solve real-world development challenges (blog.spiralscout.com)

What was the alternative to using php from 1996 to 2000 if you were running a small mom and pop isp and your customer base was requesting shopping carts, photo galleries, and blog like web capabilities?

In that era, the servers were pentiums of 75MHz.

That's just not true. Just one example: PHP will throw runtime errors when (1) an argument type being passed to a function does not match its corresponding declared parameter type and (2) a value being returned from a function does not match the declared function return type. In pure Javascript you can't restrict the types of objects being passed to or returned from a function.

For people new to development especially who may have started with some simple static HTML, just being able to rename a .html file to .php on a dirt cheap web host and have it "just work" is such a low barrier to entry that it is a tremendous learning tool.

People also like to forget that PHP scales down better than any language out there, making it a no-brainer decision for cheap hosting of small and simple sites.

When you start increasing traffic and throughput or building software to run an serious business, of course there are other great options.

Just remember that every language has a purpose even if it's not yours, otherwise it wouldn't exist.

1) Rapid iteration: Edit a file, hit refresh, see your results.

2) Ease of deployment: SFTP your changes, done (obviously you wouldn't work this way for a serious project...)

3) Simple execution model: each request gets its own thread (or process), each request starts from scratch.

PHP 7's type system is worse than Javascript's type system? I can't imagine any developer who has worked with both those languages agreeing with you. It sounds like you haven't done any serious PHP work for the last ten years or so, and your opinions haven't kept pace with reality.

    try{
      $exceptionType = rand(1,10) > 5?     
        BadMethodCallException::class
        : LogicException::class;
      throw new $exceptionType("smartass");
    }
    catch(BadMethodCallException $typed_1){
      file_put_contents('php://stderr', "Bad method, ".$typed_1->getMessage());
    }
    catch(LogicException $typed_2){
      file_put_contents('php://stderr', "Bad logic, ".$typed_2->getMessage());
    }

    function lieToMe(PHPMailer\PHPMailer\PHPMailer $mailer){
      
    }

    $mailStrategy = new MailStrategy();
    $mailStrategy("email@example.com","Subject","Body");

It's sad to see people who probably can't program a microwave diss an entire language they haven't ever actually used.

For webapps in particular there can be a lot of value in constantly reloading the page. For example it can allow you to more often visually inspect the page for ui/ux/performance improvements. Particularly in early stages of a user interface where you're still figuring things out.

Yes, absolutely. This is my principal and nearly-exclusive method of debugging the distributed systems I work on all day.

I have largely stopped coding in PHP, but I did use xdebug when necessary. I have very little idea of other developers' workflows, but I am very skeptical of this claim.

I'd say 90%-95% of the time that's entirely sufficient.

"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." - Brian Wilson Kernighan

IMO the ability to easily diagnose and debug issues is a feature of the code/application and should be taken into account when writing it. Having to fall back on a debugger means your dealing with something not written with maintenance in mind.

Time difference between printf() & F5 vs. setting up breakpoints and watch variables in a debugger is going to be negligible in something like Ruby/Python/PHP.

Also, everything is so damn framework-heavy these days that stepping until you strike gold can take a very long time. Super-verbose logging would probably be more effective.

RoadRunner lets you run "workers" (php processes) that perform all the bootstrapping just once, and then receive-process-reply to requests. The use case is to avoid the (possibly expensive, especially with modern frameworks) bootstrapping for every request.

Check the symfony integration example for instance [1]. Everything that's outside of the

  while ($req = $psr7->acceptRequest()) {
  ...
  }

The problem with this approach is that you now need to be careful not to leave unwanted stuff behind (open files / db connections, static $properties, etc.) that may interfere with future requests, whereas this just isn't possible in "normal" PHP. I would argue that this is one of the features that makes PHP so beginner-friendly.

[1] https://github.com/spiral/roadrunner/wiki/Symfony-Framework

This is awesome ergonomically (because a past request cannot affect a future one in any way), but has terrible performance because all of the PHP code has to be re-bootstrapped for every request (think: read config files, open db connection, setup the injection-container, etc.).

Thus, this thing is like php-fpm but letting you bootstrap once and then just reply to requests within that php-space.

Aside from the "now you have an extra gun to shoot your foot with" issue, the other major difference is that php-fpm can execute any php file, whereas this approach requires a different process for each entry point (aka "front controller" in modern frameworks, aka "index.php").