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

Вами предлагают некий более навороченный Си

Шта? Скорее больше быстрый питон.

Скорее больше быстрый питон.

Шта? Питон по сравнению с этим просто меганавороченный язык.

Совсем разные языки. Python в разы более гибкий за счет отсутствия у переменных типов (можно стороннии линтеры добавить если нужна проверка типов, но это обычно делается на близком к готовности продукте, на устоявшихся частях). А здесь по сути типизация у переменных + отсутствие привычного для питоньщиков ООП, что по сути делает невозможным писать в питонячьем стиле многие вещи. А еще методология интерфейсов и практическая невозможность решить круговые зависимости из-за неправильной архитектуры проекта...

В общем Go ни капли не похож на Python и они вообще ни каким боком сравнены не могут быть из-за разности парадигм.

см LookupEnv

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

Нужны, чтобы

самоконтроль и втихую отрубленные конечности в случае его отсутствия

нормой не считались.

UB в operator* - это просто эпик фейспалм

У авторов крестов всегда был бзик, что самый короткий код должен быть самым производительным. Не хочешь УБ - юзай value().

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

Ну вообще-то да, это тоже идиотизм. Но

• Для bash это менее актуально ввиду гораздо меньшего размера типичного «проекта»
• Я могу обоснованно оценить подходы к дизайну полновесных языков, потому что имею хороший опыт использования разных языков в профессиональной деятельности. В области дизайна шеллов я не специалист, так что предложить хороший дизайн не могу. Я избегаю высказываться по вопросам, в которых не компетентен.
• Вокруг Go существует громадных размеров хайп. Это вызывает любопытство и желание подробней разобраться в вопросе. Когда же оказывается, что это не объяснимо весьма посредственными техническими характеристиками Go, то закономерно возникает удивление и недоумение.

Я и юзаю value. Но вопрос о повреждениях рассудка, из-за которых в 2016 году в язык вносится UB ради выдуманной экономии.

Про навороченость никто не говорил.

Тем не менее, на Go переходят именно с питона. И гугл его пропагандирует именно в этом направлении.

Я ни разу не видел рекламу Go от гугла, ее где-нибудь можно увидеть?

Слово «пиар» больше подходит?

да, правда, изза существования «нулевого состояния» примитивных типов, он тебе запихнёт везде нулевые данные, типа «» вместо строк, и твоя забота будет это ловить

+100500, прямиком из Python. Хайп вокруг Golang не обоснован. Просто забудь и пиши на ЯП, хватит ненужное палочкой шевелить, а то воняет

прямиком из Python

os.getenv(varname[, value])

Return the value of the environment variable varname if it exists, or value if it doesn’t. value defaults to None.

Бегом в Го, неосилятор!

Что не так, фанатик? Пустая строка и None это разные вещи.

Фанатик чего? Я и писал, что гошный дизайн к питоновскому отношения не имеет.

UB у basic_string<...>::operator[] при индексации за пределами length — это тоже эпик фейспалм?

Не готов к реальному программированию? Возвращайся на pascal, там всё контролируется.

Ок.

UB у basic_string<...>::operator[] при индексации за пределами length — это тоже эпик фейспалм?

По крайней мере, это решение было принято 20+ лет назад.

Не готов к реальному программированию?

Ты только не переживай за меня.

Возвращайся на pascal, там всё контролируется.

Контролируется много где. Печально, что ты остановился в своем развитии на уровне Паскаля.

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

Нет, только ты. При чём тут echo вообще?

user@host $ printenv LANGUAGE
en
user@host $ echo $?
0
user@host $ printenv UNDEFINED
user@host $ echo $?
1
user@host $ export EMPTY=""
user@host $ printenv EMPTY

user@host $ echo $?
0

По крайней мере, это решение было принято 20+ лет назад.

Сейчас код с проверкой границ, как и 20+ лет назад, будет медленнее чем без проверок. Ты не знал?

Сейчас код с проверкой границ, как и 20+ лет назад, будет медленнее чем без проверок. Ты не знал?

Сейчас процессоры стали гораздо быстрее, а потери от выхода за границу массива - гораздо больше, поэтому потратить немного производительности на безопасность - разумный размен. Ты не знал?

потери от выхода за границу массива - гораздо больше

Что ты имеешь сказать? undefined behaviour стал более undefined?

потратить немного производительности на безопасность - разумный размен.

Разумные люди (не ты) разумно потратили, выбрав подходящий инструмент. Только тебя до сих пор почему-то удивляет, что в C/C++ принято производительность ставить на первое место.

потери от выхода за границу массива - гораздо больше

Что ты имеешь сказать? undefined behaviour стал более undefined?

А у тебя undefined behaviour стало единицей измерения потерь? Вау.

потратить немного производительности на безопасность - разумный размен.

Разумные люди (не ты) разумно потратили, выбрав подходящий инструмент.

Когда вырастешь - поймешь, что выбор инструментов часто ограничен.

Только тебя до сих пор почему-то удивляет

О, начались телепатия и статистика.

Сейчас код с проверкой границ, как и 20+ лет назад, будет медленнее чем без проверок. Ты не знал?

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

У плюсов подход в духе «будет UB, если вдруг не доглядел». Можно, конечно, использовать at вместо [], но так мало кто делает, да и преимущества отсутствия проверок теряются.

А в расте наоборот - проверки есть по умолчанию есть, но можно их избежать. Конечно, можно ещё лучше.

Когда вырастешь - поймешь, что выбор инструментов часто ограничен.

Когда вырастешь — поймёшь, что выбор поведения в C++ часто ограничен.

Ни разу не видел пиар тоже. Ну может пару презентаций с обьяснениями нафига его сделали

printenv

т. е. ты в скриптах получаешь значение переменной через printenv? Или всё же через $VARNAME?

т. е. ты в скриптах получаешь значение переменной через echo? Или всё же через $VARNAME?

Сейчас процессоры стали гораздо быстрее

И вообще, вылези из криокамеры. Частоты с 2003-го не растут.

Сейчас процессоры стали гораздо быстрее

Частоты с 2003-го не растут.

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

А чем мерить, лалка? Глубиной конвейера и числом портов у ALU? Так там тоже всё встало и даже, как для частот, всё идёт обратно в сторону уменьшения.

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

А чем мерить, лалка?

Попробуй мерять линейкой.