×

Кого проще переквалифицировать на Golang разработчика?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Привет сообщество.

Интересно ваше мнение, кого проще переквалифицировать на Golang разработчика:

1) С/С++
2) Python
3) Perl
5) того, у кого мозги лучше работают
6) никого
7) Разносчиков пиццы (Anton Kononenko)
8) Ниасиливших скалу (minodvesP Vasya)
9) Nodejs (Mikhail Ulyanchenko)
10) Да кого угодно: это даже не язык. (Yuriy Pitometsu)
11) Джава | swift (Oksana Chuiko)
12) Служителей и последователей культов (Alexander Kureniov and Vladislav Trotsenko)
13) Бабушку (Roman Trofimov)
..n) Ваш вариант

Вроде как Go ванговали на замену C++, но, судя по рынку, на Go пытаются перейти с Python или PHP.

P.S. Если чё с Валялкиным не аффилированн

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Я бы скорее задал вопрос «зачем». Кто сможет на него основательно ответить, тот и сможет перейти на go с легкостью, так как всем ясно что язык — лишь инструмент, дело в фундаментальных скилах разработчика.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Похоже тема потеряла актуальность и все кто хотел/мог уже перелезли на Go

Всем привет.
Не прошло и полгода — мы готовы перейти от бла-бла-бла к реализации.
Решили начать с С/С++ т.к. сети и много низкоуровневого, да и kernel drivers на С++ там есть — jobs.dou.ua/...​agilites/vacancies/53791

Если модеры почтут за спам не обижусь, вычитывать все правила лень :)

Забыл добавить:
1. Два бизнеса смерджились в один и теперь выпускают и железяки и SDN
2. Текущая команда: 1хSenior, 1xMiddle/Senior, 1хJunior

Т.е. ищем 4-го ГО.

Продолжу диалог сам с собой
Появилась менее низкоуровневая позиция, тут уж точно переучиться не проблема jobs.dou.ua/...​agilites/vacancies/54467

а где блек джек и блудницы , что то я не увидел их в описании рабочего места!?

И тебе привет )
Петросянь сколько хочешь, а мы себе мозг выели, пока приблизились к тому, что народ хочет видеть.
Можешь тут почитать содержание предыдущих серий — dou.ua/forums/topic/21741

Проще никого не переквалифицировать, т.к. все желающие уже давно самостоятельно переквалифицировались в go-программистов и вспоминают о предыдущих языках программирования только в страшных снах.

Мне от цікаво, скільки тобі доплачують вороги здорового глузду? )))

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

главное что бы не от воображаемых друзей

Да в принципе можно любого разработчика, который знает основы программирования и имеет опыт разработки на любом из языков.
Сам сейчас практикуюсь в GO, сложного ничего нет. Главное желание.

Да, если на доу открыть раздел работа, подраздела GO я вообще не вижу. Проскакивало пару вакансий, но как то кисло пока. Кто-то в продакшене пишет большие проекты ? Я пока пару скриптов сделал, дальше дело не пошло, все ниши заняты python(куча скриптов в системе), java(всегда была), scala(типа со спарком). Куда и зачем заказчику еще один язык в системе, вот вопрос.

если на доу открыть раздел работа, подраздела GO я вообще не вижу.
открий ДОУ за 1.1.2020, раскажи шо видиш

в тебе стара версiя ДОУ, без Го-енджiна

А пока я на java/scala попишу можна? а то как то кушать хочется

На java/scala пишешь и до сих пор накушаться не можешь? Сходи к гастроэнтерлогу.

scala(типа со спарком)
замените эту скалу со спарком на go + clickhouse — получите минимум на порядок более простое и производительное решение.
Yandex ClickHouse is an absolute winner in this benchmark: it shows both better performance (>10x) and better compression than
MariaDB ColumnStore and Apache Spark. If you are looking for the best performance and compression, ClickHouse looks very good.
— подробности тут — www.percona.com/…​ickhouse-vs-apache-spark

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

Ну значит, просто замените на go, не мудрствуя лукаво.

ну гон, какие нафиг «селекты/апдейты», авторы вообще упоротые на всю голову. Как мне использовать

go + clickhouse
для повседневных задач типа
spark.apache.org/…​test/mllib-ensembles.html ?
ну гон, какие нафиг «селекты/апдейты»
Согласен — clickhouse не поддерживает update и delete.
Да, если на доу открыть раздел работа, подраздела GO я вообще не вижу.

На ДОУ подраздел называется Golang:
jobs.dou.ua/…​acancies/?category=Golang

Вот же неучи, заходят на DOU, и не знают, как называется самый главный раздел.

дофига пишут. И большие проекты тоже, но не в украине

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

Там ищут разработчиков Go! а это ненастоящий Go, не ведитесь на фейки и подделки. Возможно, и это скорее всего, авторы объявления ошибочно перепутали нужный им язык программирования с оригиналом. Хорошо, что мы вовремя заметили несоответствие, и сообщество настоящих Go-программистов всегда готово любезно объяснить, какой язык программирования им нужен на самом деле.

Это рекрутеры опечатались. Там обычный golang.

Это рекрутеры опечатались. Там обычный golang.
Фух, ну слава аллаху, прям как камень с груди спал. Вот так вот из-за каких-то досадных опечаток и появляются проекты на других языках.

Ну или прийдет на собес гроссмейстер по игре Го. Тоже ничего)

С+±ника с опытом Python.

В свое время ходило упорное утверждение «го — это язык для пхпешников не осиливших ноду»,
так что скорее всего их родимых, пехепешников.

того кто хочет — остальное вторично.
я уже неоднократно ванговал, что go не взлетит. единственный, как по мне, шанс — это если Гугл принудительно переведет Android разработку на него.

Go уже взлетел, пора уже признать очевидное. Вон, на сегодняшний день уже scala уделал, потом и до java доберётся.

А что в твоём понимании доберётся?
Что это значит? Что через икс лет проектов на go для энтепрайза будет больше чем на java?

Какая разница, сколько через икс лет будет старых проектов на java. Вон на Коболе больше всего строк написали, кто-то из присутствующих их читает? Проекты живут, пока находятся в активной стадии разработки, ну может ещё некоторое время после. А писать код проще и продуктивнее на Go, к тому же у него самый малый порог вхождения, и соответственно это более развитое звено эволюции. А прибегая к аллегории с эволюцией, динозавры вымерли вовсе не от недостатка силы и массы.

Разница как раз принципиальная:) я о своём будущем думаю:)

Лёха, в долине(и недолине) на любой технологии есть интересные проекты
Главное в Дойче Банк больше не суйся и будет тебе счатье

Главное в Дойче Банк
Главное в инвест банки не соваться- и будут интересные проекты

Бывают и у них интересные проекты :) но крайне редко. Но в остальном я согласен с тобой и Алёшей Пешковым , перефразируя которого могу сказать, что : «Человек создаёт для счастья, а не для работы в банковской структуре»

Я же смотрю вперёд:) что будет через 10-15-20 лет:) так то энтепрайза на наш век хватит и на джаве, но блин, а вдруг жажда приключений будет жить во мне дольше среднестатистических показателей :)

Через 20лет ты будешь олдфартом, ловить форельку где-нить в горном озере возле своего шалле и не париться о технологиях )

Я то собственно и сейчас стараюсь не париться , но так как это непосредственно связано с моей востребованностью и ценой на рынке труда , то таки нет нет да и думаю об этом и стараюсь трепыхаться в этом направлении:)
А домик на озере , я думаю и раньше будет:) так что жди приглашения на рыбалку :)

Java forever :)))

А писать код проще и продуктивнее на Go
на бейсике еще проще.
к тому же у него самый малый порог вхождения
у PHP еще меньше :)
потом и до java доберётся.
так как Go урезан, о чем в любом обсуждении упоминается, то никогда он не сможет вытеснить более универсальные и богатые ЯП с областей где надо описывать domain.

чтобы он мог вытеснить Java, C#, PHP, Ruby, ... он должен стать таким же по мощности и выразительности. А авторы как раз сделали обратное — урезали ее.

на сегодняшний день уже scala уделал,
не пример, потому что Scala и без Go не очень летала.
сделали обратное — урезали ее
бритвой Оками отрiзали нэпотрiб

Бо в клаудах виникли потреби швидко писати надійні мікроінстанси. І виявилось що для цього Java та Python мають недоліки. Як мови так і іх транслятори. Node.js виявилась кращою. Але теж не зовсім тe.

Я сейчас команду php-шников на Java пересаживаю для написания микросервисов на JavaScript (так как они уже знают JavaScript) И всё это на vert.x

Пока полёт нормальный.

да vert.x, это прямая альтернатива Ноде в мире JVM.

Пока полёт нормальный.
почему б и нет, раз дополили нормальную интеграцию с возможностями поддержки скриптовых языков на JVM.

я как-то видел проектик по транслятору php под JVM. Но, сыроват. а так, под vert.x можно было бы и на php писать :)

vert.x, это прямая альтернатива Ноде
О да. знатная полит война между отдельными групировками была в компании: Node vs vert.x
Больше в таком не хочу участвовать.

А вообще vert.x отличный фрейворк
Можно писать на: Java, JavaScript, Groovy, Ruby, Python, Scala, Clojure and Ceylon

and Ceylon
кстати, итнтересно, как с этим языком обстоят дела (если в курсе конечно)? он где-то применячется в продакшене, или он больше экспериментально-исследовательский? (вроде его в Rat Hat разрабатывали — серъезная ж контора типа). Просто интересно.
Больше в таком не хочу участвовать.
только что отмитинговал с — а давайте все напишем на Meteor.js!

тяжело с оптимистами... что не скажешь — так и это напишем, делов то!

у PHP еще меньше :)
думаю у бейсика еще меньше, чем у пхп)
код проще и продуктивнее на Go, к тому же у него самый малый порог вхождения,
Это фишка php.

Ничего против php- но думаю go ждет нечто подобное php- тоны пришедших в айти после прочтения книжек «go за 2 дня».
Жуткий демпинг среди спецов по го.
Хотя на фрилансе- будет много заказов- наравне в php.

Жуткий демпинг среди спецов по го.
Демпинг не зависит от средств разработки. После создания экскаватора вместо лопаты, демпинга специалистов не произошло.

Сравнение неверно. В экскаватор порог вхождения намного выше, чем в лопату

То что взлетел понятно, я бы сказал, что уже и приземлился. Есть и более молодые и переспективные языки типа Rust

Хороший инструмент, освоить может любой. Даже без опыта. С опытом хватит недели двух. Но как то немного вакансий на нем. Да и нужно помнить, что не стоит пихать один и тот же язык во все задачи. Профи должен знать чотя бы 5 языков под разные задачи.

да чего уж 5, лучше 10, чтобы быть профи^2

Ну можно посчитать. В школе/универе наверняка изучали Basic и Pascal/Delphi в самом начале. Далее. Ассемблер тоже наверняка все учили. C++, C#, Java тоже наверняка большинство знают, ибо мейнстрим. Ну и php тоже. js не знать — это тоже только если принципиально не учить. Ну а Go даже особо учить не нужно, достаточно описание посмотреть, и так всё ясно. Так что 8-10 языков наберётся запросто. Не считая всякие там SQL и прочие под базы данных.

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

На Go хорошо переходят те, кто не потратил 10 лет жизни на то, чтобы освоить один язык до приемлимого уровня. Например, С+±сники, которые, сначала 5 лет в универе, потом 5 лет на работе учились писать сервисы, которые не текут — Go ненавидят, а С+±сники, которые понимали проблемы языка, легко перепрыгивают этот печальный этап в их карьере и переходят на Go.
Также, из опыта, легко переходят рубисты, питонисты, народ с nodejs и PHP — отчасти потому, что Go «чувствуется» как динамически-типизированный язык, но при этом даёт все плюшки статической типизации.

Например, С+±сники, которые, сначала 5 лет в универе, потом 5 лет на работе учились писать сервисы, которые не текут — Go ненавидят
Абсолютное заблуждение. Вот я например писал раньше на C++ сервер и прочие проекты, с 2006 года. Еслиб лет 8 назад был бы Go на том уровне, что сейчас, однозначно сервер бы писал на нём.

Это не заблуждение, а обобщение. То, что ваш случай не подпадает под «большинство», не означает заблуждение (cherry-picking fallacy). Я могу, конечно, заблуждаться в своём обобщении, но это то что я наблюдал и продолжаю наблюдать у джавистов и С++сников. :) Так-то я и сам с С++ перепрыгнул с радостью.

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

Вот честное слово, каждый трэд про Go на Доу превращается в какое-то нытье Java/.NET разработчиков, которые ни разу не писали на Go, но пытаються его обосрать.

Народ, не волнуйтесь, работу у вас никто не заберет. Да, наверняка, Go отхватит гигантскую долю рынка микросервисов (на Node.js, Python, PHP, Ruby и даже C) и всевозможных Cloud Native приложений. Просто потому что он отлично для этого подходит. Но энтерпрайз все-равно никуда не денется.

У языка есть свои минусы, но поставленные перед ним задачи он выполняет на отлично. А я считаю, что задачи у него всего две: быстро работать и сделать максимально невозможными «выстрелы себе в ногу» — ты либо пишешь код «Go-way», так, как задумали создатели языка, либо у тебя получается каша.

