Для каких задач PHP является сильным выбором, а где лучше честно выбрать другой язык?

Конкретное сравнение по осям

# Грубое сравнение RPS на Hello World (один воркер, ApacheBench)
# PHP 8.3 OPcache: ~15 000 rps
# Go net/http:     ~80 000 rps
# Node.js Fastify: ~50 000 rps
# Разрыв реален, но для DB-bound приложений нивелируется задержкой БД

Для типичного Laravel-приложения с Eloquent bottleneck — это PostgreSQL, а не PHP. Оптимизация запросов даёт больше, чем смена языка.

Где PHP — сильный выбор

PHP 8.x — зрелая платформа с предсказуемой моделью развёртывания. Его стоит выбирать в следующих сценариях:

• Web-приложения с богатой экосистемой: Laravel, Symfony, WordPress. Для CRUD-сайтов, SaaS-продуктов, CMS и интернет-магазинов экосистема закрывает 90% задач готовыми пакетами (Eloquent ORM, Symfony Messenger, WooCommerce). Скорость выхода первой версии продукта обычно выше, чем на Go или Java.
• Команды с PHP-экспертизой: найм PHP-разработчиков дешевле, чем Rust или Kotlin; порог входа для junior ниже. Если команда уже умеет писать на PHP с PHPStan level 8 и Pest, переход на другой стек — это риск, а не улучшение.
• Shared-hosting и простая операционка: PHP-FPM + nginx — стандартная конфигурация большинства хостеров; нет необходимости в оркестрации контейнеров для небольших проектов.
• Сайты с высокой нагрузкой на чтение + кэш: WordPress.com и Facebook (HHVM) исторически показали, что с правильным опкод-кэшем (OPcache) PHP справляется с миллионами запросов в день.

Где честно выбрать другой язык

• CPU-bound вычисления: обработка видео, ML-инференс, криптография — Go, Rust, C++ дадут на порядок лучшую производительность. PHP не компилируется в нативный код (JIT в 8.x помогает, но ограниченно).
• Высококонкурентные сервисы с тысячами одновременных соединений: Go goroutines или Erlang/Elixir processes масштабируются дешевле, чем PHP-FPM с N воркерами. Swoole/FrankenPHP частично решают проблему, но усложняют операционку.
• Строго типизированные системы с гарантиями компилятора: TypeScript (strict mode), Kotlin, Rust дают ошибки на этапе компиляции; PHPStan/Psalm — статические анализаторы, но не компилятор, и артефакты сборки не гарантируют корректность типов в runtime без declare(strict_types=1) в каждом файле.
• Микросервисы с gRPC и бинарными протоколами: Go и Java имеют более зрелые grpc-экосистемы; PHP gRPC работает, но инструментарий беднее.
• CLI-инструменты и системное программирование: Go компилируется в один бинарник без зависимостей, что удобнее, чем дистрибутировать PHP-скрипты.

Подводные камни

• Выбор PHP «потому что я его знаю» без анализа нагрузки и команды — это технический долг, а не техническое решение.
• PHP без PHPStan/Psalm уровня 6+ в CI — это динамически типизированный язык со всеми рисками: TypeError в production, невидимые null-dereference.
• Long-running PHP (Swoole, RoadRunner) меняет модель памяти: утечки, shared state, нужны reset-хуки — команда должна это знать до перехода.
• OPcache работает только при opcache.enable=1 и правильном opcache.revalidate_freq; неправильная конфигурация делает PHP на порядок медленнее.
• WordPress-экосистема и современный PHP (8.x, Composer, PSR-4) — разные миры; не стоит оценивать PHP по коду WordPress-плагинов 2012 года.
• Найм «любого PHP-разработчика» и найм «PHP-разработчика с опытом Symfony, event sourcing и асинхронной обработкой» — разная стоимость и разный рынок.

• Выбирать PHP по популярности, а не по требованиям проекта
• Игнорировать опыт команды, эксплуатацию и стоимость поддержки
• Не называть ситуации, где PHP будет плохим выбором

• Называет критерии выбора PHP
• Учитывает команду, эксплуатацию, стоимость и риски
• Может назвать сценарии, где выбрал бы альтернативу