Здравствуйте, Kswapd, Вы писали:

K> Go проще (но не примитивнее) и производительнее Питона.

Еще как примитивнее. То, что на питоновских list/set/generator comprehensions делается в одну строчку, на Го придется полэкрана дурацких циклов с императивной записью в массивы городить.

Здравствуйте, kaa.python, Вы писали:

KP>Официальный и реально годный для использования в продуктовой разработки только gc, остальные не более чем игрушки небольшого количества энтузиастов.
gccgo — полноценно работающий. Я его использую для финальной сборки, код существенно быстрее получается.

Здравствуйте, e.thrash, Вы писали:

ET>Казалось, что Python пришел надолго.
ET>Но вот что-то стал часто слышать, что Go вытеснит Питон.
ET>Что думаете?

Думаю, Rust вытеснит и того и того.

Здравствуйте, kaa.python, Вы писали:

KP>Шумиха вокруг Go вызвана тем, что он позволяет использовать откровенных жопоруков, коих в огромных корпорациях очень много. Так что я бы сильно не радовался соскочив с C++ на Go, так как Go — язык для мартышек и по насыщению рынка их ждёт судьба PHP программистов.

Это неверно. В разработке софта сложность ЯП составляет исчезающе малую часть всех "сложностей" с которыми сталкиваются разработчики проекта. Основная сложность-это выбор/разработка алгоритмов и их качественная реализация. И тут всё определяется целевой сферой. Например, если это ML и AI, то в проекте могут участвовать только компетентные в этом чуваки. Нельзя разработку проекта, связанного с AI, доверить мартышкам, только, благодаря тому, что он пишется на Go. И наоборот, необязательно привлекать гуру к разработке какого-нибудь простейшего GUI-я, только вследстсвии того, что этот GUI пишется на C++, его на Qt и мартышки запилят не хуже любого гуру. На C++ тоже можно писать так, что любая мартышка справится, банально используя (задав это жёстко принятыми в проекте правилами кодинга) только его самое простое подмножество. Более того, подавляющее большинство C++ проектов именно так и пишется, очень редко где в промышленной разработке софта на C++ юзаются его "сложные пласты", почти везде тот самый пресловутый Cи c классами.

Здравствуйте, kaa.python, Вы писали:

C>>gccgo — полноценно работающий. Я его использую для финальной сборки, код существенно быстрее получается.
KP>Похоже что, gccgo решение, но он отстает от основной ветки:
KP>

The GCC 7 releases include a complete implementation of the Go 1.8.1 user libraries

В GCC 8 образца лета прошлого года — уже версия 1.10.

Тут основная проблема с тем, что циклы релиза и стабилизации у gcc слишком долгие. Гопники портируют всё в GCC всё достаточно быстро, а потом оно там год лежит.

Go используется примерно в 300 различных проектаов, связанных с разработкой ПО:
https://www.freshports.org/lang/go/

Здравствуйте, Kswapd, Вы писали:

K>Не совсем так. Go — обычный язык программирования, который может быть реализован несколькими компиляторами и даже интерпретаторами. FAQ на оф. сайте говорит, что на данный момент развивается и поддерживается три "официальных" компилятора: gc (основной), gccgo (использующий бэкенд от gcc) и gollvm (использующий соответственно LLVM). Видимо, вопрос того, какой подход победит, остаётся открытым.

Официальный и реально годный для использования в продуктовой разработки только gc, остальные не более чем игрушки небольшого количества энтузиастов.

K>Хотя лично мне нравится идея трансляции Go в промежуточный абстрактный ассемблер. Есть в этом безуминка гения .

Это есть в официальном Go, просто "правильное", с играми и девочками, а не какой-то там LLVM.

the compiler operates on a kind of semi-abstract instruction set, and instruction selection occurs partly after code generation

Авторы Go большие поклонники Plan 9 и не могли себе позволить такую ересь как использование готового бекэнда для компиляторя:

Although the assembler takes its guidance from the Plan 9 assemblers, it is a distinct program, so there are some differences.

Здравствуйте, kaa.python, Вы писали:

KP>В основном из за очень-очень плохого оптимизатора. В Go можно понять всё, кроме религиозных заморочек авторов не позволивших им взять LLVM.
В требованиях к Go, когда он проектировался в 2006-м году, была скорость компилятора. В то время LLVM была ещё маленькой и clang только-только появлялся. Так что Go сделали свой кодогенератор и альтернативную полноценную реализацию для gcc (которая и сейчас развивается). Получилось очень неплохо — скорость компиляции в первой версии зашкаливала.

