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

(на всякий случай docker это анахронизм, с которого давно уже, все кто в теме, слезли)

А вообще все правильно, я про это выше писал:

 if err != nil {
        return err
    }

Это должно быть внутри а не снаружи.

Да я давно подозревал, что выбор в пользу Go – это диагноз. А выступления адептов Go в этой теме лишь больше в этом убеждают.

Мое личное мнение,

(я уже это писал здесь)

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

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

Хотя теперь с появлением ИИ становится уже пофигу на синтаксис языка, главное понимать принцип и логику а закорючки(операторы) тебе ИИ подскажет. Так что сейчас адпеты каких нибудь Рустов, которые годами изучали ЭТО, идут лесом. Любой чел представляющий логику работы проги и т.д. может писать на любом языке!

оскорбления не нужны

Это была досада.

[Docker Compose] ж, вроде как, одна из икон того, что сделано на Go.

Примерно как Notepad++ икона того, что сделано на C++.

Чтобы быть нейтральными, оставим Docker Compose, но добавим ещё, к примеру, Caddy [1].

Только что произвёл подсчёты:

Docker Compose: 722 функции, возвращающие ошибку, 5,212 возвратов, учитывающих ошибку, и 835 простых «return err.»

Caddy: 920 функций, возвращающих ошибку, 9,208 возвратов, учитывающих ошибку, и 688 простых «return err.»

Это даёт право утверждать, что «return err» - это нечастый метод.

Команда Go ранее уже приходила к подобному выводу:

«We recently scanned all the open source projects we could find and discovered that this snippet [if err != nil {return err}] occurs only once per page or two, less often than some would have you believe.» [2]

Считал так:

# no of err-ret funcs
% find . -type f |9 grep '\.go$' |cat `{cat} |9 grep '^func' |9 grep 'error.? {$' |wc -l

# no of err-aware rets
% find . -type f |9 grep '\.go$' |cat `{cat} |ssam -e 'x/^func.+error.?.{\n([^}].*\n|\n)*}\n/' |9 grep '^	*return( |$)' |wc -l