Вот опять тоже самое. Такое может писать только человек, который с Go не работал.
«Go-way» никак никого ни в какой функцональности не ограничивает, а только «настаивает» на том, как организовать код, чтобы он был очень гибким и легко тестировался.

Полностью согласен. Вся суть Go, в том что очень много архитектурных решений уже придумано за вас и язык заточен под решение конкретных задач с конкетными подходами (= медленее накапливается говнокод).

Это инструмент. Для определенной сферы применения. И забивание гвоздей микроскопом всегда видет только к говнокоду.

Так а зачем вы натягиваете то, что не натигивается? Это не проблема языка, а проблема выбора технологии.

Лично я дле себя выбрал Go, как язык для REST/RPC/консольных утилит. Это 90% моих задач и Go справляется отлично. Инструмент для работы.

И все же, когда у говнокодера нет доступа к шаблонам, виртуальному наследованию и эксэпшенам, жизнь становится ощутимо легче.

картошку можно и топором чистить.
так топор не дають, дають ножа,
но с кривими руками можна й ножом намудачить
что программист, это не тот, кто тупо веслает на галере, а тот, кто нечеткие и противоречивые хотелки заказчика переводит в язык, понятный компьютеру.
це було 20 рокiв тому, та лишилося в маленьких овноконторах.
зараз маем кучу прокладок для формалiзацii завдання кодеру

Да не, человек может, ярко выраженные случаи называется шизофрения, но чисто технически, близкие к идеальным параллельным вычислениям только квантовые компьютеры, которые почему не распространены =)

Сложность в том что как у человека, так и у машины это где то упирается в асинхронную, но одно поточную систему ввода-вывода.

Но по сути это и есть то о чем многие тут писали разными словами.

Для меня многопоточный код писать — непросто (причем чтобы он не ушел в дедлок и не тормозил больше, чем однопоточный и хотя бы дал 60-70% роста производительности от количества ядер).
На Go многопоточный код пишется легко, так чтобы он не уходил в дидлок. Тормоза зависят главным образом от того, как происходит синхронизация между потоками. Если она минимальна, то в среднем по палате на 12 ядрах код выполняется в 4 раза быстрее, чем только на одном.

Если в каждом потоке запускать независимые длительные вычисления, сведя общение между потоками до минимума, то на 12 ядрах будет работать в 12 раз быстрее, чем на одном (если не упремся в пропускную способность памяти). В этой области достаточно задач. Например, всякие числодробилки, кодеки, архиваторы и шифровальщики.

Ой, ну толстые не дерущиеся за ресурсы потоки — это идеальный случай, тут и на баше летать будет.

Виртуальное наследование не использовал ни разу за более, чем 20 лет. Но, в каких-то задачах оно может быть сильно удобно.
Надо же, а я думал, что это только мне одному виртуальное наследование — как собаке пятая нога. А то коллеги на собеседованиях о нём зачем-то подробно расспрашивают.

да прям мейнстрим з ним, шо не собес, так вопрос

Мы не спрашивали, многие сыпятся на банальном вопросе как не потерять ресурс.

как не потерять ресурс.
где потерять, какой ресурс?

A *a = new A();
Далее лесенка if-ов и возврат из функции, в некоторых ветках с потерей памяти. Как пофиксить?

goto label_delete;
...
label_free: delete ...
p.s.
1. what about RAII?
2. wtat about std::auto_ptr?
3. what other ways to shut leg yourself in C++?

Типа того, подобных вещей хватает и без залезания в глубокие теории

так как, зачот, интэрву прашол?

Еще по деревьям походить с рекурсией и без (балансировать не надо) и считай что да

в 3.14ду деревья, хай мавпи лазять по деревам,
це уже не С++, a кампутер-саенз

Не прошел, т.к. ресурс нужно освобождать так:

A *a = new A();
// все return'ы, break'и, if'ы и for'ы лесенкой
// спрятать внутри useA
useA(a);
delete a;

Исключение внутри useA и привет

Если на плюсах, то можно и try catch.

Проще в scoped_ptr завернуть

Надеюсь, теперь понятно, почему exceptions — зло.

По той же логике аккумуляторы тоже зло, могут на голову упасть и током убить.
Но есть способы сильно облегчить себе жизнь

В Go нет ни exceptions, ни аккумуляторов, безопаснее Go нет ничего.

Надо сохранить инстанс A и привет

Ну и через auto_ptr будет на одно строчку короче

Через auto_ptr будет undefined behavior в 97.5% случаев. Пора вылезать из танка — auto_ptr давно признан худшей фичей c++ и забанен в последних стандартах c++.

unique_ptr

когда у говнокодера нет доступа к шаблонам, виртуальному наследованию и эксэпшенам
... он рисует тонну копипаста вместо шаблонов (и ошибается при замене буковок), изобретает свою схему ОО (и наверняка с ошибками и недочетами, которые вылезут позже) и рисует лесенки if(error) return ERROR; в которых забудет сделать освобождение ресурсов

Неужели подобный луддизм оправдан?

рисует лесенки if(error) return ERROR; в которых забудет сделать освобождение ресурсов

Здравствуйте, старые добрые С грабли

В некоторых случаях очень полезная вещь. Я пользовался. /* мне начхать на ваше мнение */

Также не нужно и выделять слюну как собака Павлова при виде лампочки.

Дедушку и его собачек не трогате!

Сколько собачек садист загубил. А слухи ходят что еще и на беспризорниках практиковался.

В старопрежни времена когда один д.т.н. стал писать свои расчетки на С после Бейсика (не квик-, а того, неструктурированного, хардкорного), его код выглядел примерно так:

if (ryba == seledka) goto a;
integral = rybij_integral(nachalo, konec);
goto b;
a: integral = seledochnyj_integral(nachalo, konec);
b: proverka_integrala(integral);

При этом расчетка ни с какими рыбами связана не была.

Вообще-то ни того ни того. Потому что одиночный оператор ставился в логическом IF в обоих. В Фортране IV логический IF был уже в полный рост.
Так что тут привычки какие-то ещё более хардкорные.

Да. После фортрана. У басика строки нумеруются.

Мой руководитель диплома так писал. Я ЭТО оформил как функцию и написал визуализацию. Я защитил диплом а потом мой руководитель умер от рака. Конечно это не связано, но все же корреляция может быть.

Если для выполнения операции надо сделать кучу подготовительных действий, на любой из стадий может возникнуть ошибка, и надо корректно все откатить, то в С goto может быть меньшим злом

Да. Классический пример — модуль в ядре линуха.

Об адепты секты «сложность ради сложности» повылазили :)

он рисует тонну копипаста вместо шаблонов (и ошибается при замене буковок),
1. Необходимость делать ручками отбивает охоту шаблонизировать все и вся.
2. Явный мистайп легко грепается и открыт ревьюверу.
изобретает свою схему ОО
Не понял. Объектно-ориентированности? Так это вроде не догма прибытая гвоздями к С++
рисует лесенки if(error) return ERROR;
Вам никто не объяснял, что такое эксепшены и чем они отличаются от обычного кода возврата?
Нет конечно, а то б не заменяли эксепшенами обычный switch-case.

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

поиск в докере по if err != nil
github.com/…​q=err != nil&type=&utf8=

Красотища неимоверная

Проблема-то в чем? В отсуствии
 template<typename Key, typename Value, class EqualTo, class Alloc> typename ACE_Array_Map<Key, Value, EqualTo, Alloc>::const_iterator ACE_Array_Map<Key, Value, EqualTo, Alloc>::find (   typename ACE_Array_Map<Key, Value, EqualTo, Alloc>::key_type const & k) const {
?

в вызывающем коде будет col.find(). Problem?

В лапше.
Но забавно, как разговор о преимуществах Го (ну и недостатках, куда ж без них) сводится к лютому хейтерству С++. Прям глубокая психологическая травма на всю жизнь, С++ плохой, пойду поплачу на форумах.

Скорее наоборот. В топики про Rust/Go приходят адепты секты запутаистов и говорят, что не взлетит.
А С++, был хороший язык, пока из рук производственников не попал в руки теоретиков.

Да прям.
Но то, что каждый if увеличивает число комбинаций вдвое, никто не отменял. Ну это если абстрагироваться от хайпа и чутка посмотреть реально. А так и флаг в руки.

Хайп он вокруг 11/14/17/20.
А Go тихонечко живет в своей тематической экосистеме, но тем не менее вызывает аццкую попоболь у многих.

А, ну-ну.
«И Карфаген должен быть разрушен», ага

Вам никто не объяснял, что такое эксепшены и чем они отличаются от обычного кода возврата?

А это повылазил адепт секты «найдём у полезного механизма наиболее кривое применение и будем всем его совать прямо в лицо».

А шо не? Поприучались на любой отрицательный результат бросать эксепшен.
Это же не вдумчивый разбор «а что должно быть по логике если результат отрицательный?»

Поприучались на любой отрицательный результат бросать эксепшен.

Вот честно — не видел такого в массе. Или имеется в виду подход «throw, если connect к HTTP серверу не состоялся»? Тогда там сам коннект достаточно тяжёлый, чтобы на цену исключения не сильно обращать внимания. И то — в питоновском socket есть connect, а есть connect_ex (который возвращает код ошибки).

Это же не вдумчивый разбор «а что должно быть по логике если результат отрицательный?»

Так встречный вопрос — а почему этот вдумчивый разбор должен быть на каждом вызове в цепочке?

Или имеется в виду подход «throw, если connect к HTTP серверу не состоялся»?
По большому счету это должно быть под капотом у библиотеки, и возвращать код на каком месте свалилось. Стейт-машина — ничего сложного.
И то — в питоновском socket есть connect, а есть connect_ex (который возвращает код ошибки).
В Питоне есть сборщик мусора, да и сам язык не позиционируется, как сколько-нибудь производительный.
Так встречный вопрос — а почему этот вдумчивый разбор должен быть на каждом вызове в цепочке?
А не в этом ли заключается профессия программиста?
Эксепшен существует для случаев, когда ситуация действительно выходит из под контроля — хардвар, удаленное оборудование, нехватка памяти итп.
Стейт-машина — ничего сложного.

И нахрена нужна та машина, когда её не собираешься возобновлять? А трансляция состояний этой машины во что-то более внятное — будет той ещё проблемой.

В Питоне есть сборщик мусора, да и сам язык не позиционируется, как сколько-нибудь производительный.

1. И тем не менее это сделали.
2. Не позиционируется, но многие модные кривули даже обгоняет.

А не в этом ли заключается профессия программиста?

Тратить себя на проходную ерунду?

ксепшен существует для случаев, когда ситуация действительно выходит из под контроля

Не вижу никаких оснований для такого утверждения.

И нахрена нужна та машина, когда её не собираешься возобновлять?
А вдруг собираюсь?
В Питоне есть сборщик мусора, да и сам язык не позиционируется, как сколько-нибудь производительный.
1. И тем не менее это сделали.
Еще раз — сборщик мусора, скорость разработки в ущерб производительности.
2. Не позиционируется, но многие модные кривули даже обгоняет.
Какие именно?
Тратить себя на проходную ерунду?
На хорошо сделанные программы.
ксепшен существует для случаев, когда ситуация действительно выходит из под контроля
Не вижу никаких оснований для такого утверждения.
What Is an Exception?
The term exception is shorthand for the phrase «exceptional event.»
Definition: An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program’s instructions.
What Is an Exception?
The term exception is shorthand for the phrase «exceptional event.»
Definition: An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program’s instructions.
Чем event от normal flow of the program’s instructions отличается рассказывать?
А вдруг собираюсь?

Каким образом?

Еще раз — сборщик мусора, скорость разработки в ущерб производительности.

Ещё раз: и что с того? В Go тоже сборщик. А производительность, если её совсем радикально не ломать, даже неплохая получается.

Какие именно?

Где-то рядом недавно даже с Go сравнивали. Идёт нос в нос.

На хорошо сделанные программы.

Это с проверкой кода возврата на каждом чихе? Это не может быть «хорошо сделанным».

Definition: An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program’s instructions.

1. Откуда дровишки?
2. Normal flow это когда из return переходим в непосредственного предка. И зачем туда возвращаться, если лучше и дешевле обойти?

Чем event от normal flow of the program’s instructions отличается рассказывать?

Рассказывать. Только без прогрузки собственными тараканами типа «ой, exception, сливай свет и туши воду».

Не собираюсь соревноваться в длине простыней.
Вам сюда:
google.github.io/…​/cppguide.html#Exceptions

Что гугловские правила возникли тогда, когда C++ только вылезал из пелёнок — знает даже ленивый. Но Вы его переплюнули.

И уже тогда надо было ограничивать полет мысли пейсателей.
А с тех пор в стандарт еще изрядно поднасрали.

И уже тогда надо было ограничивать полет мысли пейсателей.

Зачем? Чтобы получить горбатого уродца? Таких и так полно — как предмет этой темы, например.

А с тех пор в стандарт еще изрядно поднасрали.

C++11 наконец стал нормальным языком — логически замкнутым по основным фичам — и с тех пор развитие идёт безусловно грамотно и разумно.

Опыт говорит обратное — практически все успешные компании имеет документ аналогичный гугловскому. Иначе — швах.

Опыт говорит обратное — практически все успешные компании имеет документ аналогичный гугловскому.

Ссылки в студию.

«У нас есть тааакие стандарты, но мы их вам не покажем.» :)
Нет, в данном случае — не слышали и не услышим.

