Что происходит с популярностью Go?

func main() {
	sm := &SafeMath{}
	sum := sm.Add(sm.Add(100, 200), 300)

	// all-or-nothing
	if sm.err != nil {
		log.Fatalf("overflow: %v", sm.err)
	}

	fmt.Printf("sum: %v\n", sum)
}

Какой же, прастихоспадя, ужос…

Вот тут то и мои претензии, когда вылезет парсинг еррор потом фиг поймешь на ком оно завалилось.

Возможно это моя личная заморочка.

Да. У раста дебильный синтаксис.

И самое главное у Go есть ниша, и уже полно прог. У того же Раста ниши нет, на нем пишут то что можно было и на с++ написать, но мозгов для этого уже не хватает.

Code folding - компромисс. Его сложно сконфигурировать правильно и он может скрыть лишнего.

IDE - это личный комфорт. У другого человека может быть отключен code folding. В GitLab/Slack/Confluence нет code folding и вряд ли появится. При совместном редактировании (через удалённый доступ или демонстрацию экрана) code folding будет мешать.

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

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

For what it's worth, я работаю с Go на текстовом редакторе из 1994 года и не замечаю трудностей, связанных с обработкой ошибок. То есть без подсветки синтаксиса, без code folding, без автодополнений и ещё без кучи того, сегодня модно.

сегодня модно.

извините а вы не знаете почему тот мой пример специально замолчали? Что я там не правильно написал?

Ну я не писатель на Go и Rust, только читатель :)

Иногда приходится заглядывать в проекты на этих языках чтобы разобраться как что-то в каком-то из проектов работает. Вот при чтении кода на Go постоянные if err != nil просто сразу же замыливают глаз.

Этот [1]? Наверное, потому что непонятно какую роль данный пример выполняет. Попросили проанализировать арифметику с проверкой на переполнения (когда int не может вместить нужное число). Вы привели пример деления на ноль.

Если что, в Go невозможно поймать переполнение паникой. При переполнении значение пойдёт по кругу, примерно как в целочисленной арифметике.

[1]: Что происходит с популярностью Go? (комментарий)

да ладно, как может замыливать глаза то что просто и понятно?

А вы случайно не знаете почему тот мой пример замолчали?

Попросили проанализировать арифметику с проверкой на переполнения (когда int не может вместить нужное число). Вы привели пример деления на ноль.

Да. Я просто не понял как реализовать конктретно : когда int не может вместить нужное число.

И показал деление на 0 для примера. Мне нужна реализация той ошибки я погляжу что мне с ней сделать.

Кратко суть ? из rust, что здесь пытаются назвать инновацией.

#define fwderr(expr...) ({ auto ret = (expr); if (ret.err) return ret; ret.val; })
result custom_sum(type a, type b) { return sum(fwderr(parse(a)), fwderr(parse(b))); }

> [«мощная обработка ошибок»] То, что позволяет писать sub(add(a, mul(b, c)), d) и при этом имеет нулевой оверхэд

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

> if s.err != nil на каждую операцию имеет ненулевой оверхэд

На небольшом масштабе, для Go это нормально.

> Мне нужна реализация той ошибки я погляжу что мне с ней сделать.

Это реализуется так [1]. То есть самому надо проверять и оборачивать в ошибку, в языке нет встроенной идентификации этого случая.

[1]: Что происходит с популярностью Go? (комментарий)

Немного личных впечатлений // другой аноним

Недавно писал на плюсах код без исключений. Подумал: нафиг все эти сложности - шаблоны, лямбды и т. п., сделаю обработку ошибок максимально тупо и понятно. Немного погонял варианты - пришел к возврату std::pair<Result, Err>. Ну, думаю, гоферы знали что делали.

Написал функцию, другую… Стало грустно. Там логики-то - делай раз, делай два. Иногда три. А функции размазываются раза в два-три. Ага, в духе if (err) return { nullptr, err };

Попробовал переписать на expected - как глоток свежего воздуха. Код короткий, четкий, вот то что нужно: делай раз, потом два, иначе три. Таки есть синтаксический оверхед - заворачивание в лямбды, списки захвата, и пишется сложнее, иногда приходилось помучать компилятор, пока типы сойдутся. И всё же читаемость куда лучше: бойлерплейт в виде скобок пропускается, как у лисперов, остается чистая логика.

Под такое определение, если я не ошибаюсь, даже Rust не подходит.

Не ошибаешься. Всё что есть в rust - попытка замести проблемы под ковёр. if err return по сравнению с ? лучше.

Хотя обсуждалась, вроде бы, только выразительность.

Я уточнял этот момент изначально:

В языке с мощной обработкой ошибок это выглядит так же, как и обычная арифметика без проверок: sub(add(a, mul(b, c)), d) //a + b * c - d и имеет нулевой оверхед.

и имеет нулевой оверхед

Недавно писал на плюсах код без исключений.

без исключений.

Ну ты отстал от жизни лет на 15-20. Можешь посмотреть на те же go и rust: оба имеют эмуляцию исключений, признавая низкое качество других механизмов. В общем, странные у тебя впечатления.

Вообще не в кассу. Исключения у меня кидаются там где уместны, на hot path они забанены. Фанатизм в них - вот что веет 90-ми.

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

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

Исключения у меня кидаются там где уместны, на hot path они забанены.

