Фича Python Golang
Функциональный сахар, типа map, filter + -
Возможность написать 2 утилиты, которые могут лежать и запускаться в 1 папке + -
REPL + -
Легко закомментировать половину кода для отладки (в Go будут ошибки imported and not used. Go-plus в Atom удаляет неиспользуемые импорты при сохранении. Добавляешь принты дебаговые, с помощью fmt, комментишь, сохраняешь, import fmt удаляется, раскомментируешь - ошибки) + -
Компилируемость даёт большой выигрыш в производительности - -
Возможность x, y = func(), которая возвращает список из двух строк + -
Необходимость писать свой urllib при шаге влево/вправо - +
Строгий urllib падает с ошибками разбора URL вида http://example.com/x/% - +
Богатая библиотека для работы со строками (в Go нет find() с offset, isUpper(), isLower()) + -
Min() и Max() работают для любых числовых типов + -
Деплой 1 бинариком - +
Навязывание layout мотивирует не делить код на модули - +
Удаление элемента из slice по индексу логично (в Python - del, в Go - создание нового списка через сложение подслайсов сбоку и справа от элемента) + -
Поддержка дефолтных значений в getenv() + -
Возможность использовать пустую строку в условии как false (в Go надо считать их длину) + -
Бенчмарки хороши + +
Парсер YAML требует строгой типизации файла. Не поймёшь в какую структуру его парсить, пока не распарсишь. Успех парсинга зависит от именования поля структуры, причём не 1 в 1. То, что в YAML зовётся “consumer” в коде Go должно называться Consumer - +

Примечания

Самый умный совет по оптимизации:

@strangeqargo: все равно надо на код смотреть, может у тебя контейнеры неоптимальные в питоне

Забавно, но код

s = “string”
s[len(s)-1] == “g”

быстрее в 8 раз, чем

s = “string”
strings.HasSuffix(s, “g”)

Удивил порядок разницы, я думал будет что-то около 1.5-3 раз.

А 1 python-функция на 23 строчки превратилась в 4 Go-функции на 130 строк.