Трудно догадаться, что подобные документы в публичный доступ не выкладываются? Или просто не приходилось работать на действительно серьезных людей?
Вы уже второй день капитально передергиваете, а значит сами понимаете, что глубоко неправы.

Я не про код. Я про внутреннюю дизайн-документацию.
И кстати где она есть — код несколько затянут, зато легко читаем и модифицируем.

Трудно догадаться, что подобные документы в публичный доступ не выкладываются?

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

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

Или просто не приходилось работать на действительно серьезных людей?

Гугл несерьёзен, раз опубликовал свои? Тогда почему Вы ссылаетесь на его стандарты? ;))

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

У меня точно такое же мнение в Вашу сторону. Эмоции, вкусовщина, передёрги, отсылки к авторитету, при этом полный отказ разбирать явление по сути и проявлять аккуратность и взвешенность в оценках — уже 100% признаки того, кто юлит и пытается вывернуться любым образом, лишь бы не признать, что спорол чушь.

Потому что стандарт кодирования это не тот документ, который действительно полезно скрывать от публичного доступа.
Тем не менее скрывают. Выкладывают только безусловные законодатели мод вроде Гугла и МС-а, чтобы собсно эти моды и создавать.
в публичной дискуссии ссылаться на закрытый документ, неизвестно, чей, и существующий ли — как минимум моветон.
Подавляющее большинство присутсвующих здесь так или иначе работает(ло) на крупные западные корпорации, пользовались подобными документами и знают о чем идет речь. Если у вас в анамнезе только квартирные шарашки вроде вашей нынешней — не мои проблемы.
Если у вас в анамнезе только квартирные шарашки вроде вашей нынешней — не мои проблемы.

У меня много чего «в анамнезе», но рассказывать тому, кто доказал неспособность это понимать и конструктивно обсуждать, не собираюсь. Я из этой ветки получил всё, что хотел.

Потому что стандарт кодирования это не тот документ, который действительно полезно скрывать от публичного доступа
жартуеш?
жартуеш?

Аж ніяк. Його можуть не афішувати, або в публічній версії виключити щось на зразок назв окремих компонентів, але головне в стандарті не потребує ніякого закриття. Ну, зрозуміло, якщо не соромно (типу, «ми ще повинні зберігати сумістність з компілятором від 1959 року, тому всі імена мають бути до 5 букв»).
(Додам — є випадки, коли стандарт, наприклад, копіює той же MISRA і тому підпадає під обмеження джерела. Їх я не розглядаю, до того ж завжди можна зробити вижимку.)

зберігати сумістність з компілятором від 1959 року, тому всі імена мають бути до 5 букв
представ, саме так, бо залiзо та компiлятори з того часу не обнувлявилася, а кот тре сапортити та ба — розвивати фiчi + до того граблi, на якi не хочемо щоб наступали в 100500 раз нуби, так що кодынг рулз = ноухау, закрите НДА
так що кодынг рулз = ноухау, закрите НДА

Та яке там до біса ноухау, коли ті ж рецепти (і ще і краще викладені) на кожному розі в інтернеті від всяких дідьків-бобів та кентів-басмачів. Лол.

ладно, якщо так все просто, виклади менi Ericsson C coding rules

Не викладу. Тому що як конкретна контора змішала все знайдене в персональний борщ — неможливо передбачити. Але цінність цього борща існує тільки для неї.

(Хоча деякі правила можна було б зрозуміти по коду Erlang. Як на мене, вони не найкращі. Наприклад, я зараз впевнений, що {} навколо тіл if, while... обовʼязкові, навіть якщо тіло — один простий оператор.)

Наприклад, я зараз впевнений, що {} навколо тіл if, while... обовʼязкові, навіть якщо тіло — один простий оператор.)

Тогда переходите на Go — там код без скобочек вокруг тел if и for не компилируется.

Нет уж, лучше вы к нам.

Вот вот. Корректно завершить работу сохраняя целостность данных, а не бросать по каждому ненайденному файлу.

Ну да, ну да, где бы был С++, если бы не позволял расчесывать распухшее эго на собеседованиях.

Помню, как на С++ тратил время на бессмысленные размышления «как правильно спроектировать конструктор копирования, оператор присваивания и operator new, чтобы результирующий код был оптимальным и элегантным?» (в С++ 11 это все «упростили» и добавили новые time killer’ы С++ программистов — конструктор с оператором перемещения). Но почему-то код обычно получался сложным для понимания, а элегантность ломалась при первой же попытке его расширения под новые нужды.

К счастью, потом появился Go, где все просто как грабли. В Go нет всех этих time killer’ов, ломающих продуктивность программистов — конструкторов, перегрузки операторов и функций, кастомных аллокаторов памяти, наследования, неявных преобразований типов и template’ов. Поэтому программисты на Go продуктивнее программистов на C++ в 10 раз.

Если их нет «к счастью», значит в С++ ты с этим возился от чесания шаловливых ручек, а не потому что надо было.

Та невже? А с чего начинают зубрилкины на первом же попавшемся плюсовом собеседовании?
Кстати, чисто родовая черта плюсовиков -вменяемые люди уже давно разбежались по другим технологиям.

Меряем продуктивность собеседованиями? Ну даже так, если на написание конструкторов тратится 90% времени, как у Валялкина, то гнать из С++ сцаными тряпками, последствий будет меньше.
Многие разбежались, но вменяемыми стали не все.

Многие разбежались, но вменяемыми стали не все.
Правильнее так: вменяемые разбежались с C++, остались любители преодолевать сложности на ровном месте и прочие ментальные онанисты :)

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

быдлокодер, случайно забредший в С++, не асилил
я роблю камiнг-уат, шо дальшэ?

Значит таки есть шанс на адекватность

Запостите сюда свои результаты прохождения следующих тестов по С++, в составлении которых участвовал я, python-быдлокодер:
www.quizful.net/test/cpp_basic
www.quizful.net/test/cpp_mid
www.quizful.net/test/cpp_expert

После этого решим, кто ниасилил С++.

comments:
===
Я работаю в Embarcadero, это та фирма что делает разные инструменты и среды для работы с базами данных. также она купила в свое время Borland. Т.е. мы также делаем все продукты которые были раннее под маркой Borland.
На C++ работаю лет 17 примерно. Тест на основы С++ я не прошел), ответил только на 12 вопросов из 20) но буду еще проходить и конечно пройду. Также как и остальные тесты. Хотя меня больше интересуют тесты на алгоритмы.
Понятно всем что эти тесты не отражают реальную силу программиста. Об этом можно долго говорить) Хоть они и очень полезны НО) В свое время я сам нанимал разных молодых людей (с небольшим опытом или без) на работу в разных фирмах. Некоторые успешно проходили тесты где-то среднего основного уровня и были приняты. А потом уволены руководством — так кто-то через месяц, кто-то через пол-года.. после некоторых я сам разгребал код ))))
Они не могли справится с реальными большими проектами в условиях огран. времени.. Ибо не было ОПЫТА.

===

Боже, я наконец прошел этот конченный тест. Напомнило это все рубрику Криса Касперски в журнале хаккер, где он публиковал всякие извращения языка. Только тут по этим извращениям написали целый тест.
===

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

Мои конструкторы от этого в монстров не превратились, а копия в большинстве случаев устраивала стандартная

Расскажите, как вы с помощью стандартных конструкторов и операторов копирования управляли владением и временем жизни ресурсов, инкапсулированных в класс?

Интересно, почему в С++ коде гугла на каждом шагу встречается магическая строчка DISALLOW_COPY_AND_ASSIGN?

В google C++ style guide есть следующий пункт:

Support copying and/or moving if these operations are clear and meaningful for your type. Otherwise, disable the implicitly generated special functions that perform copies and moves.

Пункт вполне правильный. Если не clear и не meaningful — запрети и не морочь голову ни себе, ни людям.

Давайте пример кода чтоли с комментарием зачем вам в нем кровь из носу нужны copy и assign.

Давайте пример кода чтоли с комментарием зачем вам в нем кровь из носу нужны copy и assign.

Любой тип, который необходимо засунуть в STL контейнер, должен реализовать конструктор копирования и, насколько я помню, оператор присваивания.

Должен. Если не реализован, генерится компилятором по умолчанию.

Самый тупой пример:

struct complex_vector_2 {
	std::complex<double> a, b;
};

struct dummy_complex {
	double imag, real;
};

struct dummy_complex_vector_2 {
	dummy_complex a;
	dummy_complex b;
};

int main()
{
	complex_vector_2 orig = { {1, 2}, {3 ,4} };
	complex_vector_2 copy(orig);
	complex_vector_2 assign = orig;

	dummy_complex_vector_2 orig2 = { { 5, 6 }, {7, 8} };
	dummy_complex_vector_2 copy2(orig2);
	dummy_complex_vector_2 assign2 = orig2;

    return 0;
}

Компилится, работает, в вектор засовывается.

Расскажите, как вы с помощью стандартных конструкторов копирования операторов присваивания управляли владением и временем жизни ресурсов, инкапсулированных в класс?

Точнее? Что должно происходить с мемберами? В примере выше самый простой случай.

Любой тип, который необходимо засунуть в STL контейнер, должен реализовать конструктор копирования и, насколько я помню, оператор присваивания.
На этот вопрос я тебе ответ дал.

Для более хитрых случаев мембер можно завернуть в одну их разновидностей смарт пойнтеров, даже в те, которые в стандарт не вошли. weak/unique/shared или нестандартный cloned_ptr — делай что хочешь.

Если ты хочешь в конструкторе сокет открывать или что подобное, то это желание странного.

Забыл еще про exceptions — благодаря их наличию в С++ приходилось тратить уйму времени и сил, чтобы спроектировать элегантный exception-safe код. Обычно получалось либо элегантно, либо exception-safe, но не одновременно. Поэтому 99% программ на C++ содержат миллион неявных косяков, связанных с exception safety.

Поэтому 99% программ на C++ содержат миллион неявных косяков, связанных с exception safety.
В CPP вместо того, чтобы бросить эксепшон, в куче мест просто сделали undefined behaviour ради ненужной совместимости с си, которую все равно потом похерили.

undefined behavior — не ради совместимости с Си, а ради возможности заоптимизировать код по самые помидоры. Без него С++ был бы тормозом. blog.llvm.org/…​ogrammer-should-know.html .

... он рисует тонну копипаста вместо шаблонов (и ошибается при замене буковок), изобретает свою схему ОО (и наверняка с ошибками и недочетами, которые вылезут позже) и рисует лесенки if(error) return ERROR; в которых забудет сделать освобождение ресурсов
Неужели подобный луддизм оправдан?
Ну во-первых, сразу после открытия ресурсов в Go пишется конструкция типа defer resorce.close(), что означает закрытие ресурса при любом выходе из функции. Так что дальше можно писать if(error) return ERROR; не беспокоясь о текущем состоянии.

Осталось только дорасти до нормального RAII, как в плюсах например.

RAII — не очень удачный костыль для exception safety. В go нет exceptions, поэтому и RAII не нужен.

RAII --- это впервую очередь привязка времени жизни ресурса к времени жизни переменной, а не то что вы там фантазируете с исключениями.

А в го у вас костыли в виде варианта try-finally

В go нет исключений, а, следовательно, и try/catch/finally

RAII --- это впервую очередь привязка времени жизни ресурса к времени жизни переменной
Вообще-то RAII — это костыль, жестко связывающий получение ресурса (например, выделение памяти) с его инициализацией. Что делать, когда ресурс нужно инициализировать в несколько шагов, зависящих от других ресурсов? Как с помощью raii работать с массивом ресурсов? Как обеспечить exceptions safety в этих случаях?

Есть классы для массивов, scoped_array например

Костыль едет на костыле и костылем погоняет :)

В С++ внезапно нет автоматической сборки мусора, потому какие могут быть претензии.

Вот-вот. Поэтому попытки запилить некоторые вещи а-ля Джава и выглядят глупо.

Ну и совать сложную инициализацю в конструктор не рекомендуется не только на плюсах. А если что, деструктор почистит.

Что там в С++ насчет exceptions в деструкторах?

еще один костыль?

Это не костыль, это здравый смысл. Кидать можешь сколько влезет. Ты точно свои тесты проходил?

defer гошный — костыль, хотя и на уровне языка.

трэд про Go на Доу превращается в какое-то нытье Java/.NET разработчиков, которые ни разу не писали на Go, но пытаються его обосрать.
Народ, не волнуйтесь, работу у вас никто не заберет.

шо-то не складывается в логическую цепь.
Т.е. если бы джависты набежали с криками «ехайте-ехайте, гоу-гоу на свой Go» — то да,
тогда-бы можно заподозрить их, что распугивают народ с Джавы,
а так, джависты же и мучутся сомненьями, и делятся ими. Это не корысти ради, хочу заметить.

Ничего личного.

Просто у меня сложилось впечатление, что некоторые люди настолько застряют в своем стеке (это не только про Java/.Net, все такие), что просто отказываются смотреть и знакомиться с чем-либо еще только потому, что «там не так, как я привык».

Я еще раз повторюсь, я не считаю Go идеальным языком, «убийцей TECHNOLOGY_NAME». Но у него своя огромная ниша, а из-за того, что он крайне хайповый его лепят там где надо и не надо.

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

в целом, мне слабо понятно, нахрена новый Язык, если под Джаву можно подпихнуть любой траслятор, компилятор.

