> Почему вы сменили PHP на Go, что было мотиватором (Go)

Короткий ответ

Основной мотиватор - производительность и конкурентность. PHP хорошо подходит для веба, но при росте нагрузки и необходимости параллельной обработки (websocket, очереди, highload) упирается в архитектурные ограничения. Go даёт лёгкие горутины, нативный конкурентный код и низкое потребление памяти. Плюс - единый бинарник и простота деплоя. Это снижает стоимость инфраструктуры и упрощает эксплуатацию.

Подробное объяснение

Переход с PHP на Go обычно вызван не "ненавистью к PHP", а конкретными задачами, которые на PHP решаются неэффективно. Основные мотиваторы:

• Нагрузка и параллелизм: PHP - синхронный, один запрос = один процесс. Для I/O-bound задач (внешние API, БД, очереди) приходится использовать очереди или воркеры, что усложняет архитектуру. Go с горутинами позволяет обрабатывать тысячи конкурентных операций в одном процессе.
• Потребление памяти: PHP-FPM держит пул процессов, каждый съедает 30-50 МБ. Go-приложение - один процесс с общей памятью, обычно 50-100 МБ на всё приложение. При 1000 RPS разница в стоимости серверов существенная.
• Типизация и надёжность: PHP - динамическая типизация, ошибки всплывают в рантайме. Go компилируется, типы проверяются на этапе сборки. Для микросервисов и долгоживущих сервисов это критично.
• Деплой и эксплуатация: PHP требует интерпретатора, настройки FPM, opcache, веб-сервера. Go - один статический бинарник, который можно запустить в контейнере без дополнительных зависимостей.
• Инструментарий: встроенный профилировщик (pprof), трейсинг, удобная работа с контекстами и таймаутами. В PHP для этого нужны сторонние инструменты.

Важно понимать: PHP не "плохой", он отлично подходит для CMS и быстрого прототипирования. Но для backend-сервисов с высокими требованиями к latency и throughput Go - более предсказуемый выбор.

На практике

В реальном проекте переход обычно выглядит так:

• Оставляем PHP для legacy-монолита или админки.
• Новые сервисы (API, обработчики событий, websocket-серверы) пишем на Go.
• Общаемся через REST или gRPC, общую шину (Kafka, RabbitMQ).
• Постепенно выносим тяжёлые сценарии из PHP в Go-сервисы.

Мотивация на собеседовании должна звучать как инженерное решение, а не "PHP - отстой". Интервьюер ждёт, что вы объясните trade-off: где PHP остаётся оправданным, а где Go даёт измеримый выигрыш.

Пример кода

Показать разницу в конкурентности:

GO
// Go: обрабатываем 1000 URL параллельно
func fetchAll(urls []string) []string {
    results := make([]string, len(urls))
    var wg sync.WaitGroup
    for i, u := range urls {
        wg.Add(1)
        go func(i int, u string) {
            defer wg.Done()
            resp, err := http.Get(u)
            if err != nil {
                results[i] = err.Error()
                return
            }
            defer resp.Body.Close()
            body, _ := io.ReadAll(resp.Body)
            results[i] = string(body)
        }(i, u)
    }
    wg.Wait()
    return results
}

В PHP аналог потребовал бы curl_multi или очередь воркеров, что менее читаемо и сложнее в отладке.

Как отвечать на собеседовании

• Начните с конкретной проблемы: "У нас был сервис, который обрабатывал 5000 запросов в минуту, PHP-FPM упирался в память".
• Приведите цифры: "Переписали на Go - потребление памяти упало в 5 раз, latency в 3 раза".
• Упомяните, что PHP остался для админки, а Go - для API и воркеров.
• Покажите, что вы понимаете ограничения Go: нет generics (на момент перехода), более строгая обработка ошибок, отсутствие готовых CMS-решений.
• Не критикуйте PHP в лоб - скажите, что это вопрос инструмента под задачу.

Что проверяет интервьюер

• Понимаете ли вы, когда язык действительно нужен, а когда это мода.
• Умеете ли вы оценивать trade-off: скорость разработки на PHP против производительности на Go.
• Видите ли вы архитектурные ограничения своего стека.
• Можете ли вы объяснить мотивацию команде и руководству - не только технически, но и экономически.

Типичные ошибки

• "PHP - устаревший язык" - это неправда, PHP 8 активно развивается.
• "Go быстрее во всём" - нет, для простых CRUD на PHP разработка быстрее.
• Не упоминаете, что переписывание всего сразу - плохая стратегия, нужен постепенный переход.
• Не приводите конкретных метрик - без цифр ответ звучит как абстрактное "Go лучше".
• Путаете конкурентность и параллелизм: горутины не всегда ускоряют CPU-bound задачи.