С технической стороны слабоват уже, есть косяки типа того, что if без заворачивания в блок ничего не возвращает или open - не функция. Но в целом писать на нём легко и код получается компактным. Хотя Crystal мне сейчас больше нравится в этом плане, код на нём такой же компактный, но конечно более понятный для непосвящённого 🙂

Тогда что такое интерфейс в го?

А что нечитаемого в ФП?

Не более, чем интерфейс 🙂Структура с определёнными сигнатурами методов/функций. Не нужно искать в Go то, чего там нет. В конце-концов - почитайте учебник Go от его разработчиков, там нигде не сказано, в Go есть ООП.

Так а что такое интерфейс и почему если это не ООП, функционал определяется внутри него?

У нас либо отдельно структуры, отдельно функции, либо, внезапно, структуры которые определяют свое поведение, что и есть самое что ни на есть ООП

их бесконеные портянки абстракций и неуёмная жажда обощения. ну тот же HKT - это уже нечитаемо, для большинства адептов си-образных языков с +/- одинаковыми концепциями, типа жабы, шарпа или го.
ML - семейство с их каррированием всего и вся. Если взять самый труЪ ФП хаскель, то это вообще пиздец на колёсиках, которые прикручивают фанаты в виде расширения на свиох проектах и потом вообще хрен поймёш что там происхоит в духе {-# LANGUAGE BangPatterns, DeriveDataTypeable, OverloadedStrings, ScopedTypeVariables #-}

и собственно когда эти люди добираются до чего-то нового, то может произойти это
https://gist.github.com/14427/af90a21b917d2892eace

часто складывается такое ощущение, что ярые адепты ФП решают не продуктовые и технические задачи, а ровно одну задачу "ыыы, что мне скучно не было"

А что, там и наследование есть?
Ну то есть как мне получить в структуре Bb все 150 методов из Aa плюс ещё 2 моих уникальных метода и 3 метода переопределить?

А без наследования это не ООП?

Ну и суть ООП - в идеологии, а не в технической реализации. ООП было создано для того, чтобы сделать программирование ближе к человеческому мышлению, где "всё есть объект". А интерфейсы - размышления Go на тему дженериков скорее

Ну  как минимум непонятно, зачем оно такое нужно-то?

Суть ООП в том, что у тебя тип ответственен за функционал
Именно это здесь и происходит

Я не знаю зачем нужен го.

Это реализация. Языки программирования созданы для чего? Чтобы gcc лучше оптимизировал или чтобы человек мог объяснить компу на (почти) человеческом языке, что ему, собственно, от компа нужно?

Нет, в словах "Х ответственен за У" нет ничего относящегося к реализации

Внутри ООП  может быть функция, если на то пошло

В ООП нет типов, есть классы, абстрактные классы, инстансы. Класс объектов "собачьи" может быть реализовано хоть на кубиках рубика, причём тут структуры данных?
У меня в Perl-проектах некоторых объекты - это замыкания на самом деле. Никаких структур внутри нет.

Нет. То что внутри на стадии компиляции оно может интерпретироваться как функция с дополнительным параметром this и даже экспортироватсья как символ уже именно что детали реализации. То что нам в целом нужны статические методы говорит о том что эта модель на самом деле не переносится на реальный мир.

Нет, класс - это общепринятый способ описания типа.
ООП никоим образом не заставляет иметь классы.

Мы же все-таки говорим всегда "система типов" и никогда "система классов"