Comments 131
При этом некоторые компании отключают GIL на уровне интерпретатора. Например, Wargaming пишет свою систему оплаты в World of Tanks на Python, и он отключил GIL в угоду производительности.
Сходил по ссылке, там говорится, что они Garbage collector отключают, а не gil. Gil можно отключить в расширениях на си, только придется писать на си)
new_data_struct = [[(k,v) for k,v in d.items() if k not in ['b','u']] for d in init_data_struct]Можно использовать форматирование:
new_data_struct = [
[
(k, v)
for k,v in d.items()
if k not in ['b','u']
]
for d in init_data_struct
]
Спасибо
# нам нужно объединить два словаря внутри списка, выкинув оттуда ключи 'b','u'
[[('a', 10)], [('p', 10)]]
Так задача не выполнена. Получилось не объединение словарей внутри списка, а список списков кортежей
Те, кто пишут код на Python, давно просят разработчиков языка убрать GIL
Вы драматизируете, с этим вполне можно жить не слишком страдая.
Вы драматизируете, с этим вполне можно жить не слишком страдая.
Но зачем жить и страдать. Тоже как автор перекатился на Go.
Тогда поподробнее, в чем заключались ваши страдания?
GIL
Настройка venv для каждого проекта
Отсутствие типизации
Ещё конкретнее) GIL вам мешал в ситуации, когда... Я не издеваюсь, просто пишу конкурентные программы, и мне не мешает, вдруг я что-то не так делаю.
Создание venv — одноразовый процесс, который легко автоматизируется с помощью того же Poetry.
Про GIL было бы интересно послушать, как именно он мешал. Какие-то экзотические задачи были?
Отсутствие статической проверки типов — тут соглашусь, в больших проектах не хватает. Mypy, увы не очень удобен.
Мне нужно скачать 100k файлов с разных ресурсов и записвать в файлы. Может я что-то делаю не так, но работает это не очень быстро.
Это как раз типичная I/O-bound задача. Почему Вы думаете, что тормозит из-за GIL? Тут он как раз не очень мешает.
Посмотрите презентацию с EuroPython 2019. Там миллиард файлов скачивали примерно за 8 часов (синхронный код работал 48 дней). Использовали комбинированный подход: asyncio + потоки + процессы.
Съедается выгода от асинхронщины. Потому что весь флоу исполняется в один поток. Я не старался драматизировать, но многие говорят об этом. При этом, прекрасно понимаю, что не каждому сервису это нужно. Как я уже сказал в статье, Python решает свои задачи, и делает это хорошо.
Асинхронщина и многопоточность — вещи ортогональные. Она и без GIL однопоточная, если сами поток не запустите.
GIL мешает только если вы параллельно делаете вычисления на чистом Python (что бывает очень редко), то есть у вас CPU-bound задача. А большинство задач на чистом Python I/O-bound, и тут GIL не мешает вовсе.
К тому же в расширениях GIL можно отпускать, что и делают всякие числодробильные библиотеки (например, Numpy) — они многопоточные внутри. Можно в Cython легко отпускать его, если не хочется связываться с другими языками.
Разработчики давно говорят, что убрали бы GIL, если кто-то предложит реализацию, которая не замедлит однопоточные скрипты. Пока что такой реализации не видно. Даже в недавно попытке выпиливания GIL прирост скорости от оптимизаций, а не от убирания GIL.
Ну и наконец, есть реализации Python без GIL. Это особенность интерпретатора, а не языка.
Позвольте порассуждаю, если не прав, поправьте. Реально, хочу разобраться.
Работа какого-нибудь апи метода - это не на 100% i/o-bound задача. Там всегда есть cpu-bound составляющая. Парсинг запроса и json'а, формирование запроса в бд, манипуляция с полученными данными, какая-то дополнительная логика, формирование ответа и так далее. Это всё cpu-bound. Значит, что при каких-то понятных нагрузках, в сервисе всегда будут cpu-bound задачи, то есть вся система перейдёт в работу в один поток.
Запрос в БД — это I/O bound задача и она на порядок или два дольше, чем всё остальное.
Парсинг JSON — это код, вызывающий библиотеку, написанную на C или C++, и она, скорее всего, отпускает GIL, так что может работать в фоне.
Манипуляция с данными и формирование ответа — это маленький кусочек времени.
Да, на Go код будет работать быстрее, спорить смысла нет, но это больше заслуга того, что Go — компилируемый язык.
Ну и никто не отменял запуск отдельных процессов-воркеров. На процессы GIL никак не влияет.
Я не говорю, что GIL полезен. Нет, если бы можно было без него, то конечно было бы лучше. К сожалению, он появился не просто так и от него не так просто избавиться.
Я лишь хочу сказать, что GIL часто называют среди главных недостатков Python (точнее CPython). У языка много недостатков, но GIL далеко не главный, и Python медленный в типовых задачах вовсе не из-за него.
Парсинг JSON — это код, вызывающий библиотеку, написанную на C или C++, и она, скорее всего, отпускает GIL, так что может работать в фоне.
Парсинг json'a в недавнем проекте съедал 40% всего времени работы в профайлере
Я не говорил, что это быстро, я лишь утверждал, что это делается внутри библиотеки, которая теоретически может отпускать GIL. Впрочем, я подумал, там, скорее всего GIL всё же будет, так как внутри строится дерево питоновских объектов.
40 % выглядит как довольно большая доля. Не пользуетесь базой или у вас JSON такие большие?
В любом случае решение нужно принимать исходя из проекта. Если у вас нагрузка — запрос в минуту и 40 % — это процент от 10 мс, которые устраивают пользователя, то всё прекрасно.
Если вы не можете использовать процессы по каким-то причинам и нужны именно потоки, и упирается всё именно в то, что декодирование JSON не отпускает GIL, тогда Python не для вас.
Я вовсе не пропагандирую Python сейчас.
В любом случае решение нужно принимать исходя из проекта. Если у вас нагрузка — запрос в минуту и 40 % — это процент от 10 мс, которые устраивают пользователя, то всё прекрасно.
Я просто перекладываю json'ы из кафки в базу. И чем больше база, тем дольше перекладывать. Занимало в среднем 24-32 часов для базы ~500гиг. Переписали на го и теперь 12-14 часов. Json'ы сложные, многоуровневые документы
Тут часто время зависит от того, какую библиотеку вы для этого использовали. Стандартная медленная, попробуйте https://github.com/ijl/orjson.
Стандартный парсер? Есть быстрые парсеры типа simdjson.
Спасибо большое, что объяснили, очень ценная инфа
Значит, что при каких-то понятных нагрузках, в сервисе всегда будут cpu-bound задачи, то есть вся система перейдёт в работу в один поток.
Что-то не то вы написали, программа работает в стольки потоках, сколько вы ей укажете.
Давайте, лучше я вам коротко объясню про Gil. Когда вы пишете программу, то она может утилизировать(нагружать) только одно ядро процессора, остальные будут простаивать. Если вам надо утилизировать все ядра и у вас какой-нибудь Go вы запускаете вашу функцию в 50 потоков(аналог Thread в питоне) и утилизируете все ядра. В питоне 50 потоков будут продолжать работать только с одним ядром. Всё. В этом только проблема gil. Но загрузить в питоне все ядра можно с помощью multiprocessing, просто он менее гибкий и чуть более ресурсоемкий, если коротко. Именно так работают gunicorn и uwsgi с помощью, которых вы сервите ваши flask, Django или fastapi. Так что утилизировать все ядра можно на питоне, а какой-то rocket science на чистом python считать все равно не получится хоть с gil, хоть без. Поэтому без gil-а жизнь может и была бы чуть лучше, но все и так работает.
Лучше скажи автор честно — насмотрелся инфоцыган и повелся на хайп.
12 лет golang... Какой тут хайп? Вы о чём?
Иду прямо сейчас на hh.ru, выбираю Москва. Ищу только Junior вакансии:
"python junior": 264 вакансии;
"java junior": 192;
"php junior": 93;
"php junior": 93.
Ну и я сам нашёл работу джуном без проблем. Кажется, ваш поинт невалиден )
Product/Data Analyst (Junior)
Junior Data Scientist
Разработчик ботов (Python & JS)
Junior ML Engineer
Инженер поддержки (Junior)
Младший специалист по верификации RTL (Junior)
Стажёр-инженер АСУ / Automation junior engineer
И прочие непрофильные сферы, которые показываются по этому запросу? Или инфоцыгане научили, что на Питон вакансий куча, а то что, ты со знанием Django не сможешь пойти в условный ML или QA-Automation (так как это другая сфера и нужен другой стек знанаий) как-то забыли объяснить? Или вот Junior Devops тоже проходит как python junior?
Есть ли в Go, какой-нибудь условно типовой стек наподобие Питоновского: Flask + SQL-Alchemy + Alembic? Было бы интересно узнать, насколько сложно было перейти с Python на Go в бэкенде, заменив один стек на другой, оставив при этом применяемые и тут и там: Docker, Postgersql и Postman?
Scratch, ptorobuf
Я не юзаю пока как таковые веб фреймворки. Мне роутера Gorilla/Mux за глаза.
С докером вообще круто - юзаешь самый минимальный контейнер после билда.
Я даже на Golang реализовывал немного машинного обучения (распознание лиц)
В Go нет ORM. Точнее есть, но сообщество пришло к тому, что это не Go way.
По поводу фреймворка, они есть, но Golang используют в основном в крупных корпорациях, и там юзают свою обвязку на Golang.
Так что в Go фреймворк вторичен, нужно учить сам язык и синтаксис. Также советую посмотреть вот этот видосик, он прольёт больше света по проблеме, которую вы озвучили: https://youtu.be/XR9NiwuiK-k
В гугле "awesome go". Думаю все там есть. По крайней мере я не видел, чтобы отсутствовал какой-то инструмент под го.
Сам по себе переход на другой язык программирование — это сама по себе хорошая идея. Надо меняться.
А я недавно себе книжек по пайтону накупил.
Пойду теперь по Go покупать. :) Мне понравилось, что там код более понятный.
Сам перешел и не жалею! Это по моему мнению самый логичный язык программирования из всех, что я только учил (помимо Python JS,C#, Dart, Visual Basic, Delphi, Lua)
Интересно, что народ думает про Юлю? (Она же Julia.) Её разработчики утверждают, что она проста как Питон и при этом быстра как С, но у меня что-то нет особого впечатления, что ей кто-то пользуется. Почему?
Чтобы переползти на новый язык, нужна мотивация и немного любопытства. Юлия столь же молода, что и GoLang. При этом её изначально позиционировали как вычислительный язык. Ну, типа, фортран сегодня. Вернее, Матлаб, но быстрый. Вот название русскоязычного руководства: "Язык программирования математических вычислений JULIA". Это сильно сбивает, на самом деле. Язык современный, действительно очень простой, но при этом подключает питоновские библиотеки, например. И фортрановские. И сишные. Параллельный не хуже Go. Но вот кому он нужен и где используется - вопрос. Мне хорошо - я одиночка, программирую физические задачки, сделал пару проектов на Юлии просто из чистого любопытства. Поставил галочку - и вернулся обратно. Не думаю, что у этого чудесного языка есть какие-то широкие перспективы, кроме его узкой ниши. Ну, отрежет он что-то у R. Что-то у Питона (биг дату немножко). У Матлаба, безусловно (если он кому-то нужен). Это не тот размах, имхо.
Julia это достойная (и бесплатная) замена таким системам, как Matlab или R. Последнее время в неё вливаются колоссальные деньги https://juliacomputing.com/media/2021/07/series-a/. Но это не язык общего назначения, у неё очень тяжеловесная среда, примерно как Anaconda.
Идея у языка интересная (хоть и есть странности в дизайне), но нет экосистемы, а без неё никто на Julia переходить не будет.
Вот что-то никогда го меня не возбуждал (хотя может я просто не понял чего, не углублялся):
Exceptions убрали, но ничего взамен для error propagation не предложили, возвращай кол ошибки как в сяз, зотя именно из-за этого эксепшены и появились. Как понимаю в расте слелали нормально.
Компилятор не ловит null-pointer exception, можно получить его в проде, расты/хаскелы ловят на сталии компиляции.
Нет дженериков, надо или копипастить код или кодогенерацией заниматься, не аккуратно как-то. Везде считай есть
Нет механизма чистки языка от легаси, помню был какой-то косяк со строками, который видимо никогда не пофиксят из-за обратной совместимости. В расте вроде решили.
В расте все хорошо. Только попробуй найти работу на нем :)
А дженерики через пару месяцев завезут, но их отсутствие не проблема
Да, работы нет.
Ну поглядим, давно говорят, если дженерики заведут, то по идее и null-pointer проблему можно пофиксить, но опять же на практике обратная совместимость не позволит.
обратная совместимость не позволит.
Для этого есть абстрактный Go2)
Не понял, а как дженерики связаны с NPE?
NPE - это же завезти "засахаренную ad-hoc монаду Maybe" + поломать обратную совместимость (в Java / С# вон уже сколько лет пытаются - не выходит аленький цветочке).
Компилятор не ловит null-pointer exception, можно получить его в проде, расты/хаскелы ловят на сталии компиляции.
Существует линтер: https://staticcheck.io/docs/checks#SA5011
Это хорошо, но это костыль, придётся всё обложить проверками, хотя в идеали они нужны только там где пустое значение может быть использовано.
Линтеры приучают писать корректный и правильный код.
Код надо покрывать тестами.
И уже научившись писать правильно у тебя не будет проблем с nil-pointer.
Гыгы, слышал похожие рассуждения про перл. Зачем тогда изобретают новые языки? Так можно сказать, что и на си можно писать правильный код.
Насколько знаю го появился как раз потому что умные и талантливые гуглеры (знающие почему люки круглые и решающие весь letitcode за вечер) не осиливали писать правильный код.
В 18 версии дженерики. Я либу пишу, чтоб перенести Option, Result, Either в Go. Конечно enum типа нет и размер структуры будет из за этого больше, но проблема с nil pointer будет решена, как в скале. Если все просто начнут использовать option и явно его обрабатывать
Да, по началу самого бесили эти постоянные if err != nil, но сейчас привык, и мне нравится. Перехват ошибки может осуществляться где-то в непонятном месте, что увеличивает когнитивную сложность системы, а тут ты ошибки протягиваешь через цепочку исполнения и явно видишь их.
Проблема, согласен.
Дженерики завозят скоро.
Всё-таки, к этому можно по-разному относится. Для кого-то это преимущество, и возможность без проблем обновлять систему на новую версию языка.
Так понятно что исключения это разновидность go to, но не руками же пробрасывать коды ошибок по всему стэку, в расте вроде макрос для этого есть.
Ну в реальном мире сходу идеально никто не умеет делать, надо развивать и фиксить, обратная совместимость тормозит и даже блокирует развитие, для беспробоемного обновления нужны другие механизмы, вроде фиксации версии языка, могу наврать, но вроде в расте так сделали.
сейчас привык, и мне нравится
Стокгольмский синдром. :)
"На самом деле, после питона на голанг пишешь и страдаешь" - все очень индивидуально, у меня как раз ровно обратное впечатление :)
Поддерживаю. Языки программирвоания это по сути инструменты со своей экосистемой, и все наилучше подходят для разных задач. Нет универсальных языков.
Спасибо за статью 👍
Dropbox, изначально написанный на Python, переписали часть бэка именно на Golang.
А я помню эту историю, когда пошел хайп, переписывать все на Go, хипстеры из Dropbox тутже кинулись перписывать все с python на golang, конференции, статьи, много шума, закончилось тем, что часть они таки перписали, но вот производительность была не на много выше чем у python, а тут rust пошел на хайп и что? правильно - перпишем все на rust. И в результате, пока google drive, onedrive? да тот же yandex пилили новые фичи, команда dropbox занималась перписыванием старых, кончилось все закономерно, а ведь когда то dropbox был №1 в мире облачных хранилищ.
Чтобы чип не искрился при виде [[(k,v) for k,v in d.items() if k not in ['b','u']] for d in init_data_struct] нужно было учить Хаскель. Кстати, на нём даже веб-сервисы можно программировать (наверное).
Можно, я пробовал WAI/Warp. Проблема в том, что хаскель -- это такой C++ от мира функциональщины, и я в один момент начал болеть и перестал справляться с его сложностью. А ещё Servant -- фреймворк не для начинающих, проверено на личном опыте.
В тему с пояснениями, почему хаскель рано или поздно должен сдохнуть, кастуется @0xd34df00d
Не согласен. Благодаря простоте Go, его код легко читаем. Из-за знакомых конструкций глаз сразу цепляется за нужные места и в целом чтение кода похоже на чтение книги.
Тогда как в языках с сахаром часто приходится ломать голову. Особенно если ты только познакомился с каким-то языком на базовом уровне и начинаешь разбираться в коде какого-то проекта или библиотеки. И такие конструкции часто сложно как-то загуглить.
В итоге тратится больше времени разработчика и в целом увеличивается сложность кода, что чревато ошибками и трудно выявляемыми багами, которые скрыты за магией сахара.
Go — достаточно молодой язык. Ему всего 12 лет, и он сразу делался с
оглядкой на то, что код будет выполняться на нескольких ядрах
процессора. И в этом его невероятная сила.
Тут я с вами немножко поспорю. Go это результат опыта полученного от работ над такими языками как Alef и Limbo, а так же платформой plan9. В первых версиях Go был полностью основан на plan9. А это внимание: 1989 год!
Настоятельно рекомендую посмотреть доклад Филиппа Кулина: https://www.youtube.com/watch?v=ql-uncsqoAU
Так что истоки у Go очень древние. Это кстати объясняет подход к работе с ошибками, так как тогда ещё подход с exceptions был не столь популярным среди языков.
медианная зарплата Go-разработчиков выше, чем у разработчиков на Python
Есть предположение, что в этом виноват финтех.
Что странно, в го работать с финансовыми данными не удобно, есть пропозал на добавление нативного decimal64 и decimal128, но это не так модно как дженерики и поэтому движения в эту сторону никакого нету. Кстати кому не лень найдите и лайкните )
Язык-то для сетевых микросервисов, на универсальность не претендовал вроде.
Кстати, пример пхп показывает, что идея языка под задачу не работает в этом мире.
Лайкнул
"Ответка" о Haskell https://leetcode.com/discuss/feedback/136097/please-provide-haskell-language-support (немного offtop): на момент коммента 96 лайков. Во время того поста на Хабре было 50 голосов на Leetcode https://habr.com/ru/post/569522/comments/#comment_23297884
Вот не понимаю я этого гонева на GIL. Всё равно в проде запускаешь всё через какой-нибудь uwsgi с кучей воркеров, которые рассаживаются по разным ядрам. Концепция многопоточности может и не идеальная, но вполне стройная и понятная. Т.е. по факту проигрыш в скорости не такой уж и значительный. Особенно, если запариться над оптимизацией некоторых моментов.
Но в рамках воркера с async/await синтаксисом всё исполняется в рамках одного треда.
И? Процессоры-то все утилизированы. А то, что сделано не так, как в другом языке... Ну тык языки-то разные!
Но в рамках воркера с async/await синтаксисом всё исполняется в рамках одного треда.
Если это какой-то веб-сервис, который большую часть времени сидит в ожидании I/O, то в чём проблема? Ожидание не блокирует исполнение.
Как я понял, вот откуда "гонево" на GIL:
Основной язык бэкенда компании Lyft — Python. Агрегатор вычислил
стоимость железа на одну поездку в такси, заказанную через приложение, —
14 центов. Количество поездок, совершённых в 2018 году, — порядка 650 миллионов.
Lyft тратил 100 миллионов долларов в год на инфраструктуру, и сейчас
эта сумма ещё больше. Если бы это был Golang стоимость железа могла бы
быть меньше на несколько десятков миллионов долларов.
А где в цитате GIL? Тут о Python в целом. Python менее производительный как минимум потому, что он интерпретируемый, и это не исправить убрав GIL.
Речь не о том, быстрый Python или нет. Очевидно, он проигрывает комилируемым языкам. Речь о том, что если убрать GIL, то код вообще может замедлится.
Ну и ко всему прочему You are not Google.
Я даже не про конкретно эту статью, а в целом. Любят у питона GIL покритиковать. Есть что-то стереотипное в этом наезде.
Докину 5 копеек. В C# быстрее всего поняли, что постоянно трактовая частота расти не будет и завезли async/await, который затем победоносно завезли в JS и Python почти один в один. Плюс у .NET'а сразу был мощный интероп, unsafe и value type. А с появлением .NET 6 с pgo и кучей оптимизаций asp.net вообще ворвался в топ самых быстрых фреймворков по версии tech empower. И все это с дженериками, орм, исключением и возможностью писать коротко. Так что аргумент go моложе, там по-умолчанию все круче, чем в старших собратьях - ну такое:)
Если верить Википедии, то применение началось с F# https://en.wikipedia.org/wiki/Async/await
Там немного другая история. Async в f# - это computation expression (ближе к корутинам в Kotlin, но немного другая штука). В c# ввели именнно ключевые слова в язык, которые копипастнули в is и python. Ну и f# все же не mainstream-язык. Можно по этой логике добавить, что IO в хаскеле вообще с прошлого века
Балуюсь временами на .NET. Помогаю жене с проектом, ну и так, по мелочи... После этого немного тяжко возвращаться обратно к PHP и Go, которые пока что деньги приносят. В первом нет нормальной типизации, а во втором простыни кода на любой чих, и логика ускользает в процессе парсинга этого кода мозгом. Всё еще не пойму, в чём прикол Go, когда есть Rust.
На сколько я понимаю прикол Go в следующем: делаешь 100500 микро-сервисов, каждый из которых пишет команда обезьянок. Поэтому язык нужен такой, чтобы прям сильно поломать ничего нельзя было. А если код не очень окажется, так не жалко все выкинуть и начать с чистого листа. Зерг раш на максималках такой.
Однажды было высказано такое мнение: Rust — когда надо качественно, на годы вперед. Go — когда надо всё делать побыстрому. Что в итоге выбрали, догадаться несложно :) Опять же, в разрез с командой не пойдешь, когда уже вагон и маленькая тележка сервисов на Go. Смысла еще и Rust добавлять особо нет. Разве что proof of concept запилить в какие-нибудь 5% рабочего времени.
а во втором простыни кода на любой чих
Так это наверное проблема организации кода, а не языка.
Я имел в виду отсутствие некоторых привычных вещей в стандартной библиотеке.
Тоже подумывал перейти с PHP на Go, потом посмотрел сравнение производительности Go и PHP8 и передумал.
Может начну изучать Rust...
А в php8 уже можно как-то хранить состояние ? В реальном пииложении выигрыш го дает за счет того что однажды проинициализированные переменные уже существуют в памяти, а php строит все при каждом обращении насколько я знаю...
Позвольте возразить.
Вы сравниваете несравниваемое. Два совершенно разных языка для совершенно разных задач.
Как человек, некогда писавший на PHP и перешедший на Go, говорю Вам об этом.
Свои пять копеек.
Любой хайлоад, настоящий хайлоад, к проектированию которого подошли с головой, а не с парадигмой что нужно взять язык например GoLang и всё взлетит, это всегда сурогат из совершенно разных решений, разных подходов и как правило на разных языках.
Нет универсального языка, нет универсальных решений. Любое решение это всегда компромис, и за частую сюда подмешиваються ещё и факторы доступности разработчиков, финансовые затраты и т.д.
Мы у себя лабаем на чём бог послал пока формируем mvp, потом выделяем критические секции и переписываем на том, что в данном конкретном сценарии покажет лучший результат. Мероприятие крайне затратное, но без этого никогда не получить максимально эффективное решение
Согласен почти со всем! Особенно про неявность в Python.
Предрекали что он уничтожит неявность, а не будет её плодить.
Тоже перешёл на Golang в качестве основного. Спустя пару лет некоторых вещей всё-таки не хватает.
Спасибо за статью ! Очень интересно )
Сам изучаю Golang в качестве дополнения к основному языку Java )
Тут стоит упомянуть, что переход на другую технологию почти всегда сопровождается падением по зарплате. Рынок верит в то, что опыт работы на конкретном языке важнее, чем опыт в целом.
Даже если это переход в рамках одной области ? (с одного back-end языка на другой )
на вашем опыте, сильно ли упала зарплата (в %) ?
P.S
Я понимаю почему упадет зп если ты писал несколько лет сервисы на бэке , а потом решил перейти в ios разработку...Это другая область, которая требует других навыков....А вот если ты писал несколько лет бэк на С++ а потом перешел на Java ...то почему должна падать зп ?)
на вашем опыте, сильно ли упала зарплата (в %) ?
У меня при переходе с Python на Go зп выросла на 30% но корреляции тут нет никакой, просто на предыдущем месте сильно отстали от роста рынка за время пандемии
У меня зп не упала, я наоборот очень вырос. Это из-за того, что Ozon сам хантит с других языков, и естетсвенно, компенсируют тебе это падение.
По поводу замечания по переезда с одного языка, на котором пишешь бэкенд на другой. Отчасти согласен с вами. Неплохо бы такой эксперимент провести )
Получается что ваш пример и пример компании Ozon показывает что переход между языками в рамках одной области (back-end) не просто возможен, а необходим для дальнейшего развития карьеры ...Так как существует ряд задач для которых хорошо подойдет python , но плохо подойдет golang , но бывают задачи для который наоборот необходим именно golang...И для компании ценность Вас как специалиста который разбирается в двух языках (инструментах) куда выше если бы знали только python так как найм нового сотрудника это всегда риск и лучше использовать действующий штат)
Правда тут очень важный аспект это именно "в рамках одной области", так как существуют специалисты полного стека, на мой взгляд они хорошо чувствуют себя в небольших компаниях и стартапах, но проигрывают в долгосрочной перспективе более направленным на свою область специалистам)
P.S
Интересно ваше мнение на сие сочинение)
Почему я перешёл с Python на Go: choose your fighter