Go с треском пробивает днище

2013-06-09
Go (1.1)

Дальше не читал.

http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/

2013/06/09

Breaking news!

https://www.linux.org.ru/forum/talks/10191450

func Getenv(key string) string

Getenv retrieves the value of the environment variable named by the key. It returns the value, which will be empty if the variable is not present. 

По крайней мере в этом аспекте ничего не изменилось

Documented: https://golang.org/pkg/os/#Getenv

Getenv retrieves the value of the environment variable named by the key. It returns the value, which will be empty if the variable is not present.

Быдлокодеры должны страдать.

И? В документации поведение описано, чувак в коде ничего не проверил, код сломался. Это правда проблема языка?

Задокументированный идиотизм оным быть не перестаёт оттого, что задокументирован.

Это правда проблема языка?

Да, это крайне паршивый дизайн.

Строгое соответствие реализации заявленной документации — идиотизм? Обоснуй.

Назови не паршивый.

Строгое соответствие реализации заявленной документации — идиотизм?

Где я такое утверждал?

Обоснуй.

Идиотизм — возвращать валидное значение для индикации ошибки.

Назови не паршивый.

Возвращать опциональное значение, конечно же.

Ой, стойте, опций в Go нет и не будет, ага.

А чем это оно не валидное ? Переменной нет ? Значит пустая строка, вполне логично, че.

А если переменная содержит пустую строку?

Если тебе хочется именно узнать, есть ли такая переменная - os.LookupEnv(key)

os.LookupEnv(key)

Два вызова и условие вместо одного. В языке, претендующем на звание современного.

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

Go сможет отличить такой вызов

$ MY_VAR='' my-app

от вызова

$ my-app

?

UPD. Уже увидел lookupEnv, можно не отвечать.

Два вызова и условие вместо одного.

Не, вызов один. Прост Getenv для хипстеров, а LookupEnv - для интырпрайзных хипстеров, даже по названию понятно.

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

Совсем говнокодеры обнаглели. А зачем так важно знать существует ли пустая переменная? Ну нет ее, значит ведем себя как будто она есть и пустая. Очень логичное поведение будет.

Ага. Тогда в случае с LookUpEnv дно пробито уже не с таким громким треском. С обычным Go-шным уровнем треска, я бы сказал.

val, exist := os.LookupEnv("MY_SUPER_VAR")
if !exist {
   ....
}
... use val ...

В общем, вброс не удался.

Слишком уж безапелляционное заявления на основе вывода об одной функции.

Логику такого подхода тоже можно понять.

Совсем говнокодеры обнаглели. А зачем так важно знать существует ли пустая переменная? Ну нет ее, значит ведем себя как будто она есть и пустая. Очень логичное поведение будет.

Логичное, ага:

FIRSTNAME='' some-user-creation-stuff # I want an empty name
some-user-creation-stuff              # Ask me

или вот так:

KERNEL_MODULES='' generate-initrd # Do not use any kernel modules
generate-initrd                   # Use the default set

Язык, разработка которого началась в 2007 году, никак не надаёт по рукам, если забыть проверить, вернулся ли true вторым полем результата в случае LookUpEnv и вообще вернёт валидное значение при отсутствии пременной в случае GetEnv. Ещё немного, и язык, разработка которого началась в 2007 году, догонит по безопасности и удобству другой язык, разработка которого началась в 1969 году.

Логику такого подхода тоже можно понять.

Логика как раз понятна. Для таких случаев нужны опции, для реализации опций нужны дженерики, дженерики в Go не нужны, поэтому опций не будет. Но такая логика ведёт к паршивому дизайну всего языка. GetEnv тут только частный случай.

Прост Getenv для хипстеров, а LookupEnv - для интырпрайзных хипстеров, даже по названию понятно.

Я правильно понял: GO используют только хипстеры?

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

А когда она остановилась?

Она не остановилась, насколько мне известно. Последний стандарт вышел в 2011 году.

Ну как вариант при отсутствии опций — исключения. Ой.

Домашку сделал?

Нет конечно. А зачем?

Она не остановилась, насколько мне известно. Последний стандарт вышел в 2011 году.

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

Возьми Haskell уже и не ной.

Для таких случаев нужны опции

Не нужны, кортежа (value, error) достаточно.

Что касается GetEnv и LookupEnv, то отлично, что есть оба варианта. Какой нужно, такой и используем. А документацию читать полезно всегда. Go подразумевает, что ты даже самый последний Close проверяешь на err.

Можно для Ъ версию?

Для таких случаев нужны опции

Не нужны, кортежа (value, error) достаточно.

Недостаточно, кортеж допускает обращение к не определенному полю.

Не нужны, кортежа (value, error) достаточно.

Что тащит за собой целый ворох недостатков:

• Уже упомянутая возможность обратиться к полю, которое не определено
• Проигнорировать наличие ошибки проще, чем проверить
• Необходимость двух функций для одной и той же цели, если мы не хотим при каждом использовании писать boilerplate-код, что нарушает принцип неумножения сущего без необходимости
• При этом, одна из упомянутых функций имеет умолчание, никак не отражённое в сигнатуре, что нарушает принцип наименьшего удивления
• Необходимость наличия в языке такой пакости, как нулевые указатели для маркировки неопределённого значения
• Тупо больше кода писать, чем при использовании опций

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

А в том же C++ std:optional весьма уместен.

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

Мы сейчас о том, что в этом языке идиотские нормы.

А в том же C++ std:optional весьма уместен.

std::optional<std::string>, конечно, лучше, чем пустая строка, но UB в operator* - это просто эпик фейспалм.

Вообще, люди постоянно забывают, что авторы Go не предлагают вам эргономичный безопасный язык, впитавший самые современные веяния и т.п. Вами предлагают некий более навороченный Си, где вам дали замыкания, способ безгеморройно юзать интерфейсы и возможность не следить пристально за памятью (но следить всё же надо). Всё. И есть люди, которые это воспринимают, и им нравится. Кто-то любит комфорт и гуляет в парке по дорожкам, а кто-то шатается по походам, «возвращается к истокам», и в этом его кайф.

И? В документации поведение описано, чувак в коде ничего не проверил, код сломался. Это правда проблема языка?

Двойные стандарты детектед. Подобные «фичи» похапе на полном серьёзе считают именно проблемой языка.

Жырновато, браток.

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

Ищешь повод не изучать очередной ЯП? :p

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

https://golang.org/pkg/syscall/#Getenv

import syscall
import os

func init(){ 
    value, ok := syscall.Getenv("BISCUIT")
    if !ok {
        fmt.Println("Where is my tasty variable?")
        os.Exit(-1)
    }
}

...

Так же можно использовать https://golang.org/pkg/os/#Environ который отдаст копию map с переменными окружения, а зная как получать значения из map у вас не составит труда выяснить есть ли переменная такая или нет.

PS. Всем сыру!

beastie

О, не знал про него, но внутри он по сути использует мое решение :)

func LookupEnv(key string) (string, bool) {
	return syscall.Getenv(key)
}

Кстати есть неплохие примеры того как то или иное действие делается в Go.

https://gobyexample.com/environment-variables

Как отличить переменной нет от в переменной пустая строка?

Идиотизм — возвращать валидное значение для индикации ошибки.

$ echo $nonexistent

$ echo $?
0

Разработчики Bash тоже идиоты?