Для таких редких случаев

Что вы за код такой пишите-то?

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

Зачем вообще нужен язык без дженериков? Впрочем, Go и дженерики не помогут.

Видимо, тебе бесполезно говорить, что с помощью Go люди зарабатывают хорошие деньги.

Поддерживаемость

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

гораздо большие деньги.

fixed

А с помощью грабежей и убийств

Опасно и ненадежно, если ты не матерый профи.

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

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

Го-код содержит меньшее число ошибок чем популярные языки прошлого поколения

Жду ссылку на исследование.

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

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

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

Это всё-таки немного отличается от твоего первоначального утверждения и не противоречит моему, не находишь?

Multiple-value in single-value context и unused variable. То есть если функция возвращает что-то важное и err, то забыть про ошибку практически невозможно.

_ приходит к нам на помощь.

-unusedresult? Там можно конкретно Println добавить в исключения (или это сделано по умолчанию), все равно никто не знает, как такие ошибки отрабатывать.

Почему не знает? Распечатать причину ошибки в stderr и завершить выполнение с кодом -1 в случае ошибки. Такое даже в Java будет работать, причём автоматически, с нулевыми усилиями со стороны разработчика.

Вроде panic выдает трейс, всякие проблемы с тредами вроде тоже. Если error нормально обработался, трейс ему и не нужен.

Ну вот вызвал я какую-то функцию, она мне вернула error. Я хз, че за error, распечатать его в лог со стектрейсом и грохнуться со всей силы. А стектрейса нет. Какой-нибудь «Error occured» в логе будет и сиди вкуривай в какой из миллиона строк она произошла.

При создании ошибки (error).

Обработка исключений порождает слабочитаемую лапшу в коде не хуже goto.

Не порождает. Обработка исключений на порядок читабельней обработки ошибок через коды возврата.

При этом unchecked-исключения ещё и никак не отражаются в сигнатуре функции, что и приводит к тому, что про их обработку забывают.

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

Да и checked вариант провоцирует пофигистический подход к исключениям.

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

Нормальный подход — это как раз монада Try, которая позволяет всё то же, что и выброс исключений, но свободна от недостатков этого подхода.

Не знаю, что такое монада, но у исключений недостатков нет.

Для своего кода легко получить backtrace в ошибках:

https://docs.rs/error-chain/0.11.0-rc.2/error_chain/#principles-of-error-chain

А нужно для всех ошибок. Ну ладно, получение стектрейса это операция с нетривиальной стоимостью, Rust-у это можно простить, но не жирнющему Go.

но не жирнющему Go

Уровень неадеквата в треде растет. Занятно.

Обычно уводит нас на уровень выше (на 10 уровней выше). И там мы уже не имеем доступа к изначальным данным, и не может восстановиться.

У вас очень странное представление об обработке ошибок.

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

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

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

Так вот парсер может быть огромным, с кучей уровней вложенности и тд. Вы предлагаете все ошибки вручную пробрасывать, простынёй из if-ов?

В этом парсере нечего обрабатывать «на месте». Любая ошибка должна быть проброшена наверх.

Но исключение в духе «NetConnError» малоинформативно.

Исключения - это не просто имя. Это объект. Он может содержать какую угодно информацию. В том числе и «на каком этапе разорвалось соедиенние».

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

То есть «не на месте», а уровнем выше? ЧТД.

потом забить на обработку ошибки

Можно пример?

Почему Rust написан на C++

Rust написан на Rust.

Поддерживаемость

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

В Го заработать те же деньги гораздо проще

А на JS ещё проще. Но это не делает JS хорошим языком.

Можно пример? Это в Java так? Я просто такого не встречал, но это же до смешного дорого получается.

но у исключений недостатков нет

Лул.

_ приходит к нам на помощь.

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

Почему не знает?

Потому что в Println обычно используют для диагностики, если stdout накрылся, то можно забить; подозреваю что 99% вызовов printf в C не проверяют код возврата, и не потому что забывают.

В любом случае поведение go vet задается флагом. Я не помню, какое умолчание.

Ну вот вызвал я какую-то функцию, она мне вернула error. Я хз, че за error, распечатать его в лог со стектрейсом и грохнуться со всей силы.

Ну как раз panic помогает в таких случаях. Ну или debug.Stack(). Еще есть библиотеки для логгирования, которые умеют stacktrace из коробки.

Можно пример?