Современная замена С, которой перестал быть С++.
Не факт кстати, что Go ей станет, но ниша открыта.

1. Какое-такое «мелкое железо», если на уже бюджетном телефоне 4 гигагерцовых ядра?
2. Шаблоны — зло.
3. Go дает сборщик мусора и легкую многопоточность.

Шаблоны — зло.

Шаблоны — рулез. Код, избавляясь от чрезмерной общности, оптимизируется до достижения максимума производительности. А где это не получается, компилятор может и не инстанцировать, оставляя общий код.

А где это не получается, компилятор может и не инстанцировать, оставляя общий код.
Угу, как сейчас помню — рулили-обобщали так, что немаленькая память одного необлуживаемого устройства оказалась полностью забита пустыми контейнерами. А хрен ли думать — компилятор оптимизирует.

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

Это не крайний случай. Это проблемный проект, по итогам которого заказчик ушел из Украины.
А начиналось так весело — С++, лучшие практики, мы вам тут щас как напишем...

Это не крайний случай. Это проблемный проект, по итогам которого заказчик ушел из Украины.

«Крокодилы не плавают, потому что холодильник не зелёный» — логика ровно того же уровня.
Мне пофиг эмоциональные проблемы, что от кого-то ушёл заказчик. По сути изложение таки будет, или опять будет портрет с глазом на ухе?

Какие эмоциональные проблемы ?
Обычный фейл из-за того, что любителям обобщить все классы в один мегашаблон вовремя не дали по рукам.
Ценой овертайма и оверпрайса проблему решили, но заказчик отказался от продолжения.

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

Ну так почему вы этого не сделали, если видели, что те творят фигню?

Ценой овертайма и оверпрайса проблему решили, но заказчик отказался от продолжения.

Ничего удивительного. Вините теперь себя, а не язык.

Ну так почему вы этого не сделали, если видели, что те творят фигню?
Странный вопрос. Я зашел на проект, после того, как устроители этого счастья спетляли (а у любителей «изящной архитектуры с повторным использованием кода» всегда обостренное чувство на момент, когда у заказчика начнутся неудобные вопросы) и перед тем, как полезли фундаментальные проблемы.
По большому счету заказчик сам виноват, что пустил проект на самотек. Но зато я получил отличный опыт и в архитектурных решениях и в менеджерских кейсах.

Понятно. «Отличный опыт» системы «обжёгшись на молоке, не пьёт даже воды». И отсутствие главного в менеджерском опыте — как сделать, чтобы такого не происходило (а не как пофапать на состоявшееся). Зато эмоций вагон.
У меня такого опыта тоже достаточно, но я не считаю адекватным хвастаться им.

главного в менеджерском опыте — как сделать, чтобы такого не происходило
По-моему совершенно очевидно — держать мыслителей в рамках жесточайших правил кодинга, тщательно ревьювить и в случае чего жестко бить по рукам.

То есть меньше кормить, больше доить и не давать думать. Спасибо, понятно.

Тема с исключениями — хуже. Они никак не специфичны для C++ и не в нём первом; первый был или CLU, или что-то подобное, а из сохранившихся была Ada. Они становятся неизбежны, когда допускается переопределение операторов (передавать ошибку из кода вида a=b+c, где b и c не то матрицы, не то ответы SQL, или невозможно, или криво через левые глобальные переменные), и отсутствие их реализации сейчас говорит только о низком уровне языка. Если Go позиционирует себя ещё как один переносимый ассемблер, но с блэкджеком (параллельностью) и девочками (сборкой мусора), пусть, но зачем в принципе сравнивать с ЯВУ?

Они становятся неизбежны, когда допускается переопределение операторов (передавать ошибку из кода вида a=b+c, где b и c не то матрицы, не то ответы SQL, или невозможно, или криво через левые глобальные переменные)
Перегрузка операторов — самый лютый грех программиста. Вы сами ответили, почему.

А потребности в колбасе сегодня нет.

ОК, вот причины, почему перегрузка операторов — худшая из идей программирования (вы про них уже написали в процитированном предложении выше):
1) отсутствует нормальная передача ошибок;
2) сложно понять из строчки a=b+c, что этот код делает на самом деле;
3) стандартные операторы зачастую не покрывают все нужды классов, где были перегружены эти операторы. Также стандартные операторы могут принять максимум три параметра (aka тренарный ?:). Что делать, если оператору нужно передать больше параметров? Правильно — смешивать с обычными функциями и методами. Также можно пойти путем scala и дать возможность добавлять spaceship operator’ы. Но в обоих случаях получится запутанный говнокод.

Сравните, что проще для понимания и дебага:

status tableUnionTop(const Table a, const Table b, Table *result) {
    Table tmp;
    try {
        tmp = a+b;
    }
    catch (...) {
        return error(...);
    }
    *result = tmp.top();
    return success;
}

или

status tableUnionTop(const Table a, const Table b, Table *result) {
    status rv;
    Table tmp = a.union(b, &rv);
    if (rv != success) {
        return rv;
    }
    *result = tmp.top();
    return success;
}

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

1) отсутствует нормальная передача ошибок (вы про это уже написали);

Нет, она отсутствует там, где нет исключений, а не там, где перегрузка операторов.

2) сложно понять из строчки a=b+c, что этот код делает на самом деле (вы про это уже написали);

Во-первых, не я. Во-вторых, очевидно, что сложение определяется в зависимости от типа данного. Если для кого-то это сложно, ему не место в программистах.

3) стандартные операторы зачастую не покрывают все нужды классов, где были перегружены эти операторы.

Поэтому есть варианты создания вообще произвольных операторов (Perl6, Postgres), и неплохо получается.

Сравните, что проще для понимания и дебага:

Первое, если убрать из него ненужный тут try-catch, который Вы накидали только чтобы испортить впечатление.

(например, Go поддерживает комплексные числа, также есть предложения по добавлению поддержки матриц).

А завтра потребуются кватернионы или множества строк. И их будете добавлять в язык?
Одно слово — извращенцы.

А завтра потребуются кватернионы или множества строк.

github.com/golang/go/issues/19813

double facepalm. Спасибо за подтверждение невменяемости авторов языка.

А что вас смущает, поддержка комплексных чисел есть, а кватернионов — нет. Чем кватернионы хуже?

х Ладно, покэпствую: завтра наберётся ещё три десятка столь же специализированных сущностей, важных в какой-то одной отдельной подобласти. И если их всех вводить в язык — это будет не язык, а кривой ублюдочный монстр — к этому Go и движется с такими подходами. Вы ещё предложили бы каждую структуру данных из 10**100 возможных и полезных в современном коде ввести в язык.

В это же время нормальный основной путь развития языков — дать сначала возможность просто определять собственные типы, потом — их поведение и свойства, и операции с ними. Причём наиболее высокий уровень этого — возможность задания собственного синтаксиса (делается, например, в ) и типы как объект манипуляций языка (начиная с того же Haskell). Если это подать в понятном обычному кодеру виде — это уже достигнуто — то качество выражения своих идей, а, значит, и основные качества кода, как понятность, сопровождаемость и т.п. — повышаются до возможно тут предела.

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

есть тензорфлоу на плюсах и биндинги на го/питон/жабу/етц и другие математические либы. Попытки реализовать тоже самое, но строго на го пока из детских штанишек не вылезли.

Вот есть что-то наподобие каталога — github.com/…​-go/blob/master/README.md

А завтра потребуются кватернионы или множества строк.
А кроме матриц, векторов и кватернионов для подавляющего большинства расчётов по 3D графике никаких других объектов не требуется. Ну ещё если добавить аппарат по тензорному исчислению, всякие там матлабы можно выкидывать.
всякие там матлабы можно выкидывать.

И снова :facepalm:, хоть в привычку вводи. Вы как-нибудь поинтересуйтесь возможностями матлаба по символьным расчётам...

Ещё в DirectX давно есть библиотека со всеми типовыми преобразованиями с участием геометрических примитивов, оптимизированные под поддержку всех процессорных технологий, включая 3DNow!, SSE xx, AVX.

То упоротый гофер слегка лишака болтнул....)))
Ну ты ж сам знаешь, нафига нужен direct

Зависит. При операциях с матрицами перегрузка естественна, а возможность придумывания своих операторов как в Скале — уже перебор.

С каких пор написание и использование одного дженерика занимает больше, чем пучка скопипасченных классов по штуке на тип?

Че-че? Шеф, вы ваще поняли о чем речь, прежде чем выставлять свое сверхценное мнение?

Не так прочитал, sorry: не заметил, что упёрлись в память, думал сроки из-за самого написания абстракций пофэйлились.

Ты наверно думаешь, что на том же бюджетном телефоне 4 гигагерцовых ядра это единственный процессор в системе?

Какая разница? Даже один, четвертьгигагерцовый, но с MMU снимает вопрос о «мелком железе».

Та ты шо? Ну вот пальцем в небо — с контроллера зарядки/батареи что и каким образом может снимать твой четвертьгигагерцовый процессор с андроидом? Ещё раз. Даже в телефоне твой ЦПУ не единственный.

Я плохо понимаю как язык без поинтеров может быть заменой си ?

Да фактически всё, что не приводит к неожиданному раздуванию кода, имело бы смысл давно перетащить в C.
А в первую очередь — namespaces. Объём того, что видимо из библиотек, достиг такого уровня, что случайно повторить имя библиотечной функции — тривиальное достижение.

Всё определяется верой программиста
наприклад варiант «ми пользуем ISO C99 » шах влево чи вправо — растрел на мейсцэ

могу даже на Го,
«если Карпарация скажет надо, мы ей атветим есть!»

Зачем? С++ это наследник С, который предоставляет тебе все возможности С и предоставляет кучу других.

Вспомни опыт того же ядра Linux. Отчистить в варианте для C от требований рантайма — получилось (и хорошо получилось — я, как Журден, недавно узнал, что оно компилируется в hosted! FreeBSDʼшное — только freestanding). От C++ — нет. Слишком уж он многого хотел.
Для обычного юзерленда это всё обычно пофиг (если он уж Goпников терпит со статической вкомпиляцией кучи левой хрени — то и C++ выдержит). Сейчас вон даже GCC частично на C++ перешёл (в самых актуальных местах).
Но вот читаю я, например, TS 18661:1 — ты видел, сколько новых функций он включает? И таки да, я нашёл несколько таких, что я называл такими словами свои функции.

Если нужны namespaces просто юзай С++.

Ну сейчас так и делаю. Но общая тенденция не радует.

Чтобы namespaces перетащить в Си, придется практически ВСЕ операционные системы переписать. Что нафиг никому не нужно.

Чтобы namespaces перетащить в Си, придется практически ВСЕ операционные системы переписать.

С чего это вдруг?

Потому что линковка.

Не понимаю. Прошу развернуть.
Если, например, sqrt будет math::sqrt (что будет заманглено в что-то вроде _ZN4math4sqrtE), какие такие граблы будут с линковкой?

Тем что _ZN4math4sqrtE придется использовать ВЕЗДЕ. И в перле и в иксах. Навылазит куча багов итд. Никто этого делать не будет.

Если допустить параллельное существование для уже принятых функций, и только в отдельных пространствах для новых — никаких багов не будет.

В принципе, да. Но я ни разу не сталкивался в сях, с проблемой одинаковых имен в разных библиотеках. Тоесть оно как бы не плохо, но зачем? Громадных программ писать на голом Си вроде не сильно наблюдается. В Kernel (ну уж куда больше) такой проблемы тоже не замечено. По моему если такая проблема возникла, следует в первую очередь читать что значит static перед функцией или глобальной переменной, а потом уже рушить основы мирозданья.

в первую очередь читать что значит static перед функцией или глобальной переменной

static не поможет, если функция должна быть видима в соседний исходник. Ваш Кэп.

В Kernel (ну уж куда больше) такой проблемы тоже не замечено.

У них стандартная библиотека не включается. Даже у линуксового ядра, которое компилируется как hosted.

Но я ни разу не сталкивался в сях, с проблемой одинаковых имен в разных библиотеках.

А это проблема из тех, что, когда столкнёшься — бьёт как детские грабли. Я столкнулся.

Я не сталкивался. Хотя допускаю что может быть.

А не проще называть более грамотно переменные и функции?

Проекты были и не маленькие. А коллектив — да. Не большой.
Блин, сейчас никто не ваяет на Си большие проекты. Разве что мазохист какой-то. А на плюсах такой проблемы нет. Там даже без хитростей все скрывается за классами и проблем тоже не возникает.

Больше чем 20 лет, наверное действительно небольшой.

Но у С есть куча дурацких моментов, которые пофиксили в С++.

Перечислите эти дурацкие моменты, т.к. по-моему, С — отлично сбалансированный низкоуровневый язык программирования, в отличие от С++.

Мне тоже интересно. Потому что я тоже считаю что именно С — отличный язык.

Где плюсы? На моей прошлой работе Си и Го просто идеально получилось заюзать. Плюсы — язык для мозговых онанистов.

Но QT рулит. Для GUI плюсы рулят.

ООП идеальная парадигма для оконных систем.
И С++ был безусловным королём Wintel десктопа.
Но времена меняются.

ППКС. Для окон ООП было просто идеальное попадание. Причем не С++ а С++ доработанный QT (я про ихний connect)

Ну с оглядкой. Delphi привычки — не лучший пример для подражания.