Казалось, что Python пришел надолго.
Но вот что-то стал часто слышать, что Go вытеснит Питон.
Что думаете?

Здравствуйте, 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 — не уважать своих пользователей.

Здравствуйте, Kswapd, Вы писали:

K>Раз уж упомянули Rust, будет нелишне вспомнить заметку Эрика Рэймонда, широко известного как ESR
Он банальный дилетант в обоих языках. Можно почитать его посты на golang-dev и rust-internals.

Здравствуйте, Cyberax, Вы писали:

C> Получилось очень неплохо — скорость компиляции в первой версии зашкаливала.

А потом компилятор переписали на Го, и скорость просела безвозвратно.

Здравствуйте, e.thrash, Вы писали:

ET>Казалось, что Python пришел надолго.
ET>Но вот что-то стал часто слышать, что Go вытеснит Питон.
ET>Что думаете?

Некоторые слышат, что надо убивать, некоторые, что Go использовать. Сложно сказать почему у тебя именно с Go это связано.

Думаю, что Go — да, хороший кандидат на вытеснение Питона. Нынешние ниши использования хорошо перекрываются, Go проще (но не примитивнее) и производительнее Питона.

Здравствуйте, e.thrash, Вы писали:

ET>Казалось, что Python пришел надолго.
ET>Но вот что-то стал часто слышать, что Go вытеснит Питон.
ET>Что думаете?
Зависит от области.
Из machine learning & science питон вытеснять пока некому. Go крайне неудобен для этой области, да и контингент консервативный.
Из средства написания бакенда — да вытесняет. У Go лучше производительность, прощё деплой, родной рантайм именно на эту нишу нацелен как и в целом язык.
Из средства написания всяких утилит — частично делят область. Что-то скорей останется на питоне, что то уйдет на go.

Вообще все выглядит как уход от языков общего назначения к специализированным языкам в отдельных предметных областях. Поэтому будут существовать, но в разных нишах.

Здравствуйте, e.thrash, Вы писали:

ET>Казалось, что Python пришел надолго.

Python никуда и не уходил. На FreeBSD с 2006 года с ним дело имею — всё ровно.

ET>Но вот что-то стал часто слышать, что Go вытеснит Питон.

Вряд ли. Приложений на Go мало. Зависимостей от Go у меня в системе нет.

ZEN>Вряд ли. Приложений на Go мало. Зависимостей от Go у меня в системе нет.

А я и про питон только на рсдн слышу )

Здравствуйте, 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.

vsb>Думаю, Rust вытеснит и того и того.

Раз уж упомянули Rust, будет нелишне вспомнить заметку Эрика Рэймонда, широко известного как ESR: "Rust сильно разочаровал меня". Он сравнил свои впечатления от Go и Rust как потенциальных убийц C (в оригинале — learned <both languages> in order to evaluate as a C replacement), реализовав для пробы несложное сетевое приложение. Go ему понравился намного больше: кривая обучения несравненно менее крутая, к тому же в системной библиотеке Rust не оказалось некоторых критически важных функций.

Здравствуйте, 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 не приживается.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, kaa.python, Вы писали:

KP>>Официальный и реально годный для использования в продуктовой разработки только gc, остальные не более чем игрушки небольшого количества энтузиастов.
C>gccgo — полноценно работающий. Я его использую для финальной сборки, код существенно быстрее получается.

Похоже что, gccgo решение, но он отстает от основной ветки:

The GCC 7 releases include a complete implementation of the Go 1.8.1 user libraries

что при модели развития библиотек Go — основной акцент на последнюю версию языка, иногда может быть неприятно. Но в целом да, лучше чем я думал.

Здравствуйте, kaa.python, Вы писали:

KP>Шумиха вокруг Go вызвана тем, что он позволяет использовать откровенных жопоруков, коих в огромных корпорациях очень много. Так что я бы сильно не радовался соскочив с C++ на Go, так как Go — язык для мартышек и по насыщению рынка их ждёт судьба PHP программистов.

После того, как в проекте заменил C++ на Go (95%) и Rust (5%), появилось куда больше времени на прокачку навыков помимо "C++ граблеобходитель". Наконец-то можно плотно заняться расширением кругозора, архитектурой и софт скиллами
А если у кого-то профессионализм измеряется исключительно языком — это его печаль и беда

Здравствуйте, ct0r, Вы писали:

C>После того, как в проекте заменил C++ на Go (95%) и Rust (5%), появилось куда больше времени на прокачку навыков помимо "C++ граблеобходитель". Наконец-то можно плотно заняться расширением кругозора, архитектурой и софт скиллами

