Зачем делали миграцию с Python на Go
Что проверяют
Умеете ли вы обосновывать технические решения цифрами и понимаете ли цену переписывания. Ответ «Go быстрее» слабый, ждут разбор.
Как отвечать
Начните с проблемы, а не с языка. Обычные причины такой миграции:
- стоимость железа при высокой нагрузке: на одинаковом трафике сервис на Go требует заметно меньше памяти и процессорного времени, и на десятках машин это превращается в деньги;
- конкурентность: тысячи одновременных соединений в Python требуют асинхронного стека и дисциплины, чтобы ни один вызов не заблокировал цикл событий. В Go модель проще: горутина на задачу;
- предсказуемые задержки: сборщик мусора Go даёт короткие паузы, что важно для сервисов с жёсткими требованиями к времени ответа;
- эксплуатация: один статический бинарник вместо интерпретатора с зависимостями и виртуальным окружением, простые образы контейнеров;
- типизация на этапе компиляции, что снижает класс ошибок, ловившихся раньше только тестами.
Обязательно назовите обратную сторону, иначе ответ выглядит однобоким: переписывание это месяцы работы без новых возможностей для пользователя; экосистема анализа данных и машинного обучения в Go несопоставима с Python; кода на Go больше из-за явной обработки ошибок; команду нужно переучивать.
И главное, как делают правильно: не переписывают всё разом, а выносят по одному горячему сервису, оставляя остальное на Python, и сравнивают метрики до и после. Если выигрыш не подтвердился измерением, миграцию останавливают.
Где спотыкаются
Обосновывают выбор языка вкусом, а не измерением.
Переписывают систему целиком и надолго замораживают развитие продукта.
Переносят на Go то, что упиралось не в язык, а в неоптимальные запросы к базе.