Go: ООП не как у всех

В Go отключена перегрузка имён методов. Это ограничение вызвано особенностями встраивания типов, вместо наследования. Я не совсем понимаю почему так, видимо из-за того, что Go не анализирует сигнатуры (хотя Компонентному Паскалю это вполне прилично удаётся). В python есть вполне приличное множественное наследование, и в нём красиво решена проблема хрупкого базового класса. В Go внаглую передран синтаксис объявления методов из КП. Но прочитав первые 3-5 страниц шестой главы -- я не вижу ни одной отсылки к КП. Немножко некрасиво.
Мне откровенно не нравится использование утиной типизации в системном языке. Я не могу Go назвать типобезопасным языком. Ада вроде типобезопасная, но мы то помним злополучный пуск "Ариана" и былинный отказ двигателя из-за ошибки в софте, из-за внутренней сложности Ады. (И как-то сразу вспоминаются итоги конкурса по Аде с фразой:"Господин Вирт верит, что существуют простые решения сложных проблем"). КП выглядит богаче и надёжней. Возможность переопределять метод явно существует только относительно встраиваемых типов, и то, если имена одинаковые -- непонятно как к ним обращаться (полный игнор сигнатуры). Экспортируемые поля обозначены первой буквой -- большой. Что, по-моему, не самое красивое решение. В этом смысле КП с его */- более понятны. И сама политика КП ("то что, не экспортировано явно -- приватное") -- весьма разумное. С большой буквы я привык называть поля, а не экспортировать))) Инициализация класса вызывается явно, что по моему, не очень удобно. Ещё и четырёхсоставная конструкция через New(). И это вторая нагрузка на встроенный New(). Спорное решение. Идея интерфейсов выглядит сыроватой. В книге Саммерфильда так и напрашивается вопрос: интерфейсы у разных типов могут совпадать. Как на счёт интерпретации содержимого полей? Стрёмно как-то. Ну и что, что компилятор Go приводит всё к минимальному виду на этапе компиляции. Можно подумать, что в КП или FreeBasic как-то иначе? И виртуальных методов (ПО НАСТОЯЩЕМУ) используется ну совсем мало.

Посмотрим, что будет дальше.