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

Человек меняющий свободу на «строгие гарантии» не заслуживает ни того, ни другого. (с)

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

Согласен.

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

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

С отсутствием исключений, похоже, придётся смириться.

Тяжело. Видится возврат в Си(да, я знаю про алгебраические типы, Option, Result, try!, но по сути-то это мало меняет дело, смотрится как костыль с синтаксическим сахаром).

С++ ведь тоже местами «уменьшает свободу», особенно если с динамическими языками сравнивать, да даже если с С

Ну с динамическими языками я бы сравнивать вообще не стал. А вот в плане С, C++ никаких возможностей, по сути, и не урезает. Ругается/предупреждает об ошибках, убирает часть неявных преобразований и пр., но не запрещает явных. В Rust же нам вообще урезают возможности по ссылкам, дабы мы в принципе не смогли накосячить. Это именно «недоверие».

смотрится как костыль с синтаксическим сахаром).

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

В Rust же нам вообще урезают возможности по ссылкам

unsafe и кастуй что хочешь куда хочешь. Имхо, это «просто» ещё один шаг в сторону «предупреждает об ошибках, убирает часть неявных преобразований».

unsafe и кастуй что хочешь куда хочешь

Так это бессмысленно. Я лучше тогда просто C++ возьму=)

это «просто» ещё один шаг в сторону «предупреждает об ошибках, убирает часть неявных преобразований».

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

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

можно это делать встроенными средствами языка

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

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

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

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

Конкретно про go - он изначально коммерческий, с моей точки зрения. Чтобы слабые программисты в гугле тоже могли писать. Снижение затрат на разработку. А за счет того, что он компилируемый и достаточно быстрый - даже слабо оптимизированный код будет работать с приемлемой скоростью. Встроенная система тестирования, компилирование в статичный бинарник - этакий комбайн для упрощения разработки.

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

Лично мне от этого особо ничего. Потыкаю его - может чего полезного выйдет. Не выйдет - ну и пусть. Многообразие жизни) Будет не нужен - сам загнется.

Инженерной составляющей отрасли от него не много толку. Но он и не для них разрабатывался.

Подрастающему поколению - неплохой инструмент для разработки интернет-приложений.

Если go окажется хорошим в разработке интернет приложений - может потеснит такие вещи, как php, rails, django.

У исключений тоже свои проблемы есть.

Исключения зло, но то что я вижу в расте это такая жопа... Матчинг резалтов это же как колбек-хелл, просто мрак. Кстати, можешь объяснить, почему нельзя просто возвращать tuple с ошибкой? Все равно же этот Result приходится хитрожопно распаковывать каждый раз.

Я считаю, что go попытка совместить скорость разработки на скриптовых языках со скоростью выполнения на компилируемых языках.

Но у него не получается. Абстракции убогие, выразительности ноль. Позволяет только не приходя в сознание генерить бойлерплейт со скоростью пальцев. Матерые сишники и ветераны похапе4 оценят конечно.

Скоро придет эдик и будет кричать на нескольких страницах от ужаса.

Я понятия не имею, что такое «гуланге», и мне насрать!

// Eddy_Em

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

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

Потому что unwrap() гарантирует панику в случае, если ошибка произошла там, где программа её не ожидает, и не даёт воспользоваться результатом без проверки ошибки. И функции не надо думать, какой бы результат вернуть, если ей надо вернуть ошибку.

Так это бессмысленно.

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

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

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

Кстати, можешь объяснить, почему нельзя просто возвращать tuple с ошибкой? Все равно же этот Result приходится хитрожопно распаковывать каждый раз.

Если возвращать tuple, то мы потеряем все преимущества подхода. А зачем каждый раз распаковывать? Возможно, я не понял твою идею: ну вот вернула функция ошибку - что предполагается делать? Если мы хотим её сразу обработать, то «распаковывать» матчингом вполне удобно. Если просто пробрасываем на уровень выше, то и матчить не надо.

Если гитхаб накроется

Харе тупить. Твой npm сначала ломиться на один сервак за метаинформацией, потом ломиться на тот же гитхаб за тарболом. Что сказать-то хотел?

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

Не смотря на бытуещее в этом треде мнение сам import «что-то там» ни на какие удаленные сервера не ломиться и ничего никуда не качает.

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

Почему? В данный момент не удалось выделить память. И всё. Весь процесс в целости и сохранности. Если через секунду какой-то соседний пожиратель освободит свою память, можно продолжать. Вот только так нетипично решать с повтором. Но это просто ошибка при вызове какой-то функции, которая вызвала new. Ошибка могла быть и другой, и это не означает, что она приведёт к завершению всего приложения.

(уже отвечал на такой же вопрос в треде)

Твой npm сначала ломиться на один сервак за метаинформацией, потом ломиться на тот же гитхаб за тарболом.

Не, все тарболы на npm. Того что у тебя лежит в node_modules достаточно для того чтобы поднять зеркало для своего проекта минут за 30.

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

Но всё равно не понятно, почему вреда?

от повторения ответа понятнее не станет, увы.

по надежности, когда происходит неизвестное, нет ничего лучше быстрого завершения процесса

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

Память не заканчивается просто так. Скорее всего она закончилась из-за бага приложении, которое теперь творит чёрти что и жрёт память как не в себя.

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

Да? А откуда npmjs берет оригинальные тарболы? Все на гитхабе хостится. Просто меня улыбнуло как аноним тащиться от npm, в контексте, что вы все делать будете когда гитхаб похерится. А так-то у меня тоже все в $GOPATH лежит.

А откуда npmjs берет оригинальные тарболы

Автор приходит и делает npm publish. Когда гитхаб похерится ты можешь делать новые релизы на npm.

Непонятно, почему в import указан автор библиотеки и сервер хоста. Вот в чём вопрос.

Ладно ещё автора записать в файл проекта, но в пути зачем тащить, непонятно. Тем более - сервер хоста пакета. Вот что что, а это не уникально и один пакет должен легко менять репозиторий.

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

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

Поставил gb, тут как раз все так. Но либы форкать все равно трешово

При форке всё равно требуется переименование?

При форке проекта с gb — нет, не потребуется.

А с чем проблемы тогда?

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

Что будет, если сделать go get bitbucket.com/somerepo? Он также будет создавать bitbucket.com/somerepo/projectname...?

да

вообще, в gb нужно делать gb vendor fetch bitbucket.com/somerepo/somelib

и он положит это в vendor/src/bitbucket.com/somerepo/somelib

но хоть в самом проекте импорты адекватны

Мда, жаль что go get не ложит в системный GOPATH просто ./src/somelib и ./bin/somelib.