Пример чего? В Go например есть пакет github.com/pkg/errors, позволяющий получать стектрейс при создании ошибки, без него вменяемый код на Go писать малореально. Но естественно это работает только там, где ошибку создают при помощи этого пакета.

Это в Java так?

Да, по умолчанию так.

Я просто такого не встречал, но это же до смешного дорого получается.

На практике ошибки происходят редко и на общую производительность это не влияет.

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

А ещё есть такое понятие, как то, насколько бросается в глаза такой игнор. `_` это один символ, причём из вызова совсем не очевидно, что там была ошибка, а не просто ненужный выходной параметр. А чтобы проигнорировать исключение — тут нужен целый ритуал.

Потому что в Println обычно используют для диагностики, если stdout накрылся, то можно забить; подозреваю что 99% вызовов printf в C не проверяют код возврата, и не потому что забывают.

Странная логика. 99% консольных утилит используют stdout не для диагностики, а для вывода информации. То, что в C не проверяют код возврата, это хороший аргумент к тому, что это просто плохая система обработки ошибок. В большинстве кода на C и malloc-и не проверяют по той же причине: слишком муторно, проще грохнуться и сказать юзеру, чтобы не страдал фигнёй и поставил побольше памяти.

Ну вот вызвал я какую-то функцию, она мне вернула error. Я хз, че за error, распечатать его в лог со стектрейсом и грохнуться со всей силы.

Ну как раз panic помогает в таких случаях. Ну или debug.Stack(). Еще есть библиотеки для логгирования, которые умеют stacktrace из коробки.

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

Примерно так (возможны ошибки, но в принципе это реализуемо):

let mut post_id = -1;

loop { // receive new posts
  let new_post_id = read_new_post_id();
  match new_post_id {
        Ok(id) => {post_id=id},
        Err(e) => println!("There was a problem: {:?}", e),
  };

  do_something(post_id);
}

Никто не спорит, что на rust так писать нельзя. Но и на go как в примере выше писать нельзя. По сути ошибку проигнорировали.

Да, если что Rust более безопасный язык, чем go. Но у всего есть цена. Например, мне для моих задач нужна структура специальное дерево с указателями в обе стороны и дополнительными индексами; на rust такое писать намного сложнее, чем на Go.

позволяющий получать стектрейс при создании ошибки

Так это не стектрейс. Мы же его вручную задаём. А значит он неполный.

Да, по умолчанию так.

Вы про ошибку или исключение? Исключение и в Rust, и даже в C++, выдаст стектрейс.

насколько бросается в глаза

Мы что сейчас про диверсии предыдущих разработчиков говорим? Ну давайте обсудим плагин для компилятора Rust, который вводит римские числа.

Проигнориорвать исключение в C++ или Python просто тривиально.

malloc-и не проверяют по той же причине

А что в языках с прекрасными новыми исключениями как-то иначе?Например Java от Orcle машина просто вылетает с ошибкой :) Игнорируя ulimits, кстати.

Или в rust часто проверяют panic, вызываемый println? Почему же они не сделали Option или Result?

panic не поможет, потому что в этом месте стек уже будет давно потерян

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

Ну это сверх-искусственный пример. Такое в Rust не встретить. В то время, как для Go это нормальный код.

Почему же они не сделали Option или Result?

Сделали. writeln!()

В каментах каждый второй плюется от tokio. По крайней мере от tokio-proto и tokio-service

tokio - глубокая альфа.

Самая точка! Где сейчас география его востребованности (кроме кулуаров гугла)? Баловаться левыми синтаксисами было интересно в прыщавой юности, но когда тебе за 30 разбирать еще одно проходное овно нет никакого желания

Вот мне как раз «за 30». Давеча ездил в Кремниевую Долину. Перетёр там с некоторыми ребятами. Так вот там к Го относятся уже как к мейнстриму. Там Го выстрелил, это факт. И выстрелил не только в Гугле, но и во многих других крупных копаниях. Например, на нём написан бэкенд для Убера. И сейчас ЗП для Гоферов там выше, чем, например, для плюсеров с их навороченными последними стандартами. Я вот приехал и сам решил попробовать. Изучил. За неделю, как везде говорят. Ещё за неделю переписал свой проектик на Го с Перла 5-го. Го оставляет крайне положительное впечатление.

Го оставляет крайне положительное впечатление.

Добра тебе, благоразумный анонимус.

Далеко ходить даже и не надо, ведь и в РФ его используют VK, Mail.ru, Yandex, Tinkoff

