Что было для вас самой большой проблемой при работе с Go?

В этом году мне посчастливилось организовать GopherConIndia 2015, а также взять интервью у ряда сусликов.

Прочтите, что суслики со всего мира ответили на вопрос: «Что было для вас самой большой проблемой при работе с Go?»

Abhijit Hiremagalur. Как опытный разработчик, я думаю, что моей самой большой проблемой был кризис идентичности. Я занимаюсь одним из видов программирования (написанием приложений Ruby / Rails) уже несколько лет и стал очень продуктивным с определенным набором инструментов и, следовательно, очень зависим от него.

Когда я изучаю Go, мне пришлось изучить совершенно новый набор инструментов, и в некоторых случаях я обнаружил, что нет аналогов инструментам, к которым я привык. Например, управление зависимостями кажется спорной темой в сообществе Go, и я стал сильно полагаться на Bundler при написании Ruby. Чтобы научиться жить без этого в Go, потребовался сдвиг мышления.

Другой пример - мой редактор. При написании Ruby я в основном использовал Rubymine. Изучение Go стало хорошей причиной, наконец, научиться использовать Vim. Одна вещь, которую я скучаю, будучи новичком в языке и редакторе, - это отсутствие у меня под рукой набора инструментов. Когда я читаю Ruby, я стараюсь по ходу рефакторинга, с Go мне сложнее. К счастью, я работаю в паре с инженерами, которые более опытны как в Go, так и в Vim, поэтому я надеюсь, что эти проблемы носят временный характер.

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

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

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

Барон Шварц - Есть несколько областей, в которых Go позволяет делать вещи разными способами. К ним относятся несколько синтаксисов объявления и именованные возвращаемые переменные. Это вызвало у нас в Vividcortex несколько тонких ошибок. Сейчас мы стараемся этого избежать. Также есть несколько незначительных вещей, которые ожидаются от молодого проекта - проблемы с производительностью со сборкой мусора, незначительные ошибки на различных платформах и т. Д. На самом деле, это очень стабильный язык, библиотеки и среда выполнения по сравнению даже с очень зрелыми языками. Я очень доволен Go.

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

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

Кори ЛаНу - Пытаюсь не отставать от Леви Кука! Помимо этого, продолжаю находить новые идиомы. Я обнаружил, что когда мне не нравится мой код на Go, это потому, что я сделал его неправильно. Не всегда очевидно, какое решение есть, но я знаю, что оно есть. Что никогда не было проблемой, так это выпустить код за дверь. Я никогда не поставлял столько качественного программного обеспечения за такой короткий промежуток времени. Никакой другой язык не позволял мне делать это раньше.

Дамиан Грыски - Отсутствие библиотек. Становится лучше, но нам предстоит еще долгий путь, прежде чем мы догоним Perl CPAN или Python PyPI.

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

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

Elliott Stoneham - Изменения в API пакетов библиотек, от которых зависит мой код, в прошлом причиняли мне много горя, особенно потому, что это часто случается в наименее удобные времена! Продажа кода действительно помогает, но я с нетерпением жду, когда сообщество Go найдет общее решение проблемы контроля версий.

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

Фатих Арслан - Сначала интерфейсы были для меня в новинку. В этом нет ничего страшного, но наблюдение за тем, как стандартная библиотека использует интерфейсы (тип http.HandlerFunc - один из таких), было весьма освежающим. Теперь я считаю, что это одна из лучших особенностей языка (даже лучше, чем примитивы параллелизма).

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

Джош Бличер Снайдер - обучение эффективному использованию параллелизма. Go предоставляет прекрасные составные строительные блоки, о которых легко рассуждать. Самое сложное - увидеть, что возможно. Https://www.youtube.com/watch?v=HxaD_trXwRE и https://www.youtube.com/watch?v=QDDwwePbDtw открыли мне глаза. И как только вы начнете видеть возможности, сложнее будет использовать забавные игрушки только тогда, когда для этого есть веская причина. Простые умные козыри.

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

Jyotiska NK - Поскольку я разрабатываю в основном на Python, строгие системы типов и синтаксические соглашения в Go были чем-то, что меня раздражало вначале. Но нужно время, чтобы привыкнуть к среде и стилям форматирования. Когда я привык к языку, писать качественный код стало довольно просто. Кроме того, отсутствие исключений фактически заставило меня написать больше строк кода, но в конце концов это окупилось, так как мне не пришлось беспокоиться о некоторых недостающих блоках try для исключений, которые я забыл поймать.

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