Не писал на делфи. Но connect гораздо лучше чем калл-бак функции.

Времена меняются. Каждая ОСь для мобильника требует свой язык (андроид --- джаву, айфон --- свифт, винфон --- сишарп).

И только возможность писать кроссплатформенно на C++ для этого зоопарка остается неизменной.

Под андроид и айос уже можно писать на go — github.com/golang/go/wiki/Mobile . Винфон со своей 0.01% долей рынка нафиг никому не нужен.

И только возможность писать кроссплатформенно на C++ для этого зоопарка остается неизменной.

Вы перепутали С и С++

В рамках фреймворка типа Qt — возможно.
Но это же не тот С++ который вы продвигаете.
PS Некроссплатформенная Джава — доставила. Пишите еще.

Подкину свеженького про GO не GO, еще пар идиет — habrahabr.ru/…​mpany/mailru/blog/325046

любую php макаку берите, тут полный форум успешных примеров — ни одной осечьки

Ходят слухи, что в одной харьковской конторе целый отдел похапистов перевели на го и никто не заметил разницы!

шо как писали на похапе так пишуть?

Я как бывший PHPст, нынешний андроидист, не вижу проблемы перехода на Go, начинал учить по свободе — все понравилось, необычно местами, да, но это и подзадоривает скажем так.
Несколько знакомых, кстати, тоже с РНР ушли на Go, но они в США перебрались под эту тему)

только не называйте файлы функции итд начиная со слова test

не понял, а почему я должен?) есть/был какой-то тренд, а я пропустил?)

То для тестирования. В общем погуглите. Я два дня потерял.

ппц, может сначала нужно о языке почитать прежде чем проект пилить?

Так ведь «кошмар, караул, на позавчера надо было». Изначально это вообще сугубо мелкая тулза, чтобы дебажить другую хрень удобно мне было. В любом случае, быстрее чем на плюсах писать оказалось.

почему? го позволяет запускать тесты по регулярке, по build тегам и так далее. а не только по стандартной логике

Это классно. НО нужно понимать что в Го важен не только регистр первой буквы в названии. Это необычно и круто!

Короче, Go можно выучить за день, максимум два. Любой нормальный разработчик разбереться.

Да. Но чтобы нормально писать и всеми фишками пользоваться — несколько лет.

Это вам не С++, в этом вся и суть что несколько лет не нужно и еще опыт с других языков нормально переноситься. Например тот, кто хоть раз пользовался локами в Java/C#/C++ сразу поймет как использовать sync.Locker или там sync.RWMutex. Острелить себе ногу в этом языке тяжело, даже тяжелее чем в Java.

А как можно локами не пользоваться?

chanell := make(chan string);
chanell <- „We don’t need locks to share state”

Но в других языках есть например BlockingQueue или там concurrent_queue, но есть задачи, где без локов — никак.

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

Странно. Я не то видел. Может потому что я на ARMе смотрел. Но по идее должно быть платформо-независимое.

Но в других языках есть например BlockingQueue
Или например, EJB где паралельность о другом немного.

Channel в го и очереди в яве это producer/consumer паттерн жи есть.

порой в описании вакансии посмотришь требования, сразу в с++ превращается))

Доктор Манхэттен детектед :)))

да нет, просто очередной мамкин балабол :)

кстати кто то там про зп шутил
У Golang первое место в рейтинге самых высокооплачиваемых технологий в США — опрос StackOverflow
stackoverflow.com/…​/#top-paying-technologies

Дык, и у нас так
можно смело добавлять $500 к третьему квартилю по сравнению с джавой — jobs.dou.ua/…​=Java&spec=&exp1=3&exp2=5

Правда выборка у меня небольшая, на истину претендовать не могу

я чет всегда был уверен что по зп java в Украине > all

та нет, например, у хороших .NET часто больше

то вы не общались с HR-ами в мыле, которые исчут тиму сработавшихся эрлангистов на релокейт в Швецию))) Видел я этих бедняг — готовы были отдать себя в рабство, только бы людей найти))

Почему не видел, видел.
Мы примерно так же искали ребят, которые в силах кастомизировать ядро андроида для одного сесурити продукта.

Да и более простые вещи, типа QA под линух вызывают ступор и у внутренних рекрутеров и у агенств. Не то чтобы не знают куда копать, и зп $1,7 — $2к для крепкого QA мануал мидла вроде как не мало. Но блин ребята с 2-3 годами вроде как хардкорного сношания линукса сыпятся на интервью(а там, поверьте, ни какого рокетсайнса). Это печалит.

Про боль мидлов было бы неплохо поднять отдельный тред. Все кричат про генетический мусор среди трейни/джунов и 23х летних сеньоров, а меня вот пугают толпы ходячих мертвецов, которые в лучшем случае зависли на одном уровне развития и двигаются куда-то тупо за счет выслуги лет. Мне это совсем не понятно, на нашем перегретом рынке компании готовы брать людей, соответствующих требованиям на 60% — под развитие. А развитие это всегда + к баблу и возможности выбора интересного проекта. Ну как всегда, понятно что предел есть )

о стенания СЕО про «нет кадров»,
а якщо отсыпать 3куе+, слабо?
знов нема, то 4куе+, знов нема?!!

Та как-то 4куе за мидл мануал QA многовато
2куе не вопрос

Любая вещь стоит ровно столько, за сколько её можно купить и продать. Так что «маловато/многовато» это не конструктивно

вот только сотрудник это как бэ не весч )

Ты покупаешь труд, чем это отличается От вещи? Тем что лоха можно уговорить продать свой труд за дешево, а на рынке плевать хотели на интересную работу и важность покупки для человечества?

Я, по-моему, нигде про занижение ЗП не писал
А если лохи и лоховоды мерещатся то нужно бить по затылку этим исбном 5392157319 — одному знакомому знакомого помогло...

а меня вот пугают толпы ходячих мертвецов, которые в лучшем случае зависли на одном уровне развития и двигаются куда-то тупо за счет выслуги лет
Ситуация такая же и на забугорных рынках, если не хуже. Потому склоняюсь к тому, что это человеческая натура такая. 80% будут сидеть на попе ровно, а 20% будут ее рвать.
исчут тиму сработавшихся эрлангистов на релокейт в Швецию)))

классика жанра:
— группа (м)чудков начинают проект для фана на экзотическом языке.
— проект взлетает и начинает жить.
— и тут начинается вот это вот всё

с HR-ами в мыле,
Видел я этих бедняг — готовы были отдать себя в рабство

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

Это в Харькове, где исторически дотнета больше чем явы.

Тут как бы и не в деньгах вопрос, а в том, что их мало и у нас и в США и на шарике в целом

В начале года общался с одним мистером, он сказал, что они с GO уходят т.к. GO девелоперы есть только в гугле, я его аргумент тогда помножил на ноль, потому, что мистер много лет проработал в гугле и слегка предвзят в вопросе, кто такой девелопер. Но, блин, он из продуктовой хайтек компании на ~1к сотрудников, офисы только в штатах, с индусами не работают. И если для них проблема найти GO, то что тогда говорить про Украину.

про деньги то я так, коммент проскакивал, лень искать его было :)

а по поводу го разработчиков — сильных, наверное действительно мало. Вы смотрите какой тренд — все пишут «выучил синтаксис за пару дней и всё», вот от сюда и уровень «го-разработчиков» (они сами думают что они таковы). А для серьезных проектов и требования соответствующие

Так по идее го для мелких проектов, а не для серьёзных

Понимаете, любой инструмент можно использовать так, как его изобретатели даже представить не могли)

Вы исходники докера смотрели? Там половина проекта состоит из exec.Command, т.е. обращения к шеллу.

Занятно, раньше как-то даже и не задумывался.

Переписал несколько воркеров с PHP на Go — профит в скорости, использовании памяти. По сути learning curve дает возможность начать использовать очень быстро. Бинарник всегда ближе к железу, плюс дает возможно упаковать туда тяжелую логику. Использовать стоит. Переходить с PHP, Python, RoR, NodeJS, Java, C# довольно легко — правда тем кто в «школе» не осилил строгтайп придется поломать мозги и пальзы — у go нет ни нотисов ни ворнингов — потому либо код чистый либо не компилится :-) Самое оно для приручения диких нодеров

Почему нет warnings ? Все нормально — исключение всегда возвращаются в виде типа: ch, err := conn.Channel() и можете его обработать и ошибки компиляции тоже вполне нормальные.

я имел ввиду notice и warnings компилятора

Я имел ввиду notice и warnings компилятора.

Важко сказати кого перекваліфікувати легше. Думаю скоріше це питання задачі і мотивації. Найчастіше переходять на GoLang з PHP, Python, Node.js (роблю судження з мого кругу знайомих програмістів). І те, навіть не переходять , а скоріше переписують частини коду або (найяастіший випадок) — виносять як окремий мікросервіс. Раніше для web-development проектів/задач коли було необхідно було винести щось в мікросервіс брали зачасту Node.JS але на разі GoLang виглядає привабливіше. Відповідно тому саме з PHP, Python, Node.js .

Чи є сенс переходити з C#, JAVA, C чи С++ мені важко сказати, але у розрізі web-development’у та швидкої розробки/прототипування проекту легше та швидше освоїться саме якийсь Go/Node аніж C#, JAVA, C чи С++.

Також багато проектів використовує Docker і щоб розширити його під свої потреби вам потрібно буде зайнятися Go, адже, якщо не помилсяюся Docker написаний на GoLang.

Якщо постане задача, яку потрібно буде реалізовувати як (веб)мікросервіс то скоріше всього моїм вибором стане GoLang.

Також багато проектів використовує Docker і щоб розширити його під свої потреби вам потрібно буде зайнятися Go, адже, якщо не помилсяюся Docker написаний на GoLang
Блин, ты видел много людей расширявших Docker под свои потребности?

Знаю хлопців, закордоном знайомих які цим займалися. З наших компаній — Grammarly. Ось посилання на Github: github.com/grammarly/rocker

Так що, так, бачив :)

плагины начали фигачить будь здоров, под каждый чих

Смотря какие задачи. Смотрите вакансии go — все становится ясно. В основном — это опытные c++ разрабы.

но, судя по рынку, на Go пытаются перейти с Python или PHP
1) много проектов на пхп даже крупных, и так получилось (команда знает только пхп), что и микросервисы у них на пыхе написаны. Вот удобненько их на го переписать, все начинает летать. С питоном тоже самое — много сервисов написаны на питоне — тоже переписывают на голанг.

Еще вопрос — что пилить на го нужно? Потому что извращаются и пишут веб проекты на го, веб фрейморки и тд. Я пробовал — извращение.

Нужно этот язык использовать по назначению и не более. Тогда и подобные вопросы отпадут.

Нужно этот язык использовать по назначению и не более.
Заходим на golang.org и читаем первую строку:
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
Что-то ни слова о микросервисах. Забыли, видно

А что микросервисы не являются software? Во-вторых может не совсем корректно, но в данном случае под микросервисами я подразумевал и микросервисы и вообще всякие самодостаточные скрипты\демоны и тд.

Потому что извращаются и пишут веб проекты на го, веб фрейморки и тд.
То-есть веб проекты не являются software? Ну ок.

Являются, и? Вообще любой язык создан для написания ПО, но это не значит что нужно на паскале сайты писать. Сейчас обсуждаем, что в основном пишут на golang, а что лучше оставить для php, python, java, .NET и тд. Какая то странная у нас дискуссия....

