Что за идиотизм с импортами в гуланге?

Вполне себе нормальная логика. Возможно немного непривычно.

В GOPATH создается папка github.com, и при форке репозиториев они складываются туда.

И в какой папке вы бы не начали свой проект - по данному пути GOPATH/github.com/hipstor/cococo/internal-lib/functions сборщик всегда найдет нужный пакет.

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

Т.ч. можно рассуждать об эфимерном менеджере пакетов, а можно и shut-up and code

на языке с нормальным подключением пакетов! :P

PS: если же либа не придерживается compatibility promise — время искать другую (или форкать).

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

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

Ну это уже тут до маразма доходит.

А в других языках ты не должен этого делать?

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

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

Шесть страниц треда, с решениями и практиками, и всё ради того что бы вернутся к началу. Лор это гниющее дно.

Whatever. Пас.

Да что мелочиться, бери ассемблер, там этой проблемы нет.

Если тесты не пишешь и ошибок боишься - просто не обновляйся. Никогда.

Я за тредом не следил, мне задали вопрос - я ответил. Может, перечитаю, если будет время.

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

А что, согласно дарвинистам, мы все так и живём уже около 5 миллиардов лет. В чём проблема?

По теме: мне удобней абсолютными.

Как минимум, в относительном пути есть одна неявность: текущая «директория». Это может запутать дело в некоторых случаях.

А вот тут вот опять выплывает, ранее в треде осмеяный, go test.

ты гонишь какую-то пропаганду. Долго, упорно. Хватит обманывать себя.

Почему это не могут? Что за неверие в силу человеческого разума?

Есть мнения.

http://eao197.blogspot.com.by/2015/05/progidiotic-rsdn-lor.html

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

Шесть страниц треда, с решениями и практиками

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

npm

отличный пакетник

просмеялся

А тебе что нравится?

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

Кто сказал, что оно только с github работает? Моя песочница вон вообще на собственном cgit.

И go get перекрасно таскает от туда пакеты.

ref: https://www.dim13.org/go-get-cgit

А про «имена» — это всего лишь часть пути, как оно организовано на github. В том же gitlab или gogs можно и без.

pacman, xbps, portage.

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

Или когда фиксация версий имела под собой какие-либо иные причины, кроме «боязни изменений» (а не то мой Г-код сломается!)

Бюджет. Ты вообще хоть раз в реальном проекте по разработке ПО участие принимал, клоун?

Currently I'm (still) studing Aerospace Engineering at TU Berlin.

I'm also IT Administrator at Moccu – Creative Agency for Digital Media and open-source developter with affinity to OpenBSD, Plan9 and Go.

А, ну тогда понятно все.

Люди, зачем вы время тратите чтобы с этим товарищем вообще спорить?

Завязываться наглухо на один сервис

Действительно кем нужно быть, что бы завязываться на какой-то npmjs.com - много ты пакетов установишь без интернета или если он ляжет?

Это всего лишь репозиторий, сегодня один, завтра другой. У гоперов же привязка на уровне имен пакетов. Если гитхаб завтра закроют, то весь го-код сломается. Нужно будет каждый сраный импорт во всех проектах менять. Это вы называете хорошей инженерией? Да это днище, до которого еще никто не докатился.

Моя песочница вон вообще на собственном

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

pacman

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

Это всего лишь репозиторий

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

Если гитхаб завтра закроют

Это всего лишь репозиторий.

то весь го-код сломается

Это вообще-то компилируемый язык программирования.

Нужно будет каждый сраный импорт во всех проектах менять

То что ты не знаешь godep я еще могу понять, но, то что ты не можешь sed'ом изменить одну строку на другую - это трындец.

из чего ты будешь его поднимать.

Эээ https://docs.npmjs.com/misc/registry https://www.npmjs.com/package/sinopia ?

Похоже вы ни разу ни строчки не написали на Go.

go get работает с системами контроля версий. Ему не важно, тянуть с github, или с вашего личного репозитория git-а.

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

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

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

go get работает с системами контроля версий. Ему не важно, тянуть с github, или с вашего личного репозитория git-а.

А почему git'а?

По-моему - это нормальное решение, имеющее право на жизнь.

По-моему в go вообще нет ни одного нормального решения. Набор костылей.

К сожалению.

Это вообще-то компилируемый язык программирования