Леви Кук - отвыкание от разработки и проектирования с помощью Ruby и Java. Я хотел, чтобы проекты были организованы определенным образом, а это не подходило для Go. Я хотел наследства, потому что умел так думать. Я также забыл, как заниматься низкоуровневым программированием, потому что это было спрятано в отличных библиотеках на моих предыдущих платформах. Преодолеть это было непросто. Я много раз писал и переписывал библиотеки и приложения, прежде чем почувствовал себя идиоматическим Go.

Марсель ван Лохёйзен. Для меня это было простым. Стандарт простоты базовой библиотеки очень высок. Это была самая сложная часть разработки API.

Мэтью Холт - Изменение моего подхода к написанию программного обеспечения. Удивительно, как трудно изменить определенные привычки. Они не обязательно плохие, просто они не так хорошо работают в мире го. Но как только я приспосабливаюсь, меня это обычно очень устраивает.

Мэтт Аймонетти - я бы сказал, что это могла быть отладка программ go.

Мэтт Хит - Рефакторинг! Когда я начал писать Go, на меня определенно повлиял мой предыдущий опыт Ruby и PHP. Затем я обычно несколько раз проводил рефакторинг, пока мой код не стал намного более идиоматическим и (к счастью) намного проще.

Натан Янгман - Указатели. Когда их использовать, а когда нет, и как они взаимодействуют с остальным языком.

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

Сау Шеонг Чанг - Есть несколько областей, которые остаются для меня непростыми - структуры данных, интерфейсы и горутины по разным причинам. Структуры данных и интерфейсы знакомы, но отличаются от того, как я бы использовал их в Ruby. Хотя горутины являются захватывающими и мощными, но каналы по-прежнему остаются сложными, но это вызов, который одновременно увлекателен и доставляет удовольствие.

Стив Франсиа. Мне было бы сложно выбрать хотя бы одно, поэтому я расскажу о двух связанных проблемах. Две проблемы - это отсутствие библиотек и документации. Оба являются типичными условиями молодого языка. Несмотря на удивительно обширную стандартную библиотеку для своего возраста, написание приложений на Go сегодня часто означает написание собственных библиотек. Это также часто означает чтение исходного кода, чтобы понять, как использовать сторонние пакеты. Когда я писал Hugo, по ходу дела я разрабатывал несколько других библиотек, потому что мне нужна была библиотека, которой еще не было. Например, мне нужен был хороший командир командной строки. Не найдя ни одного, я написал Cobra, которая сейчас используется в open shift и во множестве других приложений. Кроме того, при написании Hugo мне нужна была хорошая библиотека для обработки конфигурации, поэтому я написал Viper, чтобы заполнить этот пробел. Хочу отметить, что у обоих хорошая документация.

Эти вызовы - палка о двух концах. Хотя вам может потребоваться написать несколько больше библиотек, чем нужно в более устоявшемся сообществе, таком как java или ruby, вы получаете возможность помочь в создании библиотек, которые будет использовать сообщество. Однако я не думаю, что когда-либо есть оправдание тому, чтобы не писать документацию. Если вы собираетесь потратить время на написание библиотеки и поделиться ею по лицензии с открытым исходным кодом, вам следует предоставить документацию о том, как ее использовать.

Вероника Лопес - из другого языка мы обычно все время пытаемся сравнивать его с го, что неуместно. С другой стороны, самой большой проблемой для меня в Мехико было попытаться убедить команды, боссов и других разработчиков использовать его, в основном по двум причинам: нетехнические боссы всегда боятся использовать новые технологии, которые не используются. пока хорошо принят, потому что обычно это означает, что вы не можете легко найти новых разработчиков Go или тратить время и деньги на их обучение, прежде чем они смогут стать продуктивными. Другая причина - на стороне разработчиков: имея тонны разработчиков Java, .Net и C в Мексике, они обычно неохотно принимают новые технологии в соответствии с философией если мои инструменты все еще работают, зачем их менять, поэтому сообщество по-прежнему очень маленький, но мы над этим работаем.

Что ты думаешь? Разместите их здесь.