интерфейсы в 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 в принципе хлам.