Это не говорит о том, что инструмент лучше остальных, заметьте

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

Вот непонимаю написанного. Можно проблему описать?

ну по сути нельза просто в папке с проектом создать папку aaa и потом ее импортировать в main, если папка с проектом лежит не по адресу /home/{user}/go/src/{project name}/

Неправда

И ещё проблема — нельзя отделить приложение от зависимостей. Вот как в maven например - все зависимости валяются где-то в $HOME/.m2, а при сборке подтягиваются. С точки зрения CI просто шикарно. С GOPATH всё не так. Нужно либо исходники приложения копировать внутрь GOPATH, либо какими-то симлинками заморачиваться. Потом нет версионности - каждому приложению свой GOPATH нужен. И это вымораживает слегка.

И ещё проблема — нельзя отделить приложение от зависимостей. Вот как в maven например - все зависимости валяются где-то в $HOME/.m2, а при сборке подтягиваются. С точки зрения CI просто шикарно. С GOPATH всё не так. Нужно либо исходники приложения копировать внутрь GOPATH, либо какими-то симлинками заморачиваться. Потом нет версионности - каждому приложению свой GOPATH нужен. И это вымораживает слегка.

Можно же, как и в любом gcc и прочем

Вынос мозга. У вас есть как минимум 2 способа отделить зависимости от приложения - вендоринг и собственно GOPATH, однако $HOME/.m2 который является тем же самым но только с боку, приносит вам дикую боль? Рили?

Вынос мозга. У вас есть как минимум 2 способа отделить зависимости от приложения - вендоринг и собственно GOPATH, однако $HOME/.m2 который является тем же самым но только с боку, приносит вам дикую боль? Рили?

О чем и речь, МОЖНО, но не удобно)

Вынос мозга. У вас есть как минимум 2 способа отделить зависимости от приложения - вендоринг и собственно GOPATH, однако $HOME/.m2 который является тем же самым но только с боку, приносит вам дикую боль? Рили?

чем это отличается от pip install ?

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

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

C pip-ом та же проблема, с любым манагером зависимостей таже проблема.

проще говоря при переходе с другого ЯП надо изучить помимо самого го еще кучу всего)

Неудобно делать симлинк в CI?

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

Я как минимум, сменил 4 ЯП, везде как минимум год нужен, что-бы окунутся в экосистему, но с Го это было проще всего.

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

на хабре яндекс писал про gb - тоже вроде бы решение.

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

Hint - если выучишь JavaScript, сможешь писать и бек, и фронт, и декстопное ПО на одном языке. (Правда любить тебя никто не будет после этого) 😄

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

я вот тоже по-тиху на го слажу))с питона)) хотя и питон казался ламповым))

Который из? Говорят, что питонов аж два штука.

а всегда GIL есть плохо?

глобальный лок? да, всегда плохо

это было пофиг в одноядерной системе

но где вы видели одноядерную последний раз? и когда?

Контейнер

согалсен, но а где Вы видели язык с 0 написанный для многоядерных систем?

это не язык - это решение проблем с многоядерностью

это не язык - это решение проблем с многоядерностью

Это ответ на вопрос где вы видели одноядерную систему