интерфейсы в GO

Абсурд. Альтернатив Гошке нет вообще.

Любой другой ЯП либо недоразвитое говно, либо перегружен говном.

Всё старые ЯП в принципе обсуждать нет смысла — устаревшее говно не успевающее за реальностью.

А что остаётся? Да в принципе ничего. Раст — это про другое. Котлин — тоже. Что там ещё? Да больше ничего и нету.

забанили в гугле, яндексе, бинге, дакдакго и всех ai чатах

И на go.dev/tour, видимо.

Фанаты они такие фанаты :)

Лучше генерации ничего нет. Просто слишком сложно для простой замены типов.

Фанаты они такие фанаты :)

Да, полностью согласен. Фанаты говноязыков программирования. Они такие.

Тогда мы бы получили второй C#.

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

Вы всё говорите общими фразами. Можно конкретно показать, где дженерики ломают go?

Java и TypeScript гораздо удобнее Go. Хотя бы тем, что там есть исключения, а не эти идиотские return err.

в Го всегда были захардкоженные map[type1]type2. И всех все устраивало.

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

Они туда еще нормальную ORM не добавили, RAW SQL во все поля как какая-нибудь сишка.

Охладись маленько.

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

Сколько и каких книжек написал ты?

Я не хочу и не захочу писать шлакокнижки. Зачем мне это?

Исключения запутывают поток выполнения, в отличие от. И поэтому чаще всего на них забивают, повсюду ставя throws или один catch (Exception) на весь блок. Для закрытия ресурсов вообще отдельная конструкция (try with resources).

Они не ломают Go. Их было сложно реализовать таким образом, чтобы они не ломал Go. Но теперь они есть в языке и всё норм.

О том, что именно вызвало трудности:

• Minimize new concepts
• Complexity falls on the writer of generic code, not the user
• Writer and user can work independently
• Short build times, fast execution times
• Preserve clarity and simplicity of Go

https://go.dev/blog/why-generics

Конкретные примеры можно найти в куче отклонённых предложений. Я лично не особо с ними знаком, но могу привести такой пример, возможно, слегка не по теме — сейчас нельзя добавить дженерик замыканию, потому что нужно сохранить нулевые значения, а без указания конкретного типа это невозможно. Подобные ограничения, мне кажется, делают невозможным подход «давайте всё спишем у C++/Java/C#».

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

Во всех языках (C, Java, Python) этот приём используется вручную, но в Go его встроили прям в язык.
Вот как выглядит аналогичный код на разных языках.

sort(arr, 0, len / 2); // C
arraycopy(src, 0, src.length / 2, ...); // Java
print_half(lst, 0, len(lst) / 2); Python
println(s[0:len(s) / 2]); // Go

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

Наоборот. Постоянные return запутывают поток выполнения. А исключения позволяют не отвлекаться не несущественный код.

И поэтому чаще всего на них забивают, повсюду ставя throws или один catch (Exception) на весь блок

Один catch это гораздо лучше, чем миллиард if-ов, спасибо за аргумент в мою пользу.

Для закрытия ресурсов вообще отдельная конструкция (try with resources).

Или defer, ага.

Ну вот видишь ты throw new Exception, где он обработается? С return сразу будет видно.

Это несущественный код только для тех, кто привык писать ненадёжную скриптуху, ломающуюся от каждого пинка.

Один catch это гораздо лучше, чем миллиард if-ов, спасибо за аргумент в мою пользу.

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

Захочешь добавить новый код и не поймёшь, правильно ли сейчас обработается твоё исключение одним общим блоком.

В общем, лень ≠ простота.

Или defer, ага.

defer — конструкция общего назначения, не обязательно для закрытия ресурсов. А try with resources — магия, которую добавили после провального try-finally.

Ну вот видишь ты throw new Exception, где он обработается?

Где положено.

С return сразу будет видно.

Нет, не видно.

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

Это не важно. Важно, что идёт так.

Захочешь добавить новый код и не поймёшь, правильно ли сейчас обработается твоё исключение одним общим блоком.

Чего это не поймёшь?

defer — конструкция общего назначения, не обязательно для закрытия ресурсов.

Да, как и try-finally.

А try with resources — магия, которую добавили после провального try-finally.

try with resources это синтаксический сахар для успешного try-finally. Который бы не помешал в Go, кстати говоря.

Где положено.

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

