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

В виме, конечно же. gofmt и прочие отлично работают.

А ты предлагаешь в super-puper-goide.exe, который, судя по всему, в попу ломается от любой неожиданной фигни? нет, спасибо

У некоторых вимеров, например, не работал автокомплит, пока они писали не в GOPATH. Сходу вряд ли что-то еще вспомню.

В чьём HEAD? Гипотетического проекта или его зависимостей?

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

я игнорирую

Дрочишь в присядку, да? ;) Ню-ню.

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

Как по мне, дрочить в присядку — это заставлять код зависеть от текущей директории и имени и владельца репозитория

Да, есть gopkg.in, но в реальности без него пока еще ничего не ломалось.

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

Не вижу ничего страшного в самой возможности.

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

когда есть возможность инклудить напрямую мастер бранч с гитхаба — это ФГМ.

Ну почему же нерабочий. Вполне себе рабочий. Только API изменили, например. Это я к тому, что в go-комьюнити крайне низкий уровень инженерной культуры.

Только API изменили, например.

На страницах проектов, которые собираются ломать API в ридми обычно крупно написано: under heavy development.

в go-комьюнити крайне низкий уровень инженерной культуры

Какие-то мы с тобой разные сообщества наблюдаем.

это ФГМ.

Это как минимум удобно для небольших проектов. Примени пламегаситель и еще раз подумай об этом используя логику.

Только API изменили, например.

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

https://golang.org/doc/faq#get_version

Packages intended for public use should try to maintain backwards compatibility as they evolve. The Go 1 compatibility guidelines are a good reference here: don't remove exported names, encourage tagged composite literals, and so on. If different functionality is required, add a new name instead of changing an old one. If a complete break is required, create a new package with a new import path.

Это как минимум удобно для небольших проектов. Примени пламегаситель и еще раз подумай об этом используя логику.

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

(disclaimer: вышенаписанным я _не_ признаю, что это дерьмо удобно для проектов какого-либо размера)

should try

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

Это я к тому, что в go-комьюнити крайне низкий уровень инженерной культуры.

+1

отлично сформулировал

Какие-то мы с тобой разные сообщества наблюдаем.

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

А если не секрет, то зачем ты взял go?

когда есть возможность инклудить напрямую мастер бранч с гитхаба — это ФГМ

Что тебе мешает не делать так, а воспользоваться _штатным_ инструментом для вендоринга, и хранить в своих сорцах еще и сорци нужных тебе сторонных либ, на нужных тебе коммитах, и собирать с них?

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

Я не говорю что это лучшее что мог дать нам кришна, но и в pip'ах gem'ах и прочих сладостях говна по ложке. Хотя второе не должно оправдывать первое.

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

Пруфы будут? Или это откровения диванного аналитика?

и хранить в своих сорцах еще и сорци нужных тебе сторонных либ

...которые тоже тянут код в житхаба.

Что тебе мешает не делать так

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

Есть godep и прочие тулы сторонние для решения этой проблемы. Гуглеры так и говорили, мы не писали эту фичу для вас. Пусть сообщество создаст удобный инструмент. Критикуешь - предлагай! :)

я не могу никогда заранее знать размер проекта. поэтому go заранее негоден.

И? Не вижу причины по которой инклуды должны быть прибиты гвоздями во веки веков. Вообщем, все твои аргументы как минимум в этом треде в духе 'У меня подгорело!!!111'.

все твои аргументы как минимум в этом треде в духе 'У меня подгорело!!!111'.

по-моему, у кого тут горит - вполне очевидно. мне-то чего? я go не пользуюсь, и не собираюсь :)

Packages intended for public use should try to maintain backwards compatibility as they evolve. The Go 1 compatibility guidelines are a good reference here: don't remove exported names, encourage tagged composite literals, and so on. If different functionality is required, add a new name instead of changing an old one. If a complete break is required, create a new package with a new import path.

Господи, это просто охрененно.

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

Судя по цитате выше, golang не работает.

Критикуешь - предлагай! :)

Предлагаю выкинуть golang и забыть о нём как о страшном позоре для всей индустрии.

Пруфы будут?

https://golang.org/doc/

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

Не зря на go, в основном, переходят php'эшники и js'ники иногда...

что pip или gem чем-то лучше - говно из соседней бочки, как по мне.

А как правильно?

А как правильно?

ну я не истина в первой инстанции, но npm без -g, и засунуть все в сорсконтроль при необходимости, нормально.

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

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

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