Я уверен что ты тут сильно недоговариваешь, так как вместо грабель C++ (каких, кстати?) ты получаешь модель памяти Rust, которая те же грабли, но вид с боку. А вот Go, да, это как раз то, о чем я говорил. Любой посредственный разработчик не сумевших осилить более сложный и выразительный инструмент превращается в обезьянку способную если не Войну и мир написать, но что-то не сразу падающее точно. Правда потом более опытным дядям всяко приходится смотреть на поделие осиливших хотя бы Go и продумывать как это расчищать

C>А если у кого-то профессионализм измеряется исключительно языком — это его печаль и беда

Одна из составляющих профессионализма — знание своего рабочего инструмента. Язык программирования — один из основных рабочих инструментов. Так что разработчик не осиливший языка не может считаться профессионалом. Вторым сопоставимым по важности элементом будет домeнная область.

Здравствуйте, Cyberax, Вы писали:

C>В GCC 8 образца лета прошлого года — уже версия 1.10.

C>Тут основная проблема с тем, что циклы релиза и стабилизации у gcc слишком долгие. Гопники портируют всё в GCC всё достаточно быстро, а потом оно там год лежит.

Понял, спасибо. Для моих текущих задач это не вариант, но в целом отрадно знать что есть компилятор с нормальным бекэндом

Здравствуйте, D. Mon, Вы писали:

C>> Получилось очень неплохо — скорость компиляции в первой версии зашкаливала.
DM>А потом компилятор переписали на Го, и скорость просела безвозвратно.
Зато компьютеры побыстрее стали Они его сейчас немного параллелизуют, а тут ещё generic'и подтянутся. Глядишь, и догонит по скорости.

KP>Одна из составляющих профессионализма — знание своего рабочего инструмента. Язык программирования — один из основных рабочих инструментов. Так что разработчик не осиливший языка не может считаться профессионалом. Вторым сопоставимым по важности элементом будет домeнная область.

Доменная область это главное. И голова и время не бесконечно, чем меньше тратится усилий на инструменты тем лучше.

Здравствуйте, gardener, Вы писали:

G>Доменная область это главное. И голова и время не бесконечно, чем меньше тратится усилий на инструменты тем лучше.

Тут есть один тонкий момент. Разные инструменты за счет разной базовой сложности могут давать различные результаты в плане скорости разработки и простоты поддержки решения.

G>>Доменная область это главное. И голова и время не бесконечно, чем меньше тратится усилий на инструменты тем лучше.

KP>Тут есть один тонкий момент. Разные инструменты за счет разной базовой сложности могут давать различные результаты в плане скорости разработки и простоты поддержки решения.

Ну тут сложно возразить.

Здравствуйте, kaa.python, Вы писали:

KP>грабель C++ (каких, кстати?)
Мы будем вести дискуссию на тему того, есть ли в С++ грабли? Серьезно?

KP>модель памяти Rust, которая те же грабли, но вид с боку.
А шаблоны С++ — те же interface{} в Go, только сбоку. Ну и так далее.

KP>Любой посредственный разработчик не сумевших осилить более сложный и выразительный инструмент превращается в обезьянку способную если не Войну и мир написать, но что-то не сразу падающее точно.
Отлично. Что плохого? И что плохого в том, если хороший разработчик начнет на Go писать?

KP>Правда потом более опытным дядям всяко приходится смотреть на поделие осиливших хотя бы Go и продумывать как это расчищать
А теперь давай подумаем о количестве тех, кто не осилил C++, но пишет на нем. И подумаем, за кем именно опытным дядям будет проще расчищать.

KP>Одна из составляющих профессионализма — знание своего рабочего инструмента. Язык программирования — один из основных рабочих инструментов. Так что разработчик не осиливший языка не может считаться профессионалом. Вторым сопоставимым по важности элементом будет домeнная область.
Основных элементов чем выше по карьерной лестнице, тем больше. Далее, это не противоречит ничему из того, что я сказал. Если человек перестал писать на C++, но начал на Go, то что, он становится от этого менее профессионалом? Конечно нет.

Здравствуйте, kaa.python, Вы писали:

KP>Тут есть один тонкий момент. Разные инструменты за счет разной базовой сложности могут давать различные результаты в плане скорости разработки и простоты поддержки решения.
Согласен, в моем проекте лучший результат — это когда в одних местах вместо C++ — Go, а в других вместо C++ — Rust.

Здравствуйте, iZEN, Вы писали:

ZEN>Go используется примерно в 300 различных проектаов, связанных с разработкой ПО:
ZEN>https://www.freshports.org/lang/go/

Там половина либы для него самого.

Здравствуйте, kaa.python, Вы писали:

