Moving from Go to PHP Again

> Perhaps because they don't want to incur technical debt to a language/runtime that could change at the whim of one company that probably doesn't have other companies' best interests in mind?

How is Go any different?

To keep it simple, it was originally created as sort of a helper instead of a full-fledged language, and just kind of grew into that. As such, its early years were plagued with architecture, security and performance issues, as well as many "gotchas" that could wreak havoc on amateur programmers that tended to gravitate to the language. Couple that with the fact that the maintainers drug their feet in implementing modern paradigms found in other languages and fixing the latter issues in the name of backwards compatibility, and that at the time most PHP knowledge bases were years out of date, and it was a recipe for a poor ecosystem all around.

PHP 7.0 took a huge step forward by straight up removing old extensions that weren't maintained, focused a lot on performance and allowing more strict standards, and tons of new improvements. In addition, more modern frameworks like Symfony and Laravel started to pop up, which helped reduce the stigma of it just being a "scripting" language and made it very pleasant to work with.

I maintain a PHP app that was originally written in PHP 4, and one that was created in PHP 7 and the difference is night and day. I maintain a few Ruby and Python apps as well, but even having used these more often PHP still tends to be my go to for prototyping.

This article explain it well: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

For years it was a very permissive language that allowed you to do a lot very quickly but then with a lot of overhead to make sure things were correct.

E.g., I've seen a payment management suite that was written using php traits, which then had a super class that everything descended from, meaning every service could do everything, completely breaking OOP. For example, a DirectDebitService has methods like processMandate(), processDd(), but then because of the traits it also has access to processCreditCardPayment(). As you can imagine this made unit testing literally anything require lines of set up code and just made things impossible to work with.

With the introduction of classes, and PHP 7's scalar type declarations as actual keywords rather than just PHP docs, as well as the option for strict comparison, plus the ridiculous speed improvement between 5.6 and 7.0.

Further, tools like composer (which I think was actually one of the first modern package managers (with lock files, version selectors), Behat for integration tests, plus the huge steps frameworks have made in removing in overhead have made PHP actually a very nice language to write these days.

Deployment in a micro service context is still annoying as PHP's built in web server is not great, requiring you to have an Ngninx pointing at a PHP-FPM which actually serves each of your microservices.

You may think you can get away with one Ngninx, but then as soon as micro services start requiring things like scaling it's a pain in the arse. E.g. you may wish to do rate limiting or rbac or something for a specific service, requiring an nginx->PHP-FPM in front of each PHP service.

I'm sure there are cleverer ways to get around this but this is the way I always go and the way I've seen other PHP deva go

I inherited a Symfony2 app and it was a bitch to deploy. It definitely had an asset pipeline.

  php app/console cache:clear --env=prod --no-debug
  php app/console assetic:dump
  php app/console cache:warmup --env=prod --no-debug
  chown -R apache:apache . # fix owner
  chmod -R u=rwx,g=rwx,o=rx app/cache  # fix cache perms
  apachectl restart # bounce Apache, otherwise it can throw segfaults