Comments 44
листал, ждал когда вода закончится и мясо пойдет, статья и закончилась
хорошо, что статья короткая, спасибо
Видимо в Skillbox и обучение такое, как минимум у этого эксперта. Бла-бла-бла и ничего конкретного. Где туу опыт неудачного переезда с Python на Go тоже не понял
ну человек — дипломированный специалист Cisco, почему он не может быть экспертом? У него экспертиза в сетях, он сетевой архитектор и вот он поковырял Go и сложил такое мнение в процессе, при этом про преимущества Golang он тоже пишет. :)
"Бла-бла-бла" — это объяснение. Если нужна конкретика, то peer-to-peer сеть — это единственное, что можно написать на GO с реальной особенностью языка, а больше делать в языке нечего. Это ИМХО. Я не настаиваю на этом. Если есть желание, я готов совершенно бесплатно и без Skillbox подискутировать с Вами, вижу Вы истинный эксперт в вопросе, так что наша дискуссия будет интересной.
человек — сетевой инженер, попробовал применить Go для своих задач и понял, что ему не подходит. При этом пишет про задачи, где он подошел бы идеально — просто это не его задачи.
"Человек и сетевой инженер" взял не подходящий для его задач инструмент и жалуется, что инструмент ему не понравился. Про задачи, где Go подошел бы идеально, человек и инженер пишет какую-то оторванную от реальности околесицу (впрочем, как и про назначение той же Java). И про стек сбера и тбанка он странное пишет - Go у них отлично применяется.
В общем, человек и сетевой инженер решил порассуждать о материях, в которых ничего не понимает. Не разработчик он.
Плюс статья в разделе «Мнения», а не кейсы, поэтому тут именно мнение
Если бить — не надо :)
Закончил чтение статьи на моменте, когда персонаж назвал себя экспертом.
Главная проблема языков типа Python и PHP с моей точки зрения - это отсутствие статической типизации и отсутствие явного объявления переменных. То есть достаточно просто написать
foo = 10
и у нас готовая новая переменная. Или не новая, а измененная старая. Понимаете? Одна маленькая опечатка в имени и... всё будет замечательно работать. Но неправильно. И это неправильно может вылезти не сразу, а очень нескоро и в самом неожиданном месте. Вот эта особенность была для меня просто как нож по горлу. И языки типа Python и PHP вызывали у меня, С/С++ программиста, абсолютно устойчивое неприятие. Кто-то скажет что это мелочь, но для меня это - фундаментальный дефект дизайна языка.
Но потом появился Go. И оказалось что это ровно то что нужно, как глоток свежего воздуха. Простой высокоуровневый (в отличие от того же С++) язык, куча библиотек, и переменные объявляются явно, ровно так как надо! В общем теперь многое, главным образом всякие утилиты и программы для работы с сетью, пишу на Go.
Тут согласен. Статическая типизация решает, а с Python можно получить кучу глюков внутреннего пробрасывания переменных. Действительно, это большая проблема, а Go её решил. Лично для меня это был прикольный момент, но в процессе я выбрал C# (так как я могу сделать бОльшее), а не Go (хотя с ним можно тоже поиграть с теми же вопросами). Но тут уж на вкус и цвет, но статическая типизация — однозначный плюс
Вы с PHP давненько не работали, видимо 🙃
В примере со "словариком" что-то мне стало непонятно - допустим, в питоне это был массив "словариков", но в го - это уже массив структур. Можно было бы в го сделать массив мап map[string]any, и было бы так же коротко - только типизации бы не было - причем так же, как и в питоне. По хорошему, надо было бы и в питоне объявить структуру (класс), иначе тот, кто будет такой код за вами поддерживать - вам спасибо не скажет.
Присоединюсь к остальным комментаторам, примеров перехода с питона на го в статье я так и не увидел
Несколько раз упоминается PyPy, но было бы здорово увидеть конкретные примеры, где он делает "то же самое" - так же быстро? Или может быть даже быстрее? Может всё-таки зависит от ситуаций применения?
Тут согласен. Я не пытался сравнить два кода (это издевательство над обоями языками, как по мне), но если брать пример со словариком — да. Но есть Java. Зачем Go, если есть ява? Та же структура и тот же подход к проектированию.
С вопросом про PyPy. Оставлю ссылку на статью и гифку оттуда. Это просто понижение языка с интерпретируемого на компилируемые части:
Разгон дикий
Не очень понятны условия работы. Это в обоих случаях чистый запуск без кэшей?
А если pycache всё-таки будет? Разгон тоже дикий будет?
А если это I/O bound операции, вроде обработки HTTP API, насколько влияние pypy становится существенным?
Даже на сайте pypy не все тесты выполняются быстрее cpython.
Вы просто искажаете реальную картину, показывая только то, что удобно.
пример с pypy выглядит несколько наивно. M:N асинхронность есть (подскажу, нет)? Ну тогда высказывания вида "питон выдает сравнимую производительность" превращаются в пшик.
К слову о том, зачем Go, если есть Java - все она же, M:N. Если она нужна, Go даёт весьма ощутимый выигрыш. Если нет - не дает. Все просто.
Вот поэтому и начинать жизнь программиста с питона вредно. Трудно переходить на другие языки. Мне лично с С++ и с Java переход на Go не составил особого труда.
Главное преимущество go перед C#/Python и другими - он выдаёт eye файл. один. С которым не надо тащить runtime. Достаточно просто скопировать и запустить.
Это перекрывает все остальные преимущества C# и тем более скриптовых языков.
Там еще если с CGO_ENABLED=0 собирается, то есть еще киллерфича: собрать контейнер FROM scratch с двумя слоями: FROM stage1 cp /go/bin/app /bin и CMD ["app"]. ну само собой в stage1 собираем наш бинарь. Для микросервисов - самое то: ничего лишнего и даже шелла в контейнер нет - безопастники пищат от восторга.
Тут еще добавлю: имею два пет-проджект одного типа: индикатор в linux-овую панель для одного облачного диска. Один на питоне писан в далеком 2015 (еще на 2.7), переписан в Python3, ООП и практически заморожен. Второй родился в 2018 как "надо бы что-то пробовать на go написать, для прокачки скилзов". И там сначала появился низкоуровневый слой, который я к питонячей морде прицепил, а потом я накопал для Go библиотеки для GTK и QT и к низкоуровневой либе навесил два разных индикатора. По прошествии нескольких лет я копнул тему и выяснил, что GTK-шную либу форкнули и перевели на работу через D-BUS: т.е. GUI уже в зоне ответственности того, что там на D-BUS зарегистрировалось как "я вам индикатор нарисую". Это дает полною отвязку от того что там у вас под капотом вашей DE. Ну и с-но QT-шный индикатор пошел под нож (в архив), а GTK-шный стал универсальным (работает практически под любой DE из зоопарка DE Linux).
Так вот к чему это я. Питончему коду от роду с 2015, а гошному c 2018 и понятно как первый питонячий расползся сильнее (что и по звездочкам на гитхаб очевидно)
Одноко в питонячем, что не новая версия Ubuntu - то начинают зависимости отваливаться или меняться... То там что-то перестает работать - в общем мороки от его поддержки - довольно много. Go-шный вариант вообще почти без проблем работает годами изредка возникают отдельные вопросы часто упирающиеся в деланные руками не из того места, теми самыми кто "я вам индикатор нарисую". И да конечно круг пользователей гораздо меньше у Go-шного. Но я его больше сам переделывал (чем, надо признать, и багов подсыпал) чем всякие депенденси правил.
Т.е. если совсем коротко резюмировать - многолетняя поддержка питонячего кода - изрядны гиморрой. А гошного - преимущественно обновление версии go и библиотек.
Это перекрывает все остальные преимущества C#
Справедливости ради: C# в эти дни тоже собирается в один бинарь, при желании даже не очень большой, а при большом желании даже очень маленький.
Кстати, после того комбайна в который превратился C# go-шный ООП выглядит классно - просто и со вкусом.
Опять-таки не забываем кто-то Go придумывал/разрабатывал.
Я попытался и не смог в go. Попытался накидать маленькую утилиту по конвертации курсов криптовалют. Может я глуп для go. Поискал примеры на go разных програм на гитхабе... госпаде... дикие портянки кода, в одном файле более одного класса, странное наследование без инкапсуляции,...мне стало просто больно.
А что сложного в конвертации курсов? Там по-сути надо слайс уметь траверсить, и всё. А ля for v,_ := range mySlice {...}. Ну и дебажить ещё через fmt.Println когда надо
В чем проблема когда больше одного класса в файле?
Я думаю что эта мода из Js пошла куда не могут нормальный линкер завезти.
Файл это модуль - который должен реализации Ловать функционал а не место хранения для класса.
Рекомендую к прочтению Оустерхота - Архитектора компьютерных систем. он там как раз с Мартином (автором чистого кода) по этому поводу полемизируют
Рекомендую книгу по go:
Let’s’ go
Товарищ реально классно написал.
Я не осуждаю. В принципе можно и всю программу написать в одном файле 12000 строк. Можно писать только одними elseif и goto. Я не прогер, я вообще сварщик. Много лет по фану пишу на php. Один раз написал функцию автолоада и всё, скрипт знает где какой класс лежит. Если я создаю класс \Market\Goods\Apple значит он и лежит в этих папках (условно), а тут ещё импортить нужно.... Поэтому моё мнение это мнение обывателя.
Ну похоже не проникся подходами го. Всё-таки структуры, а не классы. И упор в композицию, а не наследование.
странное наследование без инкапсуляции,...
Действительно, отсутствие наследования - одно из самых странных наследований, какие я когда-либо видел)
3й питон появился в 2008. А в 2017 был уже python 3.6.
У всех языков свои преимущества и недостатки. Ахиллесова пята Python в том, что приложения на нем трудно деплоить, потому что язык разрабатывался в первую очередь для инженеров. Для Go - это просто собрать бинарник. Для Java - скачать и распаковать JDK. А вот деплоить Python без контейнеров - это больно. Начиная с того, что официальных portable сборок под Linux просто не существует и заканчивая плясками вокруг virtualenv и версией glibc. А деплой в контейнеры это уже другой уровень сложности и архитектуры окружения.
Второй глобальный недостаток Python для меня - это его однопоточность. С приходом ASGI и FastAPI это уже менее актуально. Но если брать классику WSGI/Django, то Java Web приложения скейлятся по потокам, а WSGI - по процессам. Это значит что если приложение хочет считать/хранить хоть какие-то метрики (то есть shared state), то нужен как минимум Redis или просто база данных. Для условного сервиса это часто лишний и ненужный уровень сложности + лишняя зависимость.
Поэтому Python имеет место быть, и для ML вряд ли его кто-то заменит в обозримом будущем, но для Web, Java/Kotlin на чем-нибудь легком типа Micronaut/Helidon или Golang будут как минимум не хуже.
Если сравнивать языки, то в комплексе: решаемые задачи, библиотеки, сложность написания vs сложность чтения кода, быстродействие, комьюнити, безопасность, сборка и развертывание, качество и доступность инструментов разработки и прочее. А не где словарик короче инициализируется.
Главная проблема языка Го в его философии "Не ломать код выпуском мажорной версии".
При этом протобуфер - это ад на земле с их циферками. А в языке самом нету дефолтных значений у функций и kwargs. И ООП там подрезали на какой-то хрен.
Зато работает быстро...
Только вот что там быстро работает. Также быстро может работать на с++.
Коробочный параллелизм в Го - это вообще шаманство. Ни потоков, ни процессов. Горутина ёпта. Чистый go to и никакого мошенничества
Весь перформанс там держится на фишках типа пулов памяти, зероаллокаций, пулов горутин. И ещё в дедлок надо не улитеть, когда всё это варево готовишь.
Там из коробки и по мануалам, и советам чатов жпт всё работает хуже чем в старом питоне. Нужно путь самурая пройти чтобы там накодить что то реально быстрое и непомирающее. То есть прокачиваешься до мидл+ и вот он - перформанс. Но зараза отсутствие кваргов и дефолтоф - не прощу...
Священная война языков программирования или опыт неудачного переезда с Python на Golang