Сломаются сборки, балда. Кому нужны блобы без рабочих сорцов.

sed'ом изменить одну строку на другую

Поржал с гопнутых инженегров. Если гитхаб накроется и вам нужно будет перенести все либы в другое хранилище, вам придется седом херачить всё на свете. Весь старый код (у которого может уже не быть мейнтейнеров) автоматически сломается.

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

Ржу опять. Гоперы еще и джедаи локалхостов оказывается.

Если я не ошибаюсь, то он и с Mercurial умеет так же дружить. Он просто клонирует репозиторий в локальную папку, используя сисему контроля версий.

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

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

По-моему в go вообще нет ни одного нормального решения. Набор костылей.

На вкус и цвет все фломастеры разные. Лично мне он понравился своей простотой и наличием всех необходимых инструментов «из коробки».

А на каком языке пишете вы?

Вы вырвали фразу из контекста.

А как по вашему программы пишут? На рабочей станции, или сразу на кластере?

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

Такие языки вредны для индустрии и инженерии.

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

Это идиотизм.

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

Взаимоисключающие параграфы.

Лично мне он понравился своей простотой

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

А на каком языке пишете вы?

В зависимости от задачи.

если память кончилась - все равно капец

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

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

Мне кажется, ты не очень знаешь, как работает golang. ;)

И как он работает? То, что ты процитировал - это просто рекомендация. Как язык помогает ей следовать?

Тут пол-треда об этом. Перечитай.

Нет. Запрещает потому, что люди ошибаются.

Ну-ну. Они как раз пишут (про плюсы):

On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

Это именно «написанный ранее код к исключением не готов».

Сейчас Rust смотрю. За исключением синтаксиса и некоторых ограничений языка пока все устраивает.

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

Я тут не понимал, почему они дженереки не запиливают. Но покодил тут серьёзно на джаве и утонул в болоте, затыканном @SafeVarargs и @SupressWarnings(«unchecked»). Уж лучше без них, чем так. Хуже только рефлексия

Кодю на жаве много лет. Про @SafeVarargs слышал только в теории. unchecked изредка надо затыкать в библиотечном коде, да. Раз на 10 000 строк примерно. Может ты как-то не так пишешь?

Как как использовать инструмент - дело программера, а не самого инструмента.

Ха. А как насчёт форматирования? Тоже «дело программиста» или тут внезапно выяснится, что навязывать единый стиль - это удобно и правильно?

Тсс, они не слышали, что можно в GOPATH слить с гита (не обязательно гитхаба) или другой VCS нужную версию
Ну и вообще можно и в папочках хранить

им apple на лопате swift принесла, а они...

вообще попробовал я этот go для написания простого грабера ссылок

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

понравилось обилие всяких готовых библиотек

ну а синтаксис чем то попахивает нехорошим, чего-то про дельфи вспомнил бррррр

Даже если ничего грамотного не сделать, часто бывает нужно хотя бы что-то «закрыть»(не файлы, которая ОС закрывает, а, например, корректно завершить сессии по протоколу, сделать необходимые записи в логи и т.д. и т.п.

Какие именно ограничения мешают?

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

Потом подход с ссылками мне не очень понравился, вроде как и безопасность, но таки иногда мешают. Я вполне могу сам в C++ корректно работать, например, с итераторами на контейнер, параллельно продолжая работать с ним(правила валидности итераторов описаны в стандарте). Да, бывают баги, но это все проверяется и фиксится. В Rust же какие-то подпрыгивания на ровном месте. Неприятно ..эм.. с «философской» точки зрения. От свободы C++ переходим к чему-то такому, где тебе не доверяют. Неприятно. Возможно это дело привычки.

От свободы C++ переходим к чему-то такому, где тебе не доверяют. Неприятно.

«В наше время нельзя доверять никому, даже самому себе» (ц)

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

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

Наследование - да, хотелось бы. Ну и оно обсуждается, так что когда-то дождёмся.

От свободы C++ переходим к чему-то такому, где тебе не доверяют. Неприятно. Возможно это дело привычки.

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

Лично мне больше по душе «строгие гарантии», пусть и с «ограничением свободы». Если надо - это явно обходится/отключается. Собственно, явность тут важная особенность. Опять же, воспринимаю это не как «недоверие», а как «подстраховку». Конечно, всякие «гении» тут начнут орать, что это не нужно, если «быть внимательным» и т.д.