а зачем это нужно и когда такое требование возникает можно поинтересоваться ?

в Go пакеты не могут взаимодействовать друг с другом?

выходит ошибка import cycle not allowed

ну например у меня есть пакет а и пакет б пакет а должен юзать функции пакета б, и наоборот

у кого нибудь есть на примете либа с реализацией базовых алгоритмов, где в сигнатурах публичных функций отсутствует interface{} ?

да и че то я не готов пока воспринимать Гошу, как строго типизированный ЯП :)

Прекрасное. код heap’а наркоманов https://github.com/scalaz/scalaz/blob/series/7.3.x/core/src/main/scala/scalaz/Heap.scala и здоровых людей https://golang.org/src/container/heap/heap.go Как говорится почувствуйте разницу

это почему же? он таковым по факту является

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

Зачем хаять, если "ниасилил"?

почему решили что не "ниасилил"?

нет, "утиная типизация" не ослабляет контроль типов ни разу. а вот это вот возможность выполнения в роли скрипта без компиляции путем установки рантайма - это что имеется ввиду?

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

> Более того язык подразумевает возможность выполнения в роли скрипта без компиляции путем установки рантайма. Хочешь покажу как код на C++ запускать также? 😃

github.com/kless/gonow wiki.ubuntu.com/gorun т.е. через #!/usr/bin/env gorun и #!/usr/bin/env gonow

> Более того язык подразумевает возможность выполнения в роли скрипта без компиляции путем установки рантайма. Хочешь покажу как код на C++ запускать также? 😃

это сейчас есть в любом статическом языке если что

не спасибо, в крестах нет утиной типизации и они дальше от скрипта, а в Гоше с его уткой вполне можно скрипты писать ))

не спасибо, в крестах нет утиной типизации и они дальше от скрипта, а в Гоше с его уткой вполне можно скрипты писать ))

В плюсах есть статический аналог утиной типизации - структурная типизация.

Скрипты - это никак не про утиную типизацию...

слишком много танцев с бубном для простого присваивания

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

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

и как это реализованно в случае указания интерфейса ?

не понял вопрос

так о чём спор-то, кто кого строже?

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

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

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

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

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

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

Ни в одном языке не гарантируется чьё-либо поведение 🤔

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

кхм кхм.. rust кхм.. кхм..

Вы хотите сказать, что в других статических языках компилятор не только проверяет наличие методов, но и гарантирует их поведение? О_о

Он гарантирует работу с памятью, а не гарантирует, что ты не поделишь на ноль ))

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

define "базовых"

это Тайна

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

гифка_о_генерыках_в_го.жпг

Пустая картинка.жопег? Или с монстром?

какой проблемой это может быть например?

define "базовых"

поправка, базовые структуры данных и алгоритмы работы с ними что то типа этого, но с реализациями для всех встроенных типов без пустых интерфейсов https://github.com/Workiva/go-datastructures

Думаю это impossible.

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

Вы фантазируете. То, что вы описали - это типичный пример ЛЮБОЙ абстракции - скрывать детали реализации от публичного апи. Функция - это тоже абстракция, она тоже может грохнуться в рантайме. К статической типизации это не имеет ВООБЩЕ ни какого отношения

Вы фантазируете. То, что вы описали - это типичный пример ЛЮБОЙ абстракции - скрывать детали реализации от публичного апи. Функция - это тоже абстракция, она тоже может грохнуться в рантайме. К статической типизации это не имеет ВООБЩЕ ни какого отношения

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

вполне possible, все тоже самое, только еще немного кодогенерации сверху для замены дж****ков

я не претендую на истиность и мне интересно читать доводы, но советую ознакомиться например с таким ответом https://softwareengineering.stackexchange.com/a/77998