Автор: Ильяс Салихов (retailCRM) · PHP Russia 2019
Язык с быстрым runtime не обязательно делает разработку сервиса дешевле. Если приложению нужны сотни полей, сложная валидация, связи между сущностями и миграции, стоимость готовых прикладных абстракций может оказаться важнее производительности самого языка.
Ильяс Салихов сравнивает PHP и Go на опыте retailCRM. На момент доклада систему обслуживали около тридцати сервисов: примерно 60% были написаны на PHP с Symfony, 30% — на Go. Автор не выбирает победителя, а показывает задачи, для которых в компании использовали каждый стек.
PHP выигрывал в насыщенных бизнес-приложениях. Symfony и Doctrine давали ORM, Unit of Work, миграции, формы и валидацию. Go выбирали для небольших API и сервисов с конкурентной обработкой, где были полезны goroutines, производительность и поставка одним бинарником.
Кому смотреть: тимлидам и backend-разработчикам, которые выбирают язык для нового сервиса внутри уже работающей системы.
Из этого можно взять в работу: сравнивать не только скорость runtime, но и список инфраструктурных и прикладных механизмов, которые команде придётся реализовать или сопровождать самостоятельно.
В качестве сложного PHP-сценария автор показывает страницу заказа примерно со 160 полями и список заказов с более чем сотней доступных колонок и фильтров. В такой системе участвуют десятки связанных сущностей, а разработчикам нужны не только SQL-запросы, но и отслеживание изменений, каскадные операции, аудит и мягкое удаление.
Doctrine предоставляет для этого Data Mapper и Unit of Work. Symfony добавляет формы, вложенные коллекции и интеграцию с валидацией. В описанном проекте значительная часть миграций генерировалась автоматически.
Попытка решить те же задачи через использовавшиеся командой Go-инструменты потребовала больше ручного кода. Автор отмечает ограничения GORM, миграций и библиотек форм. Эти наблюдения относятся к конкретным версиям экосистемы 2019 года: их нельзя автоматически переносить на современные библиотеки.
Go показывал свои сильные стороны в других сервисах. Для интеграций с мессенджерами, обработки множества соединений, ботов и небольших API подходила встроенная модель конкурентности. Приложение компилировалось вместе с веб-сервером и поставлялось самостоятельным бинарником.
Вывод доклада не в том, что PHP лучше Go для бизнес-логики. Он в том, что переход на другой язык может лишить команду зрелых абстракций, стоимость которых раньше оставалась незаметной. Если новый сервис по форме повторяет большое Symfony-приложение, переписывание ORM, форм и валидации способно обойтись дороже предполагаемого выигрыша.