Нет, не видно.

Как это не видно? Обработка происходит в 99% случаев первым if-ом.

Это не важно. Важно, что идёт так.

То есть работа с ошибками не важна. Ну тогда мой аргумент про «ненадёжную скриптуху» в силе. Только непонятно что ей делать в энтерпрайзной Джаве или Шарпе.

Чего это не поймёшь?

Представь, что обработка ошибки отправляет какое-то межсервисное событие. Оно нужно для нового кода? Хз.

try-finally

Который превращает код в лапшу, если, например, закрытие неоткрытых ресурсов запрещено. Поэтому и был придуман try with resources.

[try with resources] … не помешал в Go, кстати говоря.

Зачем? Я ни разу не видел, чтобы defer плохо справлялся с очисткой ресурсов. Есть пример?

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

И на Go придётся. Потому, что в 99% случаев там будет if err := bla(); err != nil { return err; } и это в хорошей программе, а в плохой вообще ничего не будет, лол.

Как это не видно? Обработка происходит в 99% случаев первым if-ом.

Нет, обработка происходит в 99% случаев где-то сверху по стеку.

То есть работа с ошибками не важна.

Конечно же работа с ошибками важна. Но не как в Go. А централизованно. Что позволяет гарантировать корректную работу с ошибками. А не как в го - проверил - хорошо. Не проверил - всем пофиг.

Поэтому

Ну тогда мой аргумент про «ненадёжную скриптуху» в силе. Только непонятно что ей делать в энтерпрайзной Джаве или Шарпе.

Ненадёжная скриптуха это как раз Go. Ибо там, чтобы обработать ошибку хоть как-то, нужно прилагать усилия. Примерно как в баше, лол. А в Java нужно прилагать усилия, чтобы НЕ обработать ошибку. Что автоматом повышает надёжность программы на порядок.

Про то, что информативность стектрейса на порядок выше какой-то рандомной строчки в Go - я даже не говорю.

https://niketpatel.com/essays/why-go-cant-try

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

Обработка ошибок в Гошке лучше всего. Не говно-errno, не исключения, не игнорирование.

Языки без defer в принципе хлам.

Хлам – это твоё мнение. Всегда думал, что go чисто утилитарный язык, а не язык фанатиков.

И на Go придётся. Потому, что в 99% случаев там будет if err := bla(); err != nil { return err; } и это в хорошей программе, а в плохой вообще ничего не будет, лол.

Есть ветвление. И оно есть явно. В чём пробелма? Ошибка никогда не возникает сама по себе. И у неё есть контекст. Вместо говнища вида failed something и километровой дрисни из стека, как в Яве. Ошибка возникает и ей даётся контекст. Поэтому в реальности это выглядит так

if err != nil {
     return fmt.Errorf("crap at %q with %d: %v", a, b, err)
}

В принципе – единственный способ уйти от ошибок вида 0x8394832 Broken unknown crap 2. И километровой дирсни из раскрученного стека.

А раскрутка стека на каждый чих – это вообще нечто.

Конечно же работа с ошибками важна. Но не как в Go. А централизованно. Что позволяет гарантировать корректную работу с ошибками. А не как в го - проверил - хорошо. Не проверил - всем пофиг.

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

Примерно как в баше, лол. А

Баш как раз сверхговно по части обработки ошибок, где они в принципе игнорируются всегда. И никогда не ясно, что и где отвалилось.

Все равно не понимаю, в в чем проблема дженириков. По твоему комменту вроде как все проблемы решены.

Хлам – это твоё мнение. Всегда думал, что go чисто утилитарный язык, а не язык фанатиков.

Утилитарное – это мнение говнохранителей, которым не нравится Го. Ввиду лишь только того, что из него выкинули всё говно.

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

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

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

Это Ваша характеристика.

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

Дай погадаю. Ты бывший пхпшник :) Отсюда и комплексы.

Настолько логично и понятно, что это основной вопрос на собесах.

Так на собесах все базовое спрашивают, на то они и собеседования. :)

Ссылаться на Си, объясняя косяк в современном языке, ну такое. И в Си как раз такого не будет, там всё логичнее, так как крнтроля за памятью никто не обещал.

Я тебе пытаюсь показать, что это не косяк а Go это развитие C а не каких-то там питонов. Go это C с GC. Авторы сами говорили, что Go это была замена для C++.