Язык слеплен на коленке

4.2

лишен кучи зарекомендовавших себя инженерных решений

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

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

Ну не без этого.

Не зря на go, в основном, переходят php'эшники и js'ники иногда...

А эта инфа откуда?

В общем, в основном голословные утверждения вместо аргументов.

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

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

Вроде исключений?

Вроде ADT и параметризуемых типов

Гугл запрещает использовать их своим плюсокодерам, например.

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

Гугл запрещает использовать их своим плюсокодерам, например.

Гугл много чего им запрещает. И это маразм.

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

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

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

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

это еще хуже чем всякие com.google.appengine.api.modules.ModulesServiceFactory в жабе (название было нагуглено для примера).

но все равно видеть прямые ссылки на всякие гитжабы и битбакеты в исходниках - это жесть

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

Т.е. исходники не качает во время билда. Пакет ты качаешь/обновляешь отдельно и своими руками. А во время билда оно уже берёт то, что было скачано тобой.

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

$ tree -L 3 $GOPATH/src
/home/lord/BIN/go1.4.2/GOPATH/src
├── 9fans.net
│   └── go
│       ├── acme
│       ├── draw
│       ├── games
│       ├── LICENSE
│       ├── plan9
│       ├── plumb
│       └── README
├── code.google.com
│   └── p
│       ├── go.net
│       ├── graphics-go
│       └── jamslam-freetype-go
├── github.com
│   ├── BurntSushi
│   │   ├── xgb
│   │   └── xgbutil
│   ├── eknkc
│   │   └── amber
│   ├── golang
│   │   └── lint
│   ├── gorilla
│   │   ├── context
│   │   ├── mux
│   │   ├── securecookie
│   │   └── sessions
│   ├── go-sql-driver
│   │   └── mysql
│   ├── iu0v1
│   │   └── daslog
│   ├── jstemmer
│   │   └── gotags
│   ├── kisielk
│   │   ├── errcheck
│   │   └── gotool
│   ├── kr
│   │   └── pty
│   ├── nsf
│   │   └── gocode
│   ├── rogpeppe
│   │   └── godef
│   ├── SpiritOfStallman
│   │   └── attar
│   ├── yosssi
│   │   └── ace
│   └── ziutek
│       └── mymysql
└── golang.org
    └── x
        ├── crypto
        └── tools

Так, и что будет, если я форкну либу и накачу на нее свой патч? Менять ее импорт во всех файлах ручками?

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

Мы пока еще не все в гугле работаем, и не везде исключения считаются bad practice. И они точно лучше чем когда либа на пару тысяч строк кода возвращает тебе строку типа «bad_request» в качестве ошибки, вместо подробного объекта с описанием состояний и стектрейсом.

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

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

Вроде ADT и параметризуемых типов

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

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

За это надо бить. И не потому что ексепшны это хорошая чтука, а потому что потом вылавливаешь чудесатые хрени вроде «new вернул nullptr, но мы это не проверили». причем в либе блять.

ну а вместо этого пути

/home/lord/BIN/go1.4.2/GOPATH/src

можно использовать что-то вроде «$HOME/myproject/modules»? без костылей? или на каждый проект отдельного юзера надо?

возвращает тебе строку типа «bad_request» в качестве ошибки, вместо подробного объекта с описанием состояний и стектрейсом.

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

Исключения ловятся не всегда

А программы не всегда работают, давайте их запретим, или что?

new вернул nullptr, но мы это не проверили

это где new умеет возвращать nullptr?

edit: вообще не один ли хрен — не проверил на NULL, или не обработал exception? если память кончилась - все равно капец. ну да, бывает что из-за ошибки в данных ты пытаешься выделить например террабайт памяти. но это надо проверять еще ДО вызова new/malloc.

TL;DR если new вернул null, или кинул эксепшн — процессу капец в любом случае.

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

Так, и что будет, если я форкну либу и накачу на нее свой патч? Менять ее импорт во всех файлах ручками?

Скорее да, чем нет. Для среды твой форк это новый и самостоятельный пакет. И если ты хочешь его использовать, то и путь будет другим (что-то в духе было 'gh/user/libname', стало 'gh/loz/libname'). При большом желании, ты можешь просто в место сорцов user'а положить свои, и зажевать это дело. Тогда пути менять не нужно будет. Но такое тут будет грязным и не очень понятным костылём.

Поинт в том, явное лучше неявного.

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