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

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

Вроде дженериков. К примеру. Список можно длинный составить.

Ты про тестирование вообще слышал? Я бы тебя давно уволил.

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

А вот ты с какого языка перешел на go?

Слышал. Тесты не нашли баг. Тестеры просмотрели. В любом языке я склонировал либу, пофиксил, залил на продакшен за пол часа. Твои действия с го?

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

Да, можно. Помимо этого, это многие и делают. Этот путь это системная переменная, на которую смотрит компилятор при сборке. И если ты хочешь собрать с сорцов другого пути, ты просто перед билдом указываешь этот путь, и компилятор вытаскивает сорци с него. Было go build, стало GOPATH="$HOME/myproject/modules" go build.

c, python.

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

Так можно вообще все запретить.

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

Да вообще нормальный код не написать...

Но это не смертельно.

Ну-ну...

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

в гугловском stl для ондроеда

аналогичные. Баг в продакшене - срочный откат и фикс. Пересобрать с исправленой либой не rocket science.

python

Да, из них тоже приходят многие.

Но вот чтобы люди перешли с C++, Java или C#, к примеру, слышно крайне мало.

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

Или ты путаешь «нормальный» с «как везде», или ты не работал плотно с pip'ами и gem'ами (называю именно их с личного опыта). Про сипаны и прочее слышал только страшилки, но от коллег.

вообще импорт из мастера - это уже пушка и за это надо ссаными тряпками бить до просветления

Но в Go так принято, как я понимаю

в гугловском stl для ондроеда

без nothrow или --fno-exceptions это нарушение стандарта.

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

new(nothrow)

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

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

Да я так смотрю что половина го это грязные и непонятные костыли.

+1

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

Ага, и это хорошо. Привет рубистам. У них там одно и тоже можно сделать массой способов. Как правило из-за этого путаница в коде. Конечно они выходят из этого положения, запрещая на уровне «так мы пишем, а так не пишем». Сколько слез у рубистов было по поводу safe navigation operator.

И что? Делаю внутри проекта директорию vendor, в нее кладу исправленную версию либы и собираю.

ты не работал плотно с pip'ами и gem'ами

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

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

То есть импорты тебе править не надо?

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

Ну с C++ я бы давно перешел на что-то. Было бы на что. На go надеялся какое-то время, потом забил.

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

так мы пишем, а так не пишем

И не используем чужие библиотеки? Чтоб всё было одинаково нужно запрещать на уровне компилятора.

Нет.

new(nothrow)

это отдельный оператор. я чет думал, что речь об обычном new.

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

(hint: я слушал доклад людей из git in sky, у них большая инфраструктура с кодом на го, и они правили апишечку в одном модуле, автору которого это было не очень интересно, и им пришлось заменять везде импорты)

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

Если интересно, сам почитаешь.

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

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

Мы стараемся форки не плодить, а делать PR.

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

Зачем отдельного? Да, можно. Я использую GOPATH=~/gocode

Твои пороекты будут в ~/gocode/src/whatever/whatever/whatever

PS: глянул на свой tree -d ~/gocode/src | wc -l ;) 3990

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

У нас много всякой волшебной автоматизации с претензиями на гарантии. И когда тебе нужно разлить апдейты десятке тысяч разнообразных железок, и что бы все продолжили зарабатывать деньги - go закладывает за пояс всех, и жаб и змей и камни драгоценные. По стоимости интеграции продуктов (это и с инфраструктурой) - цена снизилась на пару порядков. Потому круто тут слушать что go говно, и годен он только для хэлловордов школоты: но на деле разработка, сопровождение, коммандная работа над проектами, явность какая-никакая - это его сильнейшие стороны (а это типа деньги, а деньги решают кто тут проект танцует, дешевый и работающй go или цацкели и C*(где даже за code style срачи не прекратились)).

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

PS: да, использовал слишком много, потому от них печёт сильно, когда слышу что это вау и золотой выход

Зачем отдельного?

представь себе ситуацию, что у тебя не 1, а 2 проекта на go.

представил?

теперь представь, что ты хочешь работать над обоими проектами на одном компе, под одной учетной записью (в одном $HOME).

но проектам нужны разные версии одних и тех же библиотек.

то что ты описал (GOPATH) практически такое же дерьмище как virtualenv в пистоне.

да, использовал слишком много, потому от них печёт сильно, когда слышу что это вау и золотой выход

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

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

Нет.

«Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone.

[...]

Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch.»

Как уже говорили, всё своё можно носить с стобой. Наример: Go 1.5 Vendor Experiment.

Ну и никто не мешает имеить 2, 3... много $GOPATH. (В принципе тот же pyenv.)

В принципе тот же pyenv.

и ты считаешь, что это хорошее решение, да?

Решается вендорингом.

значит тут я был не прав. Основывался на словах Пайка.

Приведенный тобой в пример npm с тоннами копий одной и той же библиотеки не намного лучше.

Основывался на словах Пайка.

Каждую ночь молишься Святому Отцу?

Приведенный тобой в пример npm с тоннами копий одной и той же библиотеки не намного лучше.

я не приводил никаких примеров с npm и тоннами копий. ты снова что-то перепутал.

Нет. А ты?

Внесу свои пять копеек. Импорты конечно то ещё говно, но жить можно. А вот идею с GOPATH так и не удалось принять. Пришлось подключить gb и юзать либы, как я привык, например в PHP с его composer. Тут еще ссылку давали на vendor experiment, надеюсь таки запилят подобное поведение по умолчанию.

А что касается, pip и virtualenv в python, то уже долгое время пользуюсь buildout и другим советую, там конечно тоже есть свои минусы, но всё же лучше, чем возиться с виртуальными окружениями.

Я не принадлежу к секте goвнопоклонников.

про npm без -g ты писал

ага, а остальное ты придумал.

А к какой секте ты принадлежишь?

что, например?

Свидетелей статической проверки типов.

все кроме слов «npm без -g»

Эту проблему, кстати, решает Nix с его development environments.