KP>С генераторами жить скорее приходится, особого удовольствия это не доставляет.

Нет, ничего, получается довольно изящно, выглядит немногим хуже плюсовых шаблонов. И можно сразу писать generic-тесты:

//go:generate genny -in=queue.go -out=intqueue.go gen "<T>=int"
//go:generate genny -in=queue.go -out=stringqueue.go gen "<T>=string"

import "github.com/cheekybits/genny/generic"

type <T> generic.Type

type <T>Queue []<T>

func New<T>Queue() *<T>Queue {
    return &<T>Queue{}
}

func (q *<T>Queue) Put(val <T>) {
    q = append(q, val)
}

...

func Test<T>Queue(t *testing.T) {
    ...
}

Здесь угловые скобки — юникодные символы с похожим начертанием, можно вместо <T> взять любое другое валидное имя.

Обобщённый код пишется в своём файле (queue.go), после go generate появляется столько дополнительных файлов, сколько было заказано типов. Конечный эффект точно такой же, как от шаблонов, оверхед — три-четыре строки и дополнительный этап трансляции.

Здравствуйте, Kswapd, Вы писали:

K>Нет, ничего, получается довольно изящно, выглядит немногим хуже плюсовых шаблонов. И можно сразу писать generic-тесты:

Да, если нет ноги — протез довольно изящное решение, так как с ним однозначно лучше чем без него. Но вцелом такое решение мне нравится меньше, так как оно не решает главной проблемы — отсутствия обобщенных алгоритмов и коллекций. Собственно мне проблема видится не в том, что нет возможности писать обобщенный код как таковой, а в наполнении стандартной библиотеки.

Здравствуйте, e.thrash, Вы писали:

ET>Казалось, что Python пришел надолго.
ET>Но вот что-то стал часто слышать, что Go вытеснит Питон.
ET>Что думаете?
А вы как думаете?
Пока у go не будет PSF (grants, infrastructure, annual gathering support)
Врядли он кого вытеснит.

Здравствуйте, kaa.python, Вы писали:

KP>Да, но... Ты можешь посадить за проект программиста практически любого уровня и он нахреначит императивные циклы и все будет работать как и ожидалось. Да, громоздко, да, отвратно выглядит, но работает и делает то, что нужно!

Не любого. Многие программисты быстро выгорают от выделенного.

Здравствуйте, Ziaw, Вы писали:

Z>Не любого. Многие программисты быстро выгорают от выделенного.

Да, с тонкой душевной организацией могут и выгореть... но, вернемся к нашим мартышкам! А побоку их выгорание, мартышек много! Тут надо иначе смотреть, в духе "а парит ли кого-то выгорание PHP программиста, или их 5 рублей ведро?". Это я к чему, не надо делать Go своим главным языком, а то можно плохо кончить.

Здравствуйте, kaa.python, Вы писали:

KP>Да, с тонкой душевной организацией могут и выгореть... но, вернемся к нашим мартышкам! А побоку их выгорание, мартышек много! Тут надо иначе смотреть, в духе "а парит ли кого-то выгорание PHP программиста, или их 5 рублей ведро?". Это я к чему, не надо делать Go своим главным языком, а то можно плохо кончить.

Если про мартышек, то все верно. Только не надо их называть программистами любого уровня.

ET>Что думаете?
А кто это говорит, и какие доводы приводит?

Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, kaa.python, Вы писали:

KP>>Шумиха вокруг Go вызвана тем, что он позволяет использовать откровенных жопоруков, коих в огромных корпорациях очень много. Так что я бы сильно не радовался соскочив с C++ на Go, так как Go — язык для мартышек и по насыщению рынка их ждёт судьба PHP программистов.

S> И наоборот, необязательно привлекать гуру к разработке какого-нибудь простейшего GUI-я, только вследстсвии того, что этот GUI пишется на C++, его на Qt и мартышки запилят не хуже любого гуру. На C++ тоже можно писать так, что любая мартышка справится, банально используя (задав это жёстко принятыми в проекте правилами кодинга) только его самое простое подмножество. Более того, подавляющее большинство C++ проектов именно так и пишется, очень редко где в промышленной разработке софта на C++ юзаются его "сложные пласты", почти везде тот самый пресловутый Cи c классами.

Согласен что знание языка не значит умение решить конкретную задачу.

Но про Qt/C++ не согласен, опыт показывает что это не так.
Опыт показывает, что человек освоивший "безопасный" язык с GC,
на C++ может написать такое:

void f(const Foo &);

auto foo = new Foo
f(*foo);

Или передать ссылку на локальный объект
в другой поток и сделать "return" из функции.

В других языках это не было бы ошибкой.