Вышел Go 1.5

А чем он лучше чем Nim?

Или Rust.

Ну тут все очевидно, нет необходимости думать о управлении памятью.

тогда в чём разница с умными указателями в С++ ?

А чем он лучше чем Nim?

Или Rust.

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

А с точки зрения языка и среды — они, всё же, заметно разные. Про Nim не в курсе, а Rust позиционируется как альтернатива Си. Golang позиционируется как альтернатива Java/Python/etc.

Go уже вовсю используется на практике и в продакшне.

Не стоит выдавать желаемое за действительное.

Не стоит выдавать желаемое за действительное.

Docker — это уже массовый продакшн. И на GitHub по числу активных коммитов Golang уже в десятку вошёл. По числу новых вотчеров проектов — вообще на второе место после JavaScript: http://githut.info

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

тогда в чём разница с умными указателями в С++ ?

В том же, в чем разница между GC и простым подсчетом ссылок.

По числу новых вотчеров проектов — вообще на второе место после JavaScript

Если я правильно смотрю эту таблицу, так на первом месте swift. А на втором Go. Если так, то что тут удивительного? Там ведь процент указан.

В том что надо их использовать и есть возможность неиспользовать.

что использовать, а что нет, тут за вас уже решили

Простой подсчёт ссылок - это один из вариантов хорошего GC. Вы напрасно думаете, что в С++ нет GC. Просто здесь я сам решаю, нужен ли он мне и если нужен, то какой. Если вы внимательно читали новость, то поймёте, что на С++ я могу реализовать Go, если возникнет необходимость, а вот обратное неверно.

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

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

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

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

Как там, в стране эльфов?

вы комплексуете что-ли?

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

не так страшен чёрт

Просто в С++ проекте перед тем как кодить вы должны определиться какая функциональность вам потребуется, какие ограничения вы накладываете (вплоть до соглашений о форматировании кода), т.е. вам необходимо самим определить правила игры. Записываете это всё в файл и прибиваете к проекту.

Всё это работает только для сферического проекта в вакууме. То есть до первого использования сторонней библиотеки. Другому коллективу (который пишет ту самую библиотеку) свои «правила игры» навязать не получится. Или в мире эльфов все библиотеки идеальны?

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

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

Go очень простой язык. Использовал я в проекте библиотеку, мне понадобился от неё новый функционал - я запилил и сделал пуллреквест. Конец истории.

Хорошая библиотека реализации чего-либо - это чёрный ящик, вещь в себе, которая выставляет наружу хорошо определённый интерфейс, соответствующий её функционалу/предназначению. Почему я должен захотеть копаться в её потрохах? Случись в ней баг, дак это хорошо, что я изолировал её своими обёртками - это поможет локализовать проблему и не дать ей расползтись по всему коду. Если это библиотека высокоуровневых абстракций, значит она изначально играет по нашим правилам (точнее мы играем по её правилам) раз мы решили её использовать, тем более никаких проблем.

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

Почему я должен захотеть копаться в её потрохах?

То есть лучшая политика - спрятать голову в песок? Обложить баг костылями?

Hint: не все и не всегда оперативно правят баги из своего багтрекера.

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

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

И хорошо, когда это видно сразу.

this. Далеко не всегда это так.

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

Здесь спорить не буду.

Почему-то вспоминается комикс.

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

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

...а внутри сишные биндинги.

Было и такое. Сишные биндинги и внезапные паники. Оказалось проще переписать без сишных биндингов.

Возможно, главное не зацикливаться на Go, и смотреть по сторонам.

а комикс хороший

Возможно, главное не зацикливаться на Go, и смотреть по сторонам.

У каждого инструмента есть своя ниша. Я не буду писать ядро ОС на go - для этого есть более подходящие инструменты.

У каждого инструмента есть своя ниша.

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

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

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

Был опыт работы в команде по разработке на С++. У нас куча времени ушло, но то, чтобы договориться какой стиль форматирования использовать и какой туллчейн, как это всё будет настроено, чтобы можно было выявить проблему на этапе сборки и т.п. Я бы с удовольствием тогда перешел бы на Go или Python, только потому, что там есть стандарты и правила, когда можно ткнуть человека в PEP8 или в оф. доку, где написано как надо форматировать код. А то выходит, что один учил С++ по книгам Дейкстры и у него такое форматирование, другой пишет в BSD стиле и т.п. Кому то удобнее писать в Eclipse, другому QtCreator, а один отщепенец вообще только в виме пишет.

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

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

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

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

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

Кому то удобнее писать в Eclipse, другому QtCreator, а один отщепенец вообще только в виме пишет.

А это-то как мешает? Не всё ли равно?

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

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