# no of ret err
% find . -type f |9 grep '\.go$' |cat `{cat} |9 grep -n '^	*return.* err$' |wc -l

[1]: https://github.com/caddyserver/caddy

[2]: https://go.dev/blog/errors-are-values

Docker Compose

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

Т.е. чтобы фронтенд docker-compose работал нужно чтобы в системе был бакенд докер или подман.

Это я к тому: может лучше искать ЭТО в докере или подмане?

1С - вполне коммерчески успешная система, невзирая на. И язык там вполне даже нормальный. Я имел в виду, если node и ts не прокатят, то сетями можно переписать на го.

> [Docker Compose] по сути левый парсер и раньше вообще на питоне был написан

Ну я и говорю, что Docker Compose для Go - это примерно как Notepad++ для C++. Не стоит по ним слишком быстро оценивать качество языка.

> Это я к тому: может лучше искать ЭТО в докере или подмане?

moby [1]: 37,801/340,187/33,118

podman [2]: 32,440/212,678/18,467

Отсюда можно сделать вывод: показатели не портятся даже на больших масштабах.

[1]: https://github.com/moby/moby

[2]: https://github.com/podman-container-tools/podman

Мнение сообщества - это синдром. Есть и технические основания.

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

Блогпост объясняет это коротко:

“We were in a similar situation when we decided to add generics to the language, albeit with an important difference: today nobody is forced to use generics, and good generic libraries are written such that users can mostly ignore the fact that they are generic, thanks to type inference.”

> Про дженерики у сообщества тоже был бухтёж неимоверный про что, что не надо нам этих выших дженериков

В опросе за 2021 [1], перед добавлением дженериков в язык, 39% опрошенных отказывались от Go из-за отсутствия какой-либо фичи, дженерики на первом месте.

Есть опрос разрабов Go за второй квартал 2022 [2], когда дженерики уже были добавлены. Только 6% указали, что не собираются ими пользоваться.

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

> Просто кричащее меньшинство [против новой обработки ошибок] как обычно воспринимается за большинство

Проблемы с обработкой ошибок испытывает не чтобы большинство. Какое-то подмножество из 28%, согласно опросу за 2025 [3]:

“The second major category of frustrations were [“A feature I value from another language isn’t part of Go” (28%)]. These open-text comments largely focused on error handling and reporting patterns, enums and sum types, nil pointer safety, and general expressivity / verbosity: . . .”

[1]: https://go.dev/blog/survey2021-results

[2]: https://go.dev/blog/survey2022-q2-results

[3]: https://go.dev/blog/survey2025

> В именах директорий нельзя [юникод], что-то ломается в сборке

Можно. Файл вида «команда/приветствие.go» успешно соберётся.

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

Ну я и говорю, что Docker Compose для Go - это примерно как Notepad++ для C++. Не стоит по ним слишком быстро оценивать качество языка.

+1

Я думал что notepad++ не такой уж васянский продукт ;)

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

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

> func CheckErrors(err error)

Этот паттерн избегается. Его используют в очень ограниченных контекстах: при инициализации программы или в тестах.

Я не помню, что это обсуждалось в опросах Go. Скорее всего, нету.

В целом, декоратор ведь можно реализовать в Go без синтаксического сахара. Так люди и делают в языке, где не должно быть магии.

Я думал что notepad++ не такой уж васянский продукт ;)

Он не васянский, но точно не «икона». LLVM — вот это икона C++.

Caddy: 920 функций, возвращающих ошибку, 9,208 возвратов, учитывающих ошибку, и 688 простых «return err.»

Это даёт право утверждать, что «return err» - это нечастый метод.

Т.е. в большей половине функций присутствует паттерн return err – и это уже называется «нечастый»? Что же тогда «частый»? Когда по 5 раз на функцию?

Ну и 9’208 возвратов на 920 функций – это по 10 return-ов в одной функции получается. Как по мне, так просто звиздец. Код представляет собой сплошные if-ы со сплошными return-ами.

Может у Go программистов KPI завязан на количество if-ов с return-ами?

И в качестве дополнительной перчинки: https://github.com/search?q=repo%3Acaddyserver%2Fcaddy+%22return+nil%2C+err%22&type=code Это количество конструкций return nil, err.

Она же принципиально отличается от return err. Это ж совсем другое, понимать же ж надо.

Это количество конструкций return nil, err.

Она же принципиально отличается от return err. Это ж совсем другое, понимать же ж надо.

Упс, можете мне объяснить? Я почему то всегда думал что это одно и тоже.

Этот паттерн избегается.

по каким причинам? многим удобно запихнуть подобное в closure и вызывать, хотя на пайковский вкус лучше городить методы https://go.dev/blog/errors-are-values

Его используют в очень ограниченных контекстах: при инициализации программы или в тестах.

не только, если не зацикливаться на какой-то узкой сфере применения языка

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

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

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

так стоп. А можете мне написать значения a,b,c,d при каких оно даст переполнение?

Я в go небольшой спец и мне лучше конкретный пример бы поюзать.

defer func() {
    if r := recover(); r != nil {
        fmt.Printf("так нельзя")
    }
}()

a := 2
b := 0
result := a / b

fmt.Println(result)

Нельзя в названии модуля.

А без модулей сейчас не модно. Хотя, может быть можно сделать один модуль. У них как-то извращённо используется понятие модуля. Мне кажется, что то, что у нормальных людей (у Вирта, допустим) модуль, в go называется пакетом. А то, что го-начальники назвали модулем - это скорее библиотека или проект. Но это только мои текущие впечатления, могу заблуждаться. Если модуль только один, то пусть будет на латинице. В любом случае, пока проект на ts, даже с нейросетью перевести обратно - это время и отладка. Упрусь во что-то - буду решать. Ну и кстати в node.js есть электрон для гуя - хоть тяжёлый, но работает. А у гошников что-нибудь есть?

Ну и кстати в node.js есть электрон для гуя - хоть тяжёлый, но работает. А у гошников что-нибудь есть?

если типа легко электрона то wails (вроде правильно написал) или вам нативный гуй нужен?

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

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

скорее дело не в соместимости, а в безопасности https://github.com/golang/go/issues/20210

т.е. вы ваилс глядели и вам он не подходит?

Не глядел, мне гуй пока конкретно не был нужен. Так, про запас.

Ну конечно, Россия, мой вуз, который я окончил, организация, где я работаю, мой язык и даже, видимо лично я представляем из себя угрозу для безопасности США. Они сами это сказали, за язык их никто не тянул. Поэтому им обязательно нужно создать мне какие-то трудности. Придумать разные формы дискриминации моего языка, чтобы выглядело обоснованно. Взгромоздить одно на другое, чтобы ограничения приходили по зависимостям и было сложнее уйти из-под дискриминации. Поэтому и не выбираю го. Трудности создать удалось, ура. Так-то язык в целом неплохой и конечно гораздо лучше, чем это жуткое джаваскриптие.

Так иного от языков с лефтпад-инфраструктурой ожидать и не стоит. Лефтпад - это централизация, а кто нынче владеет большинством «умов» и так ясно. Бери нормальные языки, или хотя бы просто не используй лефтпады(но как видишь, это может влиять и на другие части языка, напрямую не связанные).

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

Кстати, нет. js лучше go как минимум наличием исключений. Это уже фундаментальное преимущество.

Так паники - это тоже по сути дела исключение. Просто надо разрешить себе ими пользоваться. Была статья «panic like a pro», где это обосновано. Другое дело, что может получиться, что нейросети это не вдолбишь, но если нейросеть сама и код вместо меня пишет и читает, то мне всё это менее важно, чем именование базовых сущностей, таких, как модули и директории. Js гораздо фичастее го - это да, но слишком сложная инфраструктура, присутствие интерпретатора и врождённые пороки в типах данных самого Js всё сильно портят.

Кстати, нет. js лучше go как минимум наличием исключений. Это уже фундаментальное преимущество.

ecma это язык не для программиста. Хотя ts его спасает …

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

> Что же тогда «частый»?

Есть мнение, что конструкция вида if err != nil {return err} является самым распространенным способом обработки ошибки. Когда вы анализировали обработку ошибок [1], вы сами выбрали этот пример среди всех возможных. Для того, чтобы опровергнуть эту позицию, цифры ~7% достаточно.

> Т.е. в большей половине функций присутствует паттерн return err – и это уже называется «нечастый»?

И в чём проблема? У данной конструкции есть легитимное применение. Это не антипаттерн, не плохая практика и ничего такого в этом роде.

> 10 return-ов в одной функции получается. . . . Может у Go программистов KPI завязан на количество if-ов с return-ами?

Вы же знаете, что данный стиль не уникален для Go? Называется “return early,” чтобы сократить избыточный уровень вложенности. Go может накинуть парочку if/return из-за обработки ошибок, но это всё та же тривиальная модель.

Сократить количество ретурнов можно через увеличение количества функций. Но это создаст инфляцию функций, а функции — более ценный когнитивный ресурс, нежели ретурн. И это вернет ту же избыточную вложенность, причём в более острой форме. ~10 линий на метод — вот это «звиздец».

> [return nil, err] же принципиально отличается от return err. Это ж совсем другое, понимать же ж надо.

Моё регулярное выражение учитывает любую конструкцию return, где в конце строки стоит “err.”

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

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

по каким причинам?

Не задавался этим вопросом. Но вообще, покажите полную реализацию хелпера, обсудим.

Ошибки просто нужно пробрасывать, если неизвестно как обработать. А как их пробросить с хелпером? В них обычно суют панику. Вот это уже точно плохо.

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

Я осознаю и учитываю этот факт. Я об этом уже говорил: «замедляет чтение алгоритма (сложнее разглядеть лес среди деревьев)» [1]. Выразительность действительно страдает, но это не единственная метрика.

А в данной ветке мы обсуждали конкретно паттерн “return err” (проброс ошибки без обогащения или доп действий).

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

Есть мнение, что конструкция вида if err != nil {return err} является самым распространенным способом обработки ошибки.

ХЗ чье это мнение. Я вроде как ничего подобного не высказывал.

Когда вы анализировали обработку ошибок [1], вы сами выбрали этот пример среди всех возможных.

Я его выбрал как самый убогий.

Для того, чтобы опровергнуть эту позицию, цифры ~7% достаточно.

Ага, есть ложь, есть наглая ложь, есть простая человеческая тупость статистика.

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

Этой цифры точно достаточно.

И в чём проблема?

В убожестве. Которое почему-то считают нормальным в XXI веке.

Вы же знаете, что данный стиль не уникален для Go?

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

Посмотрите на то, как подобное было решено в Rust посредством ? или в Swift посредством try.

> Вы не те помидоры считаете. Вы общее количество гнилых во всех ящиках подсчитали.

Вы были бы правы, если бы мы искали гнилые помидоры. Я не согласен с тем, что они гнилые, поэтому и смотрю на другие цифры.

> В убожестве.

“Yeah, well, you know, that’s just, like, your opinion, man.”

> Посмотрите на то, как подобное было решено в Rust посредством ? или в Swift посредством try.

Не стоит ожидать, что я этого не знаю.

Так паники - это тоже по сути дела исключение.

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

Не стоит ожидать, что я этого не знаю.

А раз знаете, то как оцениваете? Что удобнее/надежнее/понятнее?

Неужели Go-шный подход?

Могу заметить, что решение предложенное в расте только с виду выглядит хорошо. В реальности ? чаще всего прямой аналог if err != nil { return err }. И даже From не спасает.

Линкуй, кто же искать-то будет.

Я не большой любитель решения в Rust-е (как и вообще синтаксиса Rust-а), но когда приходится заглядывать в код на Rust-е, то он читается проще, чем Go-шный с постоянными if err != nil.

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

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

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

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

> Что . . . надежнее . . . ?

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

но когда приходится заглядывать в код на Rust-е, то он читается проще, чем Go-шный с постоянными if err != nil

А причём здесь rust, если ? это макросы? Сделай в go такие же, если нужно.

Ну да свернуть фигню чтобы в глаза не лезла.

замедляет чтение алгоритма (сложнее разглядеть лес среди деревьев)

кому замедляет чтение? тем, у кого ide не может автоматически убрать определенные блоки кода под спойлеры (code folding)? а еще что-то тут талдычат про 21-й век, про устаревшие технологии 70-х, а сами, видимо, сидят на допотопных текстовых редакторах

ide не может автоматически убрать определенные блоки кода под спойлеры (code folding)?

Ты никак не уберёшь под спойлеры такое add(num_or_err, num_or_err). Да и толку от такого убирания? Невидно не означает нет - оно не решает всех проблем. А if err return - это действительно 70-е.

Посмотрите на то, как подобное было решено в Rust посредством ? или в Swift посредством try.

вот гофер объяснил, почему он недоволен обработкой ошибок в свифте https://web.archive.org/web/20160124043759/https://davidnix.io/post/error-handling-in-go/

Он имеет ввиду оперирование функциями такого вида:

func add(x, y int) (int, error) {
	if y > 0 && x > math.MaxInt-y {
		return 0, fmt.Errorf("positive overflow: %v + %v", x, y)
	}
	if y < 0 && x < math.MinInt-y {
		return 0, fmt.Errorf("negative overflow: %v + %v", x, y)
	}
	return x + y, nil
}

Из таких функций невозможно сложить чистое выражение sub(add(a, mul(b, c)), d).

Хотя вот эта формулировка проблематична:

В языке с мощной обработкой ошибок это выглядит так же

Что значит «мощная обработка ошибок»? Исключения что-ль? Или вопросительный знак в Расте? Нужно уточнение что именно считается стандартом ценности.

Впрочем, конерктно в данном примере возможно и вполне уместно сделать выражение чистым вручную:

type SafeMath struct {
	err error
}

func (s *SafeMath) Add(x, y int) int {
	if s.err != nil {
		return 0
	}
	if y > 0 && x > math.MaxInt-y {
		s.err = fmt.Errorf("positive overflow: %v + %v", x, y)
		return 0
	}
	if y < 0 && x < math.MinInt-y {
		s.err = fmt.Errorf("negative overflow: %v + %v", x, y)
		return 0
	}
	return x + y
}

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)
}

Ну не только. А может быть даже и не столько.

В Rust-е операцию ? можно применять при вычислении аргументов вызываемой функции, например:

fn sum(a: i32, b: i32) -> i32 {
    a + b
}

fn sum_user_provided_values(a: &str, b: &str) -> Result<i32, ParseIntError> {
    Ok(sum(a.parse()?, b.parse()?))
}

А вот в Go придется для каждого вызова parse писать свой if.

Что значит «мощная обработка ошибок»?

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

Вот во втором примере с SafeMath ты попытался иметь возможность написать выражение «нормально», но if s.err != nil на каждую операцию имеет ненулевой оверхэд. У тебя выполнение выражения не прерывается при обнаружении ошибки, выполняется всегда полностью.