Думаю, что Go — да, хороший кандидат на вытеснение Питона. Нынешние ниши использования хорошо перекрываются, Go проще (но не примитивнее) и производительнее Питона.
Здравствуйте, e.thrash, Вы писали:
ET>Казалось, что Python пришел надолго. ET>Но вот что-то стал часто слышать, что Go вытеснит Питон. ET>Что думаете?
Зависит от области.
Из machine learning & science питон вытеснять пока некому. Go крайне неудобен для этой области, да и контингент консервативный.
Из средства написания бакенда — да вытесняет. У Go лучше производительность, прощё деплой, родной рантайм именно на эту нишу нацелен как и в целом язык.
Из средства написания всяких утилит — частично делят область. Что-то скорей останется на питоне, что то уйдет на go.
Вообще все выглядит как уход от языков общего назначения к специализированным языкам в отдельных предметных областях. Поэтому будут существовать, но в разных нишах.
Здравствуйте, Kswapd, Вы писали:
K> Go проще (но не примитивнее) и производительнее Питона.
Еще как примитивнее. То, что на питоновских list/set/generator comprehensions делается в одну строчку, на Го придется полэкрана дурацких циклов с императивной записью в массивы городить.
Здравствуйте, e.thrash, Вы писали:
ET>Казалось, что Python пришел надолго. ET>Но вот что-то стал часто слышать, что Go вытеснит Питон. ET>Что думаете?
У нас в продукте и то и другое активно используется. При этом языки вообще не взаимозаменяемы, так как Go никак не годится ни для быстрого прототипирования, ни для написания тестов, ни для скриптования тех или иных задач. При этом у Go есть довольно четкая ниша — разработке Web-ориентированных приложений и написание консольных утилит. И в этих областях он конечно потеснит Python еще больше, но про вытеснит и речи идти не может.
K>> Go проще (но не примитивнее) и производительнее Питона.
DM>Еще как примитивнее. То, что на питоновских list/set/generator comprehensions делается в одну строчку, на Го придется полэкрана дурацких циклов с императивной записью в массивы городить.
Ну, функции в Go являются полноправными объектами, так что потенциал для функциональщины есть. Если хочется в одну строчку, придётся писать функцию. Люди делают экспериментальные библиотеки для подобных вещей, например: https://godoc.org/robpike.io/filter (правда, с предупреждением, что использовать не следует, пишите циклы ).
Здравствуйте, Kswapd, Вы писали:
K>Ну, функции в Go являются полноправными объектами, так что потенциал для функциональщины есть. Если хочется в одну строчку, придётся писать функцию. Люди делают экспериментальные библиотеки для подобных вещей, например: https://godoc.org/robpike.io/filter (правда, с предупреждением, что использовать не следует, пишите циклы ).
Хм, вот так у него выглядит map, который он почему-то даже не назвал map, что уже говорит о многом.
func Apply(slice, function interface{}) interface{}
Но это же позор совершенный и нетипизированный. Как void* везде, только хуже и медленнее. Так жить нельзя. А хочешь типизированно — пиши императивные циклы. Эх.
Здравствуйте, D. Mon, Вы писали:
DM>Хм, вот так у него выглядит map, который он почему-то даже не назвал map, что уже говорит о многом. DM>
func Apply(slice, function interface{}) interface{}
DM>Но это же позор совершенный и нетипизированный. Как void* везде, только хуже и медленнее. Так жить нельзя. А хочешь типизированно — пиши императивные циклы. Эх.
Да, но... Ты можешь посадить за проект программиста практически любого уровня и он нахреначит императивные циклы и все будет работать как и ожидалось. Да, громоздко, да, отвратно выглядит, но работает и делает то, что нужно!
DM>Хм, вот так у него выглядит map, который он почему-то даже не назвал map, что уже говорит о многом. DM>
func Apply(slice, function interface{}) interface{}
DM>Но это же позор совершенный и нетипизированный. Как void* везде, только хуже и медленнее. Так жить нельзя. А хочешь типизированно — пиши императивные циклы. Эх.
Слово "map" уже занято под встроенный тип данных. Кстати, стандартная функция с именем "apply" и такой же семантикой существует в Лиспе, так что ничего нового Пайк не изобрёл.
Пустой интерфейс всё же не так плох, как void*, поскольку попытка вытащить из interface{} не тот тип приведёт к описанной в спецификации panic-ситуации, в отличие от UB в C. Производительность обсуждать без конкретных бенчмарков нельзя, да и нет смысла: пока что программы на Go исполняются в разы медленнее эквивалентных программ на C.
Что касается нетипизированности, то это следствие отсутствия в Go средств типизированного обобщённого программирования (generics). Это вспоминают чаще всего, критикуя Go, но на практике без дженериков можно прекрасно жить (например, генерируя код внешними средствами).
В связи с этим вспоминаю свою прошлую попытку спрыгнуть с C++ на более человеческий язык (это была Java). Ранняя Java тоже не имела дженериков, и ничего. Попытка получилась неудачной в связи с тем, что в Web-проекте, в который я попал, программировали больше на XML, чем на Java . Сейчас пробую перебежать в стан Go. Кстати, хайп вокруг Go часто сравнивают с первыми годами Java. И действительно, философии и свойства этих языков во многом схожи. Но Java уже прошла долгий путь, наделав много ошибок, которых пытается избежать Go.
Раз уж упомянули Rust, будет нелишне вспомнить заметку Эрика Рэймонда, широко известного как ESR: "Rust сильно разочаровал меня". Он сравнил свои впечатления от Go и Rust как потенциальных убийц C (в оригинале — learned <both languages> in order to evaluate as a C replacement), реализовав для пробы несложное сетевое приложение. Go ему понравился намного больше: кривая обучения несравненно менее крутая, к тому же в системной библиотеке Rust не оказалось некоторых критически важных функций.
Здравствуйте, Kswapd, Вы писали:
vsb>>Думаю, Rust вытеснит и того и того.
K>Раз уж упомянули Rust, будет нелишне вспомнить заметку Эрика Рэймонда, широко известного как ESR: "Rust сильно разочаровал меня". Он сравнил свои впечатления от Go и Rust как потенциальных убийц C (в оригинале — learned <both languages> in order to evaluate as a C replacement), реализовав для пробы несложное сетевое приложение. Go ему понравился намного больше: кривая обучения несравненно менее крутая, к тому же в системной библиотеке Rust не оказалось некоторых критически важных функций.
Go тормоз и жрёт память. Писать приложения на Go — не уважать своих пользователей.
Здравствуйте, vsb, Вы писали:
vsb>Go тормоз и жрёт память. Писать приложения на Go — не уважать своих пользователей.
А вот ничего подобного. Потребление памяти у Go совсем не велико, при этом он не такой уж и тормоз, в общем случае быстрее Java/C#/Python, но медленнее C++. Хотя язык и компилируется в нативный код, оптимизатор из рук вон плохой, у авторов NIH-синдром что не позволило им взять LLVM.
Здравствуйте, Kswapd, Вы писали:
K>Пустой интерфейс всё же не так плох, как void*, поскольку попытка вытащить из interface{} не тот тип приведёт к описанной в спецификации panic-ситуации, в отличие от UB в C. Производительность обсуждать без конкретных бенчмарков нельзя, да и нет смысла: пока что программы на Go исполняются в разы медленнее эквивалентных программ на C.
В основном из за очень-очень плохого оптимизатора. В Go можно понять всё, кроме религиозных заморочек авторов не позволивших им взять LLVM.
K>Что касается нетипизированности, то это следствие отсутствия в Go средств типизированного обобщённого программирования (generics). Это вспоминают чаще всего, критикуя Go, но на практике без дженериков можно прекрасно жить (например, генерируя код внешними средствами).
С генераторами жить скорее приходится, особого удовольствия это не доставляет. Особенно когда для каждого массива приходится свой цикл с поиском рожать вместо банального обобщенного `find`.
K>В связи с этим вспоминаю свою прошлую попытку спрыгнуть с C++ на более человеческий язык (это была Java). Ранняя Java тоже не имела дженериков, и ничего. Попытка получилась неудачной в связи с тем, что в Web-проекте, в который я попал, программировали больше на XML, чем на Java . Сейчас пробую перебежать в стан Go. Кстати, хайп вокруг Go часто сравнивают с первыми годами Java. И действительно, философии и свойства этих языков во многом схожи. Но Java уже прошла долгий путь, наделав много ошибок, которых пытается избежать Go.
Шумиха вокруг Go вызвана тем, что он позволяет использовать откровенных жопоруков, коих в огромных корпорациях очень много. Так что я бы сильно не радовался соскочив с C++ на Go, так как Go — язык для мартышек и по насыщению рынка их ждёт судьба PHP программистов.
KP>у авторов NIH-синдром что не позволило им взять LLVM.
Не совсем так. Go — обычный язык программирования, который может быть реализован несколькими компиляторами и даже интерпретаторами. FAQ на оф. сайте говорит, что на данный момент развивается и поддерживается три "официальных" компилятора: gc (основной), gccgo (использующий бэкенд от gcc) и gollvm (использующий соответственно LLVM). Видимо, вопрос того, какой подход победит, остаётся открытым.
Хотя лично мне нравится идея трансляции Go в промежуточный абстрактный ассемблер. Есть в этом безуминка гения .
KP>Шумиха вокруг Go вызвана тем, что он позволяет использовать откровенных жопоруков, коих в огромных корпорациях очень много. Так что я бы сильно не радовался соскочив с C++ на Go, так как Go — язык для мартышек и по насыщению рынка их ждёт судьба PHP программистов.
Снова дежавю: так раньше говорили про Java-программистов. Посмотрим, как пойдёт. Мне кажется, сравнивать Go с PHP несколько неправильно. PHP — просто помойка, язык, состоящий из большого количества бездумно собранных вместе костылей. Программирование на нём не способствует воспитанию хорошего стиля. Go — результат осознания, что такие вещи, как наследование реализации и исключения, возможно, приносят больше вреда, чем пользы. Говорят, Гослинг (создатель Java) признавал, что наследование, выражаемое ключевым словом extends, следовало бы исключить из языка, если б это было возможно. Go — простой, минималистичный и стройный (да, откровенно императивный) язык, созданный с намерением избежать уже известных ошибок дизайна языков программирования, начиная с C. При написании на Go, например, объектно-ориентированных систем намного меньше возможностей "уехать" в переусложнение (вроде создания ненужных развесистых иерархий классов в Java или C++). Таким образом, возможно, Go поспособствует воспитанию из мартышек нормальных качественных программистов .
Интересный опыт использования Go в реальном большом проекте: https://p.umputun.com/2017/04/18/god-s-go-v-riealnoi-rabotie/ . Люди в целом довольны. Отмечают, в частности, что горутины+каналы способствуют улучшению архитектуры, а "хардкорное" FP не приживается.