Исключения - это не просто имя. Это объект. Он может содержать какую угодно информацию. В том числе и «на каком этапе разорвалось соедиенние».

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

В 1% общей кодовой базы проектов.

Я тоже так полагаю. Но кроме моих представлений есть еще реальный мир, в котором это не так

Для таких редких случаев существует уже несколько генераторов кода на замену дженерикам

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

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

+1 под каждым словом.

Я вот только что вернулся с прекрасной конференции C++ Siberia 2017. Мне там запомнились два момента:

1. В спеку языка для стандарта С++17 добавили 200+ страниц. В итоге сейчас драфт стандарта 1600 страниц. Для сравнения вся спека на Го - 100 страниц. Это значит, что плюсеру, знающему стандарт С++14 вдвое сложнее освоить стандарт С++17, чем изучить Го с нуля. А если ты не пишешь постоянно на С++17, то всё равно будешь половину его фич забывать и потом долго втыкать в код, не понимая что тут написано. Там почему-то ребята думают, что уменьшение числа строк за счёт усложнения синтаксиса языка - это хорошо. Ещё меня повеселило, что регулярным вопросом докладчика к аудитории (а это явно не самые последние С++-программисты) был следующие: «Кто понимет, что у тут написано на слайде?». По-моему это сигналы о вырождении языка.

2. Несмотря на такой сложный синтаксис С++, некоторым товарищам возможностей языка не хватает, и они решили ещё больше усложнить его, попытавшись добавить туда велосипед (о чём они честно признались) с реализацией концепции каналов в Го. В итоге получился код страшный как смерть. Почему было не взять готовый Го понятно только адептам С++.

А они должны были переписать сразу весь код, который до этого писали десятилетиями? Ты в школу уже подготовился, смотри, не пропусти 1-е сентября.

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

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

Дружище, ты меня как-то невнимательно читаешь.

В то время, как для Go это нормальный код.

Не согласен. Нормальный Go код будет либо пробрасывать ошибку дальше (return err), либо присваивать какой-то safe default, либо делать panic.

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

Абсолютно на любом языке можно написать такую утилиту перемещения файла. На rust с использованием match, на c++/python/java с исключениями.

copy_file(src, dst)
if error:
  print('error creating new file')
delete_source_file(src)

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

Пустой трёп.

Это всё-таки немного отличается от твоего первоначального утверждения и не противоречит моему, не находишь?

Нет. В ходе беседы моё мнение не поменялось. И тут два варианта: а) ты намеренно цепляешься к словам, тогда ты хам, б) ты не разобрался с тем, с чем споришь, тогда ты - ?

Впрочем, главное что мы определились с хорошими методами обработки ошибок.

Угу. Собственно об этом и речь, обычно считается, что println сработает; при желании можно сделать проверку ошибок (в Go в том числе).

неверное гугл пилит и переходит на Го не от хорошей жизни с другими языками...

Но ведь имея только Rust тулчеин и исходники Rust тулчейна нельзя собрать Rust тулчейн: нужен ещё компилятор C++ с исходниками llvm, которые прикреплены к офф репе rustc. То есть Rustc не существует без C++. На Rust написан только компилятор Rust -> llvm ir (который скорее всего использует libllvm чтобы сразу собирать llvm ir в ast вместо текста), но даже так от самого по себе llvm ir толку мало ведь его никак нигде не запустить кроме как в виртуальной машине, которая тоже часть llvm, поэтому говорить «Rust написан на Rust» подразумевая «Rust -> llvm ir» часть компилятора не такой уж и большой повод для гордости, и незнающим человеком воспринимется совсем по другому (неправильно).

Да и для комуникации с системой самый крутой и безопасный на свете системный язык внезапно использует libc, которую в 99% случаев представляет решето glibc. То есть не no_std Rust программы ещё и немного C программы.

Кароче Rust не написан только на Rust и язык он пока не очень самодостаточный.

Rust написан на Rust.

Да - заметил, как только открыл архив с исходниками. Оказывается это сборщик Rust'а столько времени он порт LLVM40 под себя пересобирал - недостаточно уже установленного LLVM.

Для сравнения толстоты:

rustc-1.19.0-src/src - 33 310 объектов, всего 236,5 МБ.

go/src - 5 042 объекта, всего 46,1 МБ.

Что-то и тут растоводов можно по пальцем одной руки пересчитать https://highloadcup.ru/rating/.

Причем Rust только в 10 вошел и целых два Golang в 5 лучших.

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