Не сходится.

на hot path они забанены

Т. е. там, где они проявляют часть своих преимуществ? Опять не сходится.

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

И поэтому ты забанил один из вариантов? Снова не сходится. А разницы между expected и {val, err} в плане выразительности никакой.

Не понял, что у тебя не сходится. Но вообще адресовал пост сторонникам идеи, что гошная обработка ошибок удобна и легкочитаема.

При этом отчасти могу их понять. Мой код получился плотнее, семантически сложнее. Но я всё еще нахожу его более читаемым. А в каком-то смысле тут размен, будет код раздут по горизонтали или по вертикали.

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

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

P.S. Я так понял примеров той фигни не будет, а жаль :( Одна болтовня :(

При этом отчасти могу их понять. Мой код получился плотнее, семантически сложнее. Но я всё еще нахожу его более читаемым.

Текст песни Швондера со товарищи в фильме «Собачье сердце»

Суровые годы уходят.
Борьбы за свободу страны.

За ними другие приходят
Они будут тоже трудны.

А существует пример программы, где бы именно тормоза от проверок err != nil были бы серьёзной проблемой? Мне мама говорила, что прежде чем начать чего-то ускорять, нужно сперва выяснить, а где оно тормозит.

Да, попадался мне такой пример, правда очень давно. Это была MPI программа с очень интенсивным и креативным использованием возможностей MPI (пользовательские типы, неравномерные области памяти, хало организовано в виде типа, структуры в Send/Recv). Я такие программы называю «студент пытался втиснуть максимально разнообразное подмножество стандарта». Каждая функция вызывала интенсивную проверку на корректность.

Ну тот есть с дури можно и член сломать.

где бы именно тормоза от проверок err != nil

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

Ну так и чего это обсуждать тогда?

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

Да и если б по результату «интенсивной проверки на корректность» бросали исключение вместо возврата ошибки, то оно бы тормозило точно так же.

Не уверен, что это вообще такое - применительно к бинарнику - перехват исключения? Это еще нужно поглядеть что там компилятор нагородит в коде чтобы осуществить этот перехват исключения то.

это был мой ответ тому челу.

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

Я это понял как событие и его обрабатывает перехватчик события.

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

Или повышает читаемость для сопровождающих как и примечания.

Я это понял как событие и его обрабатывает перехватчик события.

ну вот же, в этом случае как минимум перехватчик должен куда то долбиться всегда. (слушать)

Бездумное? Сомневаюсь. У вам на каждый вызов фунции сначала будет проверка всех возможных и невозможных допусков на типы, значения, и пределы всех аргементов и глобальных переменных. До действия собственно функции дело не дойдёт.

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

какая еще куча проверок ?

Просто вызываешь функцию а потом проверяешь не ошибку ли она вернула. Все !

А если покреативить с бездумностью и возвести проверки в абсолют?

Вы чего такой нервный? Суббота же!

Вы чего такой нервный? Суббота же!

извините.

Если вообще заботишься о производительности,

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

Насчёт «сдуру что-нибудь сломать себе», тут полностью согласен.

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

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

Ты тоже ламерок, ведь именно ветвления и прочая динамика и создают 90% стоимости.

Я там давал выше пример на арифметику с проверками - sub(add(a, mul(b, c)), d). Реализуй читаемый вариант. Просто проверка и всё.

Ты тоже ламерок, ведь именно ветвления и прочая динамика и создают 90% стоимости.

Как говорится, вы можете написать 100 раз что 90% времени выполнения кода,

я могу написать 100 раз что 0.10% времени выполнения кода.

Ну это нормально. (и лучше воздержаться от личных оскорблений)

ссылку точную в студию.

А может это как раз тот самый что до сих пор не может конкретику написать после вброса про sub(add(a, mul(b, c)), d)? Если вы то код в студию.

Я там ниже дал конкретный код, вбивай, компиляй - гляди. Так что попрошу код в студию. Как говорил Мопосан - ближе к телу.

Поплыл.

Я там ниже дал конкретный код

Это ты что-ли тот ламерок, который запостил это (linux.org.ru)? Читаем внимательно:

Просто попробуйте на if err return выразить хотя бы арифметику с контролем переполнения

if err return

Что реализует конкретный код ламерка?

recover();

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

Что реализует конкретный код

Мой код копируется и компилируется. И это не про арифметику с контролем переполнения. Я это показал для примера.

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

Так понятнее?

Я сомневаюсь, что можно быть настолько ламерком, чтобы не понимать свою ошибку. И в качестве примера кода с if err return выкатывать код с исключениями и без if. Поэтому тут скорее всего несознанка началась.

который по вашим словам нельзя реализовать на go

Бегом за цитатой.

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

ну так что будет код или вы просто троль?

Да, пациент полностью невменяем. Видимо попробовал достать цитатку и не смоглось. Поэтому началась крайняя стадия «троль».

ну так что будет код

Тут совсем гениально, ведь sub(add(a, mul(b, c)), d) - это и есть код, причём адаптированный под go, иначе я сразу бы написал a + b * c - d.

Тут совсем гениально, ведь sub(add(a, mul(b, c)), d) - это и есть код, причём адаптированный под go, иначе я сразу бы написал a + b * c - d.

не фига вас не понял, попробовал сейчас на go:

result := a + b*c - d

работает.