Нужно этот язык использовать по назначению и не более.
Я лишь про то, что нигде в официальных доках и статьях про Го не написано, что он не подходит для написания веб проектов. Это вы себе выдумали про назначение. Количество веб фреймворков на Go и их активность как бы намекает, что это мнение разделяет далеко не большинство.
Я лишь про то, что нигде в официальных доках и статьях про Го не написано, что он не подходит для написания веб проектов.
Да, есть и шаблонизатор из коробки и роутинг и тд. Скорее есть более подходящие инструменты. Крупный проект лучше пожалуй на симфони начну писать чем на мартини.
Это вы себе выдумали про назначение
Однозначно. Для этого и есть пользователи продукта, которые делают выводы, делятся мнениями. А потом читаешь — о блин, а сообщество в основном использует язык для похожих задач, и в основном это как раз для тех задач, о которых я написал.
Количество веб фреймворков на Go как бы намекает, что это мнение разделяет далеко не большинство.
Количество проектов на джанго, yii, симфони, rails, spring — вот это большинство. А велосипеды есть везде. Расскажите мне сколько реально крупных проектов реализовано на golang веб-фрейворках? А еще можно отметить основные golang врейморки остановлены в разработке.
А так да, на нем можете хоть клиенты для ААА игр писать, никто не запретит.
Количество проектов на джанго, yii, симфони, rails, spring — вот это большинство.
При чем здесь пхп, руби и джава? Я то говорю о большинстве среди Го разработчиков. Не надо сравнивать тяжелое с мягким.
Расскажите мне сколько реально крупных проектов реализовано на golang веб-фрейворках?
Я не знаю (и вы, кстати, тоже). Может уже dou.ua на Go переписан — кто вам скажет? Время от времени появляются сообщения, что та или иная контора использует Го на бекенде и зачастую не говориться микросервис это или вообще.
А еще можно отметить основные golang врейморки остановлены в разработке.
Не остановлены, а стабилизированы, потому что основные фреймворки на Го обладают одним очень приятным для меня свойством — они минималистичны в отличии от монструозных spring-ов и симфоний. Не верите — сравните списки issue на гитхаб для gin и для symfony. И количество «star» тоже сравните, чтоб прозреть, что не смотря на молодость Го и Gin количество заинтересованных github пользователей уже в одном порядке.
github.com/gin-gonic/gin
github.com/symfony/symfony
По-моему это достаточно красноречиво говорит о том, что web development-у на Го быть. То что в украинских галерах вакансии для го пока еще в основном подразумевают именно написание микросервисов, так это потому, что украинским галерам в основном достаются легаси проекты, которые целиком на другой язык переписывать никто не даст.
При чем здесь пхп, руби и джава? Я то говорю о большинстве среди Го разработчиков. Не надо сравнивать тяжелое с мягким.
Мы заговорили о веб проектах и веб фрейморках. Без сравнения никак. Писать на го можно что угодно, вопрос — целесообразно ли это?
Я не знаю (и вы, кстати, тоже). Может уже dou.ua на Go переписан — кто вам скажет?
Наоборот компании постоянно описывают стек технологий, которые задействованы в проектах, и про смены технологии (mysql ->pgsql и тп) тоже постоянно пишут
Время от времени появляются сообщения, что та или иная контора использует Го на бекенде и зачастую не говориться микросервис это или вообще.
многие подробно описывают, какие части системы переписывают на го, особенно на конфах, докладах, митапах, даже цифры реальные приводят
Не остановлены, а стабилизированы, потому что основные фреймворки на Го обладают одним очень приятным для меня свойством — они минималистичны в отличии от монструозных spring-ов и симфоний. Не верите — сравните списки issue на гитхаб для gin и для symfony.
Да, про стабилизированы знаю. Минималистичны, какими и (имхо) должны быть сервисы на го. А симфони не спроса монструозен, все его компоненты активно используются разработчиками. Это позволяет быстро разрабатывать даже сложные проекты. Для минималистичности — все в нем разбито на независимые компоненты, используйте только то, что вам нужно. Тоже и в го, в любом случае придется в проект подключать 100500 зависимостей. А от веб го-фрейворка мне в основном роутинг нужен, авторизация, мб апи, которые так же есть в отдельных решениях на гитхабе.
И количество «star» тоже сравните, чтоб прозреть, что не смотря на молодость Го и Gin количество заинтересованных github пользователей уже в одном порядке
слежу и за тем и за тем, прозреть у меня не получится. Я сам влюбился в голанг, но написав 1 веб проект — наткнулся на огромное множество проблем, которых в том же php просто нет.
Мы заговорили о веб проектах и веб фрейморках. Без сравнения никак.
Вот я и говорю что если сравнивать теплое с мягким лучше не станет. Вы сравниваете базы пользователей технологий, время существования которых различается в несколько раз.
многие подробно описывают, какие части системы переписывают на го, особенно на конфах, докладах, митапах, даже цифры реальные
Если вы про конфы происходящие в Украине, то я помню как пару лет назад на конфе по Го один докладчик спросил у слушателей (порядка 50-70 человек) из зала «кто тут вообще хоть раз использовал Го» — руки подняли около трех человек. Украинские ИТ достаточно инертны относительно западного мира. И еще у нас есть этакая кучковатость в ментальности — все как один. Лет десять назад каждый второй писал на Delphi, это была супер модная технология, потом мода сменилась и все начали утверждать что никогда не любили Делфи. Хотя на западе в помине небыло такого скачка.
Поэтому я не сужу по тому как люди используют Го по украинским конфам, да и вообще на них больше не хожу. Если инетресует мнение общественности вот можно хотя бы на quora первые попавшиеся треды глянуть:
www.quora.com/…​velop-a-web-app-in-Golang
www.quora.com/How-is-Go-used-at-Google
никаких упоминаний про пригодность го исключительно для микросервисов.
А от веб го-фрейворка мне в основном роутинг нужен, авторизация, мб апи, которые так же есть в отдельных решениях на гитхабе.
Вот и я о том же
1 веб проект — наткнулся на огромное множество проблем, которых в том же php просто нет.
Пишу 4-тый веб проект на Го. Особых проблем не замечаю. Что именно за проблемы вы видите?

Не, явно не про Украину. Вообще последнее время мне сильно импонируют ребята из badoo, очень интересно рассказывают о своих проектах и процессах. Слежу за ними. Там и про go и про php.

Пишу 4-тый веб проект на Го. Особых проблем не замечаю. Что именно за проблемы вы видите?
О, это большая тема. Сейчас я временно на го не пишу, но мне есть о чем поговорить на эту тему. Пытался замутить DDD + MVC, во многих вещах упирался в нехватке обычного php oop подхода и не только.

Я не приверженец DDD. С реализацией MVC в Го проблем не вижу. ООП подход Го с упором на интерфейсы мне очень даже нравится.

Сорри, а где в go ооп? Ну не считая того что авторы таковым называюць)))

да нет его попросту. это не минус и не плюс. верней есть и минусы и плюсы. я все же настаиваю на том что не нужно в go реализовывать всё подряд.

да есть свои плюсы. но к примеру:
хочется у модели сделать метод setAttributes (у базовой, а блин наследования то нет) и всеми моделями использовать этот метод. Пришлось делать через отдельный сервис, передавать туда модель и использовать доп. библиотеку (github.com/fatih/structs). в другом языке я бы просто у любой модели вызвал метод setAttributes(data) и все. И подобные неудобства на каждом шаге. У меня вообще в модели не вышло методы никакие реализовать. Да, понятно что у go совсем другая идеология и возможно я её не вкурил её, зато я вкусил как все просто реализовывается для mvc проекта в любом другом ооп языке.

Если сильно нужно, то можно вот так включить функционал одного класса в другой:
play.golang.org/p/2H41Yj-fPQ
Но по-моему это нужно достаточно редко. Даже не помню чтоб я этим где-то пользовался.

Спасибо но не совсем то. Я хотел «свойства» классов заполнять данными. Через отдельный ModelService реализовал.

И правильно сделали — если не ошибаюсь, и в классическом ООП не рекомендуется делать чтобы предок каким-либо образом взаимодействовал со свойствами, которые будут у его потомков.

и да и нет. все зависит от объема проекта. если это не сложный crud-проект с простой админкой и фронтом — я на коленке на каком нить yii набрасывал такой за неделю — две. Мб где то с нарушениями архитектурного подхода, зато реализовывал быстро, с минимальным кол-вом кода, и главное — все надежно работало.

Если инетресует мнение общественности вот можно хотя бы на quora первые попавшиеся треды глянуть:
www.quora.com/...​velop-a-web-app-in-Golang
www.quora.com/How-is-Go-used-at-Google
никаких упоминаний про пригодность го исключительно для микросервисов.
кстати это всё субъективно. я так же могу накидать ссылок где пользование go у разработчиков вызывает боль, и все это они хорошо аргументируют и сравнивают с другими языками.

учить то надо сичас, щоб потом уже, не було мучительно больно за..

а як узнать чи оно кому надо, к ворожкэ? к ПМу ? к СЕО?

була одна в Краковi, навiть тестове завдання написав, потiм сказали, що набор заморожэно.

жабе
ням-ням
и жабоскрипту
не вставляе

и даже дотнет
бвууууээээ
ты ембедер и нос суешь в еще большее Г типа Гоу.
наприклад, з двох проектiв було би цiкаво код для рестрiмiнга медiа (аудio + video) переписати на Go та подивитися якби то було:

1. C & ffmpeg (Go & ffmpeg)
2. ffmpeg + python + wireshark + bash (Go & ffmpeg & wireshark)

Какая разница, чем ffmpeg дернуть

в смысли яка?
велика, що ти зсередини дьоргаеш викликом функцiй, а що зовнi скриптами

ну да, но львиную долю работы делает сам ffmpeg

Simple как бы намекает

Думаю, имеется в виду все-же возможность реализовывать сложные вещи по-простому, а не пригодность только для «хеллоу ворлдов».

После какого-то момента все равно будет сложно, для разных языков этот момент разный, но все равно неизбежен. Тем более что к простоте прилагается и ограниченность (тем более, что так было и задумано)

Если сравнивать с той же Java, где изначально было «все есть обьект», то Го менее ограниченный.

Да и пускай, если у кого-то от этого бомбит.
Я хотел сказать, что запилить огромного сложного монстра можно на чем угодно, даже если авторы инструмента не предполагали такого использования.

все становится ясно. В основном — это опытные c++
спасибо, я собственно мыслил примерно так же
еще вопрос — что пилить на го нужно?
микросервисы
их и нужно пилить

Чуть подробне(надеюсь, не потрут, вроде не реклама):
Ordnance(ordnance.co) provides carriers with a one-touch, carrier-grade Network as a Service platform that enables rapid software automated service delivery, reducing the need for network engineers to be involved in customer moves, adds and changes.
Backend is a globally distributed network and Linux systems orchestration platform, almost entirely written in Go with some C/C++ used to manage network equipment, Linux and FreeBSD kernel drivers.
Frontend is written in AngularJS, talking to a set of Go based RESTful API’s backed into RethinkDB and InfluxDB databases.

Да, видел вашу вакансию. Видение у вас верное.

Понятно, откуда копытца ростут))

Так, а что скрывать-то, у меня вполне простая логика.
Мы с клиентами работаем вдолгую и только по FTE, не делаем разовых проектов.
При росте тимы ой как не хочется, опять проходить через все круги ада с рекрутингом.

И опять же, на западе GO востребован, за мной сейлы будут ходить с грустными глазами и требовать крови... Оно мне надо? Оно мне не надо.

А сама технология интересна еще и тем, что на GO гораздо меньше проектов в стиле поле-на-форме-строчка-в-бд. ИМХО.

на GO гораздо меньше проектов в стиле поле-на-форме-строчка-в-бд
Ну это пока.

ваш сайт к стати ибаный Blue Coat только из за названия банит. Не оч здорово для ынтерпрайза

Сори, не совсем понял о чем Вы
Вроде бы все чисто

Я перешол с Java. Так как работаю сейчас на фрилансе то пишу на Go полностью бекенд (а не только микросервисы) для небольших веб сервисов. Не вижу причин не писать на нем и бекенд больших веб сервисов. Чем Го хорош по сравнению с PHP, Python, Node.js, Ruby:
— всем =) Он быстрее, он типизированный, у него нормальная стандартная библиотека и есть много веб фреймворков и библиотек на выбор (хотя мне нравится минималистичный Gin).
Чем Го хорош по сравнению с Java / C#:
— его легче и дешевле деплоить, гораздо ниже порог входа в бекенд разработку а производительность по крайней мере не хуже: benchmarksgame.alioth.debian.org/u64q/go.html и скорее всего в недалеком будущем будет только лучше. Следовательно для заказчика бекенд на Го обойдется во много $ дешевле чем тоже самое на Java / C#

Порицание наследования классов в Го считаю большим плюсом, в Java тоже почти никогда им не пользовался. И вообще весь язык считаю мега продуманным. Еще посматриваю на Rust, где, кстати, тоже нет наследования. Единственное что считаю недоработанным в Го — каналы, надо пользоваться очень осторожно, или заменять стандартными примитивами синхронизации.

Что-то наверно у меня интерпретатор аналогий сломался — каким местом эта картинка относится к написанному?

Здесь не спрашивали, что лучше..

человек спрашивает «с какой технологии, по-вашему, проще переключиться на Go?»
вы автору(первый уровень дерева комментариев) пишете о том, какой Go классный и почему на него надо переходить

Я ответил в первом предложении. А дальше просто описал почему так сделал, чтобы сразу ответить на напрашивающийся вопрос — «Почему?». Ниже в комментариях люди делали тоже самое, но вы не запостили им никаких картинок.

бекенд на Го обойдется во много $ дешевле чем тоже самое на ... C#
Вы, наверное, пропустили выход .NET Core

Коре — тормозное говно везде кроме винды
Проверялось тем самым бенчмарком, которым я уже всем моск засрал
Даже тупее мони

Вопрос ведь был не про скорость, а про стоимость развертывания. Я уверен, что для многих проектов производительности более чем хватает, а сам я зык и интструменты разработки очень приятные. Если вам скорость нужна попробуйте C, если умеете готовить, для каждой задачи, ведь, свой интструмент. А какашками кидаться много ума не нужно — это и абизяны в заапарке умеют.

Если вам скорость нужна попробуйте C, если умеете готовить,
умею, но меня вполне устраивает C#
который по факту не сильно медленнее С работает
а net.core реально адски тормозит под линухом (примерно в два раза медленнее моно, которое тоже далеко не идеал производительности)
и не забываем что там только core-то и есть, но не все пилят бесконечный веб. а значит для разрертывания на линухе проектов где есть хоть минимальная winforms морда придется юзать моно, а не коре.
А какашками кидаться много ума не нужно — это и абизяны в заапарке умеют.
а никто и не кидается — я как раз реальные претензии озвучиваю, во отличии от вашего голословного:
Я уверен, что для многих проектов производительности более чем хватает

Core и преназначен для конслек, а не для UI. Не слышал про UI на Go, хотя какие-то экпериментальные штука гуглятся. Тема ведь не об этом. Притенции — хорошо, оформленные как issue на git-hub — еще лучше. Из команда много усилий прилагает для улучшения производительности, так что думаю, он над этим работают.

