Комментарии 10
класс, вы стали снова оперативно предоставлять доступ к электронным книгам!
Изучаю го, после питона (опыт 5 лет). Не могу понять для чего в Го рефлексия. Не мучаетесь, пройдите туториал по питону и шаблонизации текста и генерируйте код го через шаблоны ниндзя.
Ну, по сути, использование рефлексии в Го выглядит как попытка стать динамически типизированным, цепляясь за производительность. Не зря же многие умные люди говорят,что статическая типизация быстрее динамической. Знают чего небось. Профайлеры умеют включать.
Не усидеть с рефлексией на двух стульях. А если её прям НАДО использовать в кодогенераторах - то Вам в питон.
А если рефлексия нужна в ОРМ? ОРМ - это зло. Надо уметь понимать язык СУБД.
А если у меня универсально сложный анмаршл? И супер синтез структура - то Вам опять в питон (или вы ошиблись в архитектуре, посмотрите на бизнес кейсы внимательнее). Пока Го там будет пытаться сохранить производительность, питон просто её принесёт в жертву. И результата добьётесь за сутки.
Кароче хотите гибкости - учите питон. Хотите хайлоад - нафиг рефлексию. И никаких компромиссов.
Нужен генератор кода - идём в питон. Нужно что то супер абстрактное - идём в питон.
Книжки они там целые выпускают... О том как весь мир опутать одним инструментом. Знаем мы такие книжки. На питоне мешок книжек про оптимизацию. А смысл в этом? Под каждый кейс - свой инструмент. А язык - это инструмент)
Ну, по сути, использование рефлексии в Го выглядит как попытка стать динамически типизированным,
В данном случае это компромисс, т.к. го не стремится быть самым производительным/быстрым языком. Суть в том, что го достаточно производительный и достаточно удобный и в целом довольно много людей могут начать на нём быстро писать довольно производительный код. Рефлексия замедляет код, но не всегда делает его медленным. В большинтсве случаев код с рефлексией будет работать быстрые и потреблять меньше ресурсов чем аналогичный код на питоне или пхп.
А если рефлексия нужна в ОРМ? ОРМ - это зло. Надо уметь понимать язык СУБД.
Есть ОРМ основанные на генерации и есть основанные на рефлексии(я про го), если для приложения не нужна производительность то можно использовать например gorm, если нужен более производительный код можно использовать сырой sql или орм на основе генерации кода.
А если у меня универсально сложный анмаршл?
Если речь про "анмаршл" json/xml, то я не сказал бы что в питоне это делать намного проще делать.
Кароче хотите гибкости - учите питон. Хотите хайлоад - нафиг рефлексию. И никаких компромиссов.
В целом немного странное утверждение, особенно если человек знает го и в целом задача на нём решается, то хз зачем использовать другой язык.
На питоне мешок книжек про оптимизацию. А смысл в этом?
Наверное если проект написан на питоне, то обычно дешевле оптизировать код а не переписывать его на другом языке.
Если речь про "анмаршл" json/xml, то я не сказал бы что в питоне это делать намного проще делать
В питоне json - это его суть. Если говорить языком го - то, например list[] в питоне - это []interface{} на го. При этом в питоне такой объект является примитивной конструкцией, не требующей как в го, например, утверждать типы(или копировать значения списка []int в слайс пустого) чтобы прочитать данные списка/слайса или положить данные в список/слайс.
Наверное если проект написан на питоне, то обычно дешевле оптизировать код а не переписывать его на другом языке.
Если это микросервис - то дешевле переписывать. Потому что его всё равно переделывать. И нужен супер скил, и книжек по оптимизации мешок, а в идеале готовый спец, умеющий код на питоне разгонять. А если взять Джуна с опытом в го. Он напишет хардкод месиво на коленке и оно уже будет быстрее работать.
А весь проект, да. Сложно сразу обуть на новые рельсы. Но слона по частям едят обычно
В целом верно - для каждой задачи можно найти более подходящий язык. Но (если задача не очень простая) он не будет идеальным и придется делать что-то нестандартное.
Python удобен с его кучей батареек (одна только админка django чего стоит), но на нем всегда есть соблазн уйти в оверинжиниринг, когда выходит что-то околоджавное - 10 наследований + миксины. Но если нужно сделать асинхронный код, который легко читать и поддерживать, то go показывает себя с лучшей стороны.
Идеального языка нет (могу сказать, как писавший минимум на десятке), мир не двухполярный. Поэтому у каждого языка есть варианты, как обойти ограничения. У питона есть threadpool и asyncio, которые могут позволить сделать быстрый парсер (но оба решения не без недостатков). У го есть рефлект, который позволяет удобно разбирать json. При этом так же есть вариант парсить и без рефлекта, когда нужна ультра-производительность. Вопрос в том, что ультра-производительность нужна обычно в других местах кода, а разобрать и собрать json, это вторичная операция.
Пул потоков в питоне он не для CPU boud задач. Ну джсон на пуле потоков точно париться не будет паралельно.Там GIL воткнут.
Из наблюдений. Питон время измеряет стандартным пакетом в микросекундах. А Го - в нано.
Именно GIL не позволяет питону быть быстрее Го в cpu-bound задачах.
А пул процессов в питоне - он дорогой по оперативке. Особенно Спаун, который обычно более надёжен чем форк. Тут го опять выигрывает своими легковесными потоками-горутинами.
Однако в Го крайне легко словить дедлок. А в питоне так как там GIL. Про дедлок не слышали даже мидлы. И то что там гонки с данными бывают тоже никто не слыхал из питонистов.
Книга «Golang для профи: Создаем профессиональные утилиты, параллельные серверы и сервисы, 3-е изд.»