во отличии от вашего голословного:
Он, ведь, несоизмеримо быстрее работает, чем System.Web, который многих устраивает. Я вот об этом.
Не слышал про UI на Go
причем здесь go? я исключительно за шарп говорю
оманда много усилий прилагает для улучшения производительности, так что думаю, он над этим работают
прекрасно, вот как только догонят виндовую версию по произодительности, тогда можно будет посмотреть стоит ли использовать
Он, ведь, несоизмеримо быстрее работает, чем System.Web, который многих устраивает. Я вот об этом.
я веб-разработкой практически не занимаюсь, поэтому могу предметно говорить только о производительности десктопного кода. но если простая работа с массивами и операции сравнения тормозят — это проблема не конкретной библиотеки, а платформы в целом((
вобщем те кого такое устраивают — будут юзать, те кого нет (например я) не будут))
причем здесь go?
Так тема про go, ведь. И я про .NET Core написал в этом же контексте. Но спасибо, что поделились опытом с производительностью.

Поправлю сам себя. Парачока мелких по объему кода, но крайне специфичных по предметной области проектов показала что таки Валялкин местами прав.

То вы каналы готовить не умеете. Весьма удобно.

А вы уверены, что вы умеете? Оказывается, мало кто умеет, зато многие сразу хватают и суют их во все места.
www.jtolds.com/…​-and-you-should-feel-bad

Конечно нет. Я ведь не долго на нем писал. Да и это было далеко не основное чем я занимался. А мнения, они разные есть.
Смотрел примеры понравилось как красиво и лаконично получается.

а вот про каналы ща обидно было...

ниже и выше ссылки кидал...

а набуй оно тогда надо если самое вкусное (каналы) не использовать?
Обмазаться мютексами и сидеть делать вид что так и надо?

батька, скажи, ты ж и скалолаз тоже вроде как?
если да, я тебе вопрос интересный хочу задать
котловоды на него уже кошерно ответили, теперь ишшу скалолаза)))

неа я не настоящий скалолаз, я старый жабоеб который на скалу изредка поглядывает. Но ты спрашивай может кто другой ответит

github.com/doomviruz/PerfTests
От тут лежат тупые бенчмарки, основанные на реальном проекте
если ко из настоящих скалолазов сможет мне объяснить , почему скала медленнее — или где я натупил, буду благодарен
котлиноводы уже дали свой ответ, его видно в коммитах
гоферы пока молчат))
Утром добавлю мой f# вариант ( тут тоже апологеты пусць поправяць)
И туда же активно призывается наш северный коллега из Менска
свои проноварианты на крестах я туда коммитить не рискну, дабы не опозориться))
Но пока что жаба с гадюкой держат уверенное первенство по скорости
Особенно гадюка, с ее unsafe и fixed)))

Кусок из реального genetic optimization, упрощенный до предела
Я уперся в то что доставалово элемента из массива и сравнение настолько дорого стоят, что у меня это 90% процессорного времени занимает
в .net я решил вопрос через жоппу — unsafe и fixed
но работает быстро
И тут решил я сравнить все что можно без хаков: шарп, жабу, скалу, котлин, фшарп, це, кресты, гоу, ну короче все что можно))

for с yeild и потом toArray это ужас ужас по перформансу.

чет типа джавовенького

val siganals = new Array[Signal](size)
(0 to 9999).forEach { i =>
signals(i) = Signal(...)
}

должно шустрей инициализировать.

Вот тут описано
www.jtolds.com/…​-and-you-should-feel-bad
А каналы-то не настоящие! ©
С тех пор я осторожно с ними
Ну и для меня самое вкусное в Го это его дзен-простота, а еще с недавних пор Gogland

его легче и дешевле деплоить
Конкретизируйте.

Конкретизирую — не нужно никаких предустановленных рантаймов, контейнеров. Деплоится один самодостаточный бинарь с приложением. +Обычно менее требователен к памяти при прочих равных.

Я бы скорее задал вопрос «зачем». Кто сможет на него основательно ответить, тот и сможет перейти на go с легкостью, так как всем ясно что язык — лишь инструмент, дело в фундаментальных скилах разработчика.

Просто — очень удобно. Язык писаный не «академиками» а реальными прогерами практиками.

Наверное, более половины языков писалось не академиками. Взять например Котлин — тут вообще писалось исключительно программистами для программистов (тем более в первую очередь — для себя самих же).
И если например говорить про меня, то я не сказал бы, что мне на джаве писать неудобно. Тем более тут не языком единым, должна быть большая инфраструктура. А вот перейти на Go с надеждой, что я через год буду счастлив — слабо верится, учитывая что много чего надо писать самому из-за «простоты» языка (одно отсутствие дженериков чего стоит).
Прыгать на новенький язык, просто потому что он «удобнее», «проще» — грош цена такому разработчику.

Меня убедили что у языка много перспектив.

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

Например, те же generic’и, продвинутое ООП — это всё, как правило, характерно для условного «энтерпрайза», а в небольших утилитах и сервисах можно прекрасно обойтись и без этого.

Бабушку.

Боюсь, этот вариант еще лет 25-30 будет неактуальным.

Ваш вариант: Верните Валялкина.

Тут как бы дело не столько в кости, сколько в бэкграунде.

Продукт, по сути, чем-то похож на VMware NSX, только без привязки с остальному их барахлу.
Так вот: С/С++, Python, Perl со знанием сетей (чуть больше чем, как работает трасерт) я встречал, а других как-то нет.
Может плохо смотрел (

Мурманов?

Думаю стоит добавить вариант «свидетелей иеговы».

свидетели иеговы изучают scala

Вот кстати единственная не упоротая статья написанная (скалистами-хаскелистима) по поводу го
pchiusano.github.io/…​1-20/why-not-haskell.html

В компании писал на python. Понадобилась производительность, решили go попробовать. Сейчас пишу еще и на go. Просто к статистике, что переходил на go после python. Товарищ есть, тоже python основной в компании, но помимо него еще go используют и другие языки по мелочи.

Т.е. получается, что все-таки основной вектор не схожесть технологий, а стек задач?

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

Ясно, спасибо
Ожидания оправдались?

задача выполнена) язык прижился

быстрое
в сравнении с питоном конечно быстрое))
а с нормальными языками — тормознутое

не вброс))
проверено на реале:
простейший код с тремя вложеными циклами и двумя условиями, шарящийся по массивам, go выполняет в 2 раза медленнее чем тот же код на java или c# (разница между ними в пределах погрешности измерения). так что компилеру go есть еще куда развиваться. хотя надо сказать что скалу и котлин он сделал (скала медленее в 1.3 раза, а котлин в 2.5)

на какой версии go проверял?

1.8, впрочем первый раз на 1.7 пробовал — разница в пределах погрешности

Создай багрепорт в github.com/golang/go/issues/new — и его пофиксят в go 1.9 .

бггг))
делать мне больше нечего
ты ж тут главный гофер, ты и создавай
исходник теста могу поискать

Жду исходник теста на play.golang.org .

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

play.golang.org/p/r9UduLoz3b
правда там оно не выполнится
на моем старом i3 этот код выполняется ~280 секунд

в идеале еще код на java/c#, что бы можно было убедиться в ваших словах лично и не тратить время на трансляцию (если у вас сохранился)

сохранился на шарпе, да и на яве должен был остаться
там надо еще убрать кое-какие ссылки на предметную область в названиях
чуток позже выложу

да, это совсем другое дело,
185 секунд вместо 280.
Это конечно не в 2 раза, но теперь отставание от лидеров уже совсем небольшое — порядка 5-7%
А вот что меня смутило — так это тот факт что при доставании элемента массива он копируется, вместо извлечения ссылки. Логичнее было бы наоборот — явное копирование, а неявно — ссылка. Впрочем go все же не OO язык...

Тут не хватает оптимизации, при которой значения бы «копировались» по ссылке, если бы компилятор смог доказать, что в дальнейшем скопированные значения не изменяются, как в данном примере. Может, в следующих версиях go добавят эту оптимизацию. Создал багрепопт — github.com/golang/go/issues/19817 .

go добавят эту оптимизацию
как по мне generic-ки гораздо нужнее

К сожалению, generic’и с template’ами в других языках программирования используют не по назначению в большинстве случаев, что приводит к необоснованному усложнению кода, замедлению скорости компиляции, разрастанию скомпилированных бинарников. И только в паре процентов случаев использование generic’ов дает реальный выигрыш в качестве кода. В 99% случаев это стандартный набор контейнеров и алгоритмов для произвольных типов данных.

Разработчики go готовы добавить generic’и, если удастся реализовать их в таком виде, чтобы максимально затруднить их неверное использование, в то же время максимально упростить их корректное использование. Проблема в том, что такие дженерики пока никто не придумал. См. golang.org/doc/faq#generics

жаль...
потому как копипастить тонны кода — гораздо хуже, чем усложнение рантайма

Generics впринципе только облегчают работу — так как безопаность типов гарантируеться во время компиляции — так что ими можно не уметь пользоваться, о чем сообщит компилятор сразу после написания кода, но использовать не по назначению их впринципе не даст компилятор. golang полагаеться же на то поведение в текущий момент, из-за которого в языках и появляються generics и которое куда более небезопасное — на удачную распаковку в рантайме, или некрасивую передачу замыканием массива и появляться вот такое уродство:
github.com/golang/go/issues/16721

оказалось что если отключить bounds check, то go наконец-то равняется с шарпом/явой/котлином по производительности
но понятно что такой цирк в продакшене крайне нежелателен, особенно с учетом того что исключений нету

Bounds check elimination активно внедряется в новых версиях Go — см. github.com/…​ues?utf8=✓&q=is:issue BCE . Нужно будет прогнать код на go 1.9 и, если он все так же тормозит, то создать багрепорт наподобие этого — github.com/golang/go/issues/17370 .

если использовать средства языка и использовать горутины, время уменьшается в ~3 раза — play.golang.org/p/PO6KeoAt7z
плюс если обьявлять структуру не с массивами, а срезами и потом их инициализировать отдельно, то у меня выигрыш еще ~20 сек вышел — play.golang.org/p/wiKY4tEyYo. Меняется расположение массива. Уже не часть структуры, а указатель на него. Хотя так как потом передается слайс в функцию, а не массив, то по идее разницы не должно быть. Но тут надо профилировать

если использовать средства языка и использовать горутины
не-не-не))
никакой многопоточности, только хардкор, только чистое сравнение качества компиляции
понятно что если я в шарпе и яве тоже потоки заюзаю то скорость вырастет так же в 3-4 раза
но тут есть один ньюанс
в реальной задаче размерности больше
и к-во generations на самом деле 10000-30000 тысяч
и еще — в реале таких потоков много — но с разными данными
если пытаться делить внутри самого алгоритма на потоки, то получается медленее
эффективнее распараллеливать такие задачи по наборам данных а не по операциям
тут дана только выжимка самой нагруженной части алгоритма

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

но в целом тут стало интересно. как то вечером поиследую почему так (предварительно запустив и сверив ваши примеры на других языках :), попрофилирую. ибо по логике оно не должно работать медленнее в числодробилке.

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

это фича языка
это такая же фича языка как async/await или lock в шарпе — синтаксический сахар.

запустил пример шарпа. выполняется столько же по времени (под mono)
java пока не запускал, надо погуглить как оно там запускается и компилится

mono — говно
оно у меня даже медленее go работало
все замеры делались под 10 виндой

запустил и java, вот она в ~2 раза быстрее выполнилась.
но код не смотрел. это уже потом гляну (плюс в примерах c#/java размеры массивов 32, вместо 50, но это такое. шарп столько же как и го выполнялся)

массивов 32, вместо 50,
32 это переменные, см VarCount
а 50 это популяция — разные массивы

код на java/c# +/- одинаковый
никаких платформенно специфических оптимизационных хаков не юзалось
и время выполнения +/- одинаковое

вот в этой репе сравнение разных языков
github.com/doomviruz/PerfTests
по котлину меня уже люди поправили, он сравнялся с производительностью java
для go может тоже найдется решение?))

нет. было интересно попробовать go.

Да он хоть в каких то рейтингах есть, даже зарубежных? Про Украину я вообще молчу...

Так навскидку солянку из всех рейтингов... И де там Гоу?

www.quora.com/…​language-to-learn-in-2017

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

Сейчас на него хороший спрос (просто надо знать где искать этот спрос), много проектов с питона переезжает на go. Плюс в микросервисной архитектуре он практически не имеет конкурентов. Go фактически подвинул python и java.

в микросервисной архитектуре он практически не имеет конкурентов
Сильное заявление. Проверять мы его, конечно, не будем.

Ну он ща на слуху, и истории ходят о переходах, это куда важнее чем какието там рейтинги.

Может очепятка и «в переходах», а не «о переходах»?

Может очепятка и «в переходах», а не «о переходах»?
Даже в переходах скоро без знания Go нечего будет делать.

Последователи Го напоминают свидетелей иеговы- постоянно делают попытки обернуть как можно людей в свою веру.
Вот посмотрите — никто не пытается

переквалифицировать
людей в Java, C#, python etc.

Это вполне логично, поскольку за golang — будущее, а за Java, C#, python etc — прошлое.

за golang — будущее
Согласен, думаю golang скоро займет своё почетное место на этой странице Википедии

Не займет, потому что большинство успешных проектов Google и не только уже написаны на нем. А свидетели церкви Го, это все сектанты перебежчики Node.js.

большинство успешных проектов Google
Будьте так любезны -перечислить?
Потому как у меня совершенно другая информация от Гугла.
Все более менее серьезные проекты в Гугле пишут на Java, C++.
Проекты не переписывают без необходимости в Гугле.
Программеры покрайне мере те что здесь в штатах в офисах гугла по большему счету- пытаются держаться от golang проектов по дальше.
Хотя руководство всячески форсит на нем писать.

Из тех что приходит в голову и довольно большие: Kubernetes, OpenShift Origin, Docker, Mattermost, gogs.io. Продукты Hashicorp (Consul, Vault, etc).

И какой из этих продуктов гуглом написан ?

Kubernetes (он же Google Container Engine (GKE))

Вот еще можно посмотреть, что люди пишут на нем github.com/…​trending/go?since=monthly То есть комьюнити там уже не маленькое, и если гугл бросит поддержку, думаю найдутся те кому это нужно.

Мені було би шкода. Як на мене, дійсно ефективна мова програмування.

Выходите из анабиоза — Go уже обогнал С++, С и даже PHP по количеству популярных репозиториев на github:

2,697 JavaScript
1,153 Java
858 Python
661 Objective-C
568 Ruby
426 Go
383 C++
358 PHP
347 C

Остальные «новые революционные языки программирования» типа scala, rust и swift не вошли в top10 и вряд ли туда попадут в обозримом будущем.

Программистам scala теперь больше ничего не остаётся, как только кусать локти, и писать starship-операторы.

Ну вот почему любители го ведут себя как дети и агрессивные веганы?

ты знаешь я знаю нормальных го програмистов, но на ДОУ какая то особая фракция ходит.

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

githut.info

А по активным репозиториям, то он нифига не обгоняет . Если смотреть в динамике, так он вообще сьехал. И там де, как бы он должен рулить и быть на первом месте, типа «революция, мать его !! », то тоже нифига — «NEW WATCHERS PER REPOSITORY» — Swift, «NEW FORKS PER REPOSITORY» — R....У тебя тупо подгон статистики под себя ))

У тебя тупо подгон статистики под себя
не у меня, а у гитхаба. Наверное, гугл заплатил гитхабу много бабла из огромного бюджета на раскрутку go, поэтому гитхаб поднял go выше php, c и c++, а другие молодые и перспективные языки программирования типа scala, rust и swift выкинул из топ10.

Слышал, что go будут рекламировать звезды шоу-бизнеса во время следующего финала SuperBowl. Бюджет на раскрутку go позволяет. Это вам не нищеброды из гетто scala, rust, nodejs и dart.

Зміни драгділера, інакше зостанешся на узбіччі прогресу))

Это вам не нищеброды из гетто scala, rust, nodejs и dart.
так это... насчет дарта... нищебороды, которые его разработали — это те же нищеброды, что разработали Go (гугл тобишь). -))
Последователи Го напоминают свидетелей иеговы
C#, python про них в свое время тоже самое говорили

Владимир- возможно.
Просто я впервые сталкиваюсь с таким агрессивным и топорным продвижением языка.

Думаю многие даже бы попробовали с ним поиграть- но троллизм гоу боев очень сильно отталкивает

Просто я впервые сталкиваюсь с таким агрессивным и топорным продвижением языка.
Так надо просто перейти на Go, и перестать терпеть неудобства.

Надо просто тщательно и долго ходить по граблям, чтобы набрести на язык, где перед известными граблями поставили надежные заборы.

Про шарп да, но там майкрософт толкала. Про питон — не помню.

Да кого угодно: это даже не язык.

ггг, начал и закончил читать на «C-style»

дальше можно не продолжать: sapienti sat

Ведь c-style самы первый пункт самой первой ссылки на статью, а репозиторий — набор статей разных авторов. А то выходит: «Не читал, но осуждаю.»

Большинство пунктов связаны с попытками использовать знания из других языков при написании кода на Go. Множество так называемых «неудобство» нивелируются грамотной архитектурой.

замена C++ — раст, не ?
замена питону... нету замены питону.
Замена перала — питон.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

замена питону... нету замены питону
лол, а я вот как раз наоборот часто слышу как питон скрипты переписываются на го

переписывают 3 строчки кода на 100 строчек кода ? мозахисты штоле ?

govspy.peterbe.com
не преувеличивайте. Да питон в этом плане язык-красавец, но у голанг тоже вмеру краток. Бесит правда if() при каждом чихе...
но плюсы перекрывают эти небольшую разницу в кол-ве строк кода

Какие плюсы ? Отсутствие дебагера ?
Писать скрипты на го, это как писать скрипты на скале — если больше ничего другого не знаешь, то можно жрать кактус.

ну если плюсы не очевидны — о чем говорить тогда? почитайте что пишут представители компаний, перешедших на го, и почему они это сделали, и сколько сэкономили. очевидности вам писать лень.

Коментар порушує правила спільноти і видалений модераторами.

Любого опытного сотрудника, который согласится перейти с денежного и стабильного мейнстрима на язык вакансий по которому раз-два и обчёлся и платят за это мало. Я правда не знаю зачем это опытному сотруднику

Ну во-первых не деньгами едимными, а во-вторых спрос на Го программистов в моей округе не ниже той же джавы.

не деньгами едимными
А чем ещё? Чем лучше го той же джавы?
спрос на Го программистов в моей округе
Это какая то очень специальная округа. Количество вакансий на Го на два порядка меньше той же джавы, если брать в целом

соискателей с опытом меньше на два порядка.

Ну естественно, потому что проектов нет. Вот взять здешние пенаты
jobs.dou.ua/…​acancies/?category=Golang
11 вакансий на всю Украину
jobs.dou.ua/vacancies/?category=Java
214 вакансий

Теперь сравним зарплаты. Средняя у синьора Java 3500, а у синьора голанг сколько? Даже статистики нет

хорошо, вот вам реальное положение дел за пределами вашего уютного пахучего болотца

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

бо те руки шо есть ув Нэнци — все разобраны, и их более чем неплохо кормят, и вообще

Однако на джаву продложений по трактору тоже значительно больше.

А теперь смотрим на реальное положение вещей и понимаем, что Джава мирок очень замкнутый и посторонних людей там не ждут, а большинство заявленных вакансий для тех, кого ростили под себя ЕПАМы/Люксофты.

Ну да минус джавы что короме джавы еще нужно 100500 фреимворков знать. Плюс го что 100500 фреимворков покаместь знанать не нужно, потомучто их тупо нет.

По этой же логике все должны бежать на php c wordpress.

Нет, потому что зарплаты маленькие. По го даже статистики нет

Ну не совсем так, если все вместе то да. Но если взять отдельно пхп, например symfony или magento у которых вилка 2-4К и популярность wordpress, то в итоге выходит популярно и дорого.

Сравни с java, работы меньше чем PHP но не на порядок. При этом СРЕДНЯЯ зарплата больше раза в два.

Java это весьма на любителя. Тонны легаси и энтерпрайз сомнительного качества, потому и зарплаты такие. Так сказать надбавка за вредность.

Я за деньги гавно ведрами носить буду

Так и есть, за говно всегда хорошо платят ))) И в мире джава где куча стабильных проектов из палеозойской эры, этого добра навалом. Время покажет, go активно набирает обороты, и есть задачи где его использование оправдано. Как минимум его есть смысл использовать вместо python.

А вот и нет. Питон активно применяется для моделирования бигдаты

Ну из того что я вижу, то сейчас много проектов переписываются с питона на го. Возможно это только сфера которая мне интересна. В целом я считаю, что go займет свою нишу (где то между python и java). Плюс учитывая что это компилируемый язык, то он теперь часто будет встречаться в виде shared libraries вместо того же с++.

Ну и сравни со спросом на знания того же спринга.

Тут смотреть? jobs.dou.ua/…​tegory=Java&search=Spring

Я просто не в теме, spring это хорошо или плохо? Ну и опять таки, го это не обязательно developer. Сейчас практически во всех вакансиях devops его требуют. Фильтр на dou не очень годится для этого.

Спринг это требование для девяти из десяти жабских вакансий. Знаешь спринг, хибернейт, вебсервисы и без работы ты не будешь

Ну так же с go, знаешь linux, shell, go, aws/gce без работы не будешь )) Думаю просто тут не совсем корректно сравнивать. Go это всего лишь инструмент, один из многих. Это не серебряная пуля. И само понятие перехода на Go немного бредовое. Что то из разряда перехода на shell или перехода на html ))

Вот такого плана вакансии обычно требуют go jobs.dou.ua/…​cies/35857/?from=list_hot (как я и гвоорил, между python и java)

shared libraries вместо того же с
рилi

Почему Валялкин еще не отписался в этой теме? Не написал что-то вроде «язык настолько крутой, что кого угодно. Даже обезьяну» ?

Потому как это топикстарер и есть скорее всего)))
Никогда смущало полное оццуцтвие реальных контактов в профиле сабжа?)))

Нет, он это и есть ,истинно говорю , не один литр самбуки и пива был испит с этим дядькой :)

Привет Алехей
Бросай свою Северную Каролину, приезжай к нам самбука пить пива запивать)

ответил ниже
меня все поняли с точностью до наоборот

Воу-воу, полегче, все мои контакты есть в профиле, ну а у кого палец до кнопки не достает — www.linkedin.com/in/fominv

я про валялкина вообще-то))
уж больно он на бота похож по поведению и в профиле у него ничего внятного не было
вот и подумал что ботовод объявился
если нет — звыняйте))

Потому как это топикстарер и есть скорее всего)))
Ага fuzzy logic :-)

ну в темах по go обычно только ее и можно применять))
ибо обычная логика не работает))

уж больно он на бота похож по поведению и в профиле у него ничего внятного не было
Наверное, вы попутали мой профиль с чьим-то другим.

Упс, сори
я думал Вы собирательный образ :-)
Удалил из вариантов )))

Проще переквалифицировать при 3 составляющих:
1) у человека есть желание
2) работодатель дает возможность сделать переход
3) на рынке столько вакансий и они высокооплачиваемые что придется переквалифицироваться если хочешь лучше жить

Ну и того кто с многопоточностью очень тщательно «поимел сношений». Внутри функции сделать функцию и сразу отпочковать ее в отдельную нить, это круто. А еще того кто вдоволь насмотрелся на код от онанистов на С++. Типа зачем просто переслать одной строчкой два байта, если можно написать класс для этого, перегрузить ему несколько операций, прикрутить ко всему этому темплейты, и получить несколько киллобайт кода и несколько файлов вместо 1 строчки.

сделать функцию и сразу отпочковать ее в отдельную нить, это круто
Ничего нового.

Это уже есть и C#:
привет таски а анонимными методами

Это уже есть в Java
Смотри java стримы, ну или vert.x фреймворк например.

Вот эта разрекламированная го многопоточность- никак не выделяет язык из ряда других мейнстримов языков.

А учитывая любовь гугла закрывать успешные проекты на ровном месте- как то совсем не прильщает даже смотреть на этот язык.

Коментар порушує правила спільноти і видалений модераторами.

Ничего нового.
Это уже есть и C#:
привет таски а анонимными методами
Это уже есть в Java
Смотри java стримы, ну или vert.x фреймворк например.

Чтобы не быть голословным, предлагаю сравнить следующий код на Go с аналогичным кодом на Java и C#:

for i := 0; i < 10; i++ {
    go fmt.Printf("hello from goroutine %d\n", i)
}

Собственно почти так же. Кроме того, что у нас нет встроенного пула потоков.


ExecutorService executor = Executors.newFixedSizeThreaPool(Runtime.getAvailableProcessors());

for(int i = 0 ; i < 10; i++) {
executor.submit(() -> System.out.printf("Hello, from runnable %d\n", i);
}

Ну він як би є (ForkJoinPool) і можна зробити щось типу


IntStream.iterate(1, i -> i+1).limit(10).parallel()
.forEach(i -> System.out.println("thread: " + i));
але там були нюанси.

ну можно так:

Parallel.For(0, 10, i =>
{
    Console.WriteLine("Parallel task {0}\n", i);
});

Ваша любимая scala.

for(i <- 1 to 10){
Future { println(s"hello from future $i") }
}

Пример какойто странный, никто так в жизни не делает.

Так и исходную задачу никто не делает.

Младших научных сотрудников. Старшие — тоже сойдут.

С++, С. Мне вот сказали что дескать стар я для веба, и пофиг что писал на Го.

стар
не так: не «стар», а «супер-стар»

после джавы и swift го заходит на ура. С python и node.js общего почти ничего

Интересно ваше мнение, кого проще переквалифицировать на Golang разработчика:
конечно же
n) Ваш вариант
ниасиливших скалу))
Кого проще переквалифицировать на Golang разработчика?
Scala-разработчиков

Любопытны рассуждения, стоящие за этой мыслью. Вроде бы, парадигмы у этих языков совершенно разные?

Это шутка, просто были холивары недавно на тему scala vs go.

Недавно это два года назад? А гоферы никак не остановятся

Не має значення насправді. Це одна з задумок, створить дуже просту у вивченні мову.
Хіба що сішник буде фігачить оппа сі-стайл за звичкою, а джавіст городитиме фабрики адаптерів до фасадів. Тоді пітонщик швидше в’їде.

Того кто хочет переквалифицироваться.

Nodejs добавим как вариант ?

Підписатись на коментарі