Что происходит с популярностью Go?

Не нужно разрабатывать универсальный язык, нужно разрабатывать язык который делает хорошо в конкретной доменной области.

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

Анекдот про мужиков и японской бензопилы просто наглядная демонстрация этой неизбежности.

Этот анекдот про ретроградство.

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

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

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

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

Ясное дело, выбирать нужно clojure.

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

Простите, весь текст про «ООП – бедрок…» поскипал т.к. ничего в нем не понял.

Неуместный пессимизм.

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

К какому выводу вы пришли, кроме «красиво» и «все остальные так делают»?

Компактнее и надежнее. Верующих в надежность существующего сейчас в Go подхода к информированию об ошибках еще раз ткну в примитивнейший пример: https://go.dev/play/p/qvaVqEtJEZp

После такого все разговоры Go-шников на тему «А нужно учитывать цель языка, чтобы программист думал об ошибках и занимался ими своевременно, когда они возникают.» можно отправлять прямиком в /dev/null. Просто по факту того, что язык запросто позволяет игнорировать ошибки.

И да, рассуждения Go-шников о «красоте» должны отправляться туда же просто по факту того, что в XXI веке они добровольно и с удовольствием использовали ParseBool/ParseInt/ParseUint/ParseFloat и SearchFloat64s/SearchInts/SearchStrings в то время, когда у всех вокруг уже были шаблоны/дженерики.

А кто-нибудь кроме Go смог должным образом усвоить уроки Alef и Limbo?

Какой-то странный, мягко говоря, вопрос.

Из того, что я читал про историю Go у меня сложилось впечатление, что было так:

• группу товарищей с общим прошлым задолбало использовать C++, Java и Python в условиях Google;
• эта группа товарищей посовещалась и выработала некий список требований к языку, который они бы хотели иметь;
• из-за их общего прошлого у них получилось что-то очень похожее на Limbo/Alef/Newsqueak. Совершенно случайно, ага;
• эта группа товарищей начала делать свой язык мечты, но, вероятно, не с нуля, а с переиспользованием исходников опыта Limbo.

В результате получился Go. Настолько же примитивный для своего времени, насколько примитивным для 2007-го года был сам Limbo.

При этом есть у меня уверенность, что тот же Пайк не сильно смотрел по сторонам. И вряд ли он имел опыт работы с D (который в 2007-ом зарелизился в версии 1.000 с очень быстрой компиляцией, мощными шаблонами, гораздо более простым синтаксисом, чем C++ или Java), OCaml, Erlang.

Ну и в итоге получилось то, к чему был привычен Пайк, а не то, что бы учитывало современный на тот момент уровень языкостроения.

Ну и в итоге получилось то, к чему был привычен Пайк, а не то, что бы учитывало современный на тот момент уровень языкостроения.

Вот когда я начал писать на Go, то удивился, почему на каждый чих делаю цикл for вместо reduce filter map. Я был уверен, что это от незнания стандартной библиотеки языка, а потом прочитал от самого Пайка:

I wanted to see how hard it was to implement this sort of thing in Go... It wasn't hard. Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I just use «for» loops. You shouldn't use it either.

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

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

Зачем?

Снтаксиса Си достаточно для записи любого алгоритма.
А вот если кто-то хочет чтобы ЯП программирования имел много более его основного назначения, то это говорит о том, что разработчик тратит время не на разработку, а на «усовершенствование».
Да и разработчик ли таков?

Ну а зачем вы в этой теме вообще Rust противопоставляли Go?

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

Это у вас короткая память, потому что Rust вы упомянали не только в связи с data race. Поэтому вполне логично было ожидать упоминание Rust и в связи с обсуждением утиной типизации. Но я не настаиваю, а лишь удивился вашему «зачем?»

Ну и где ваши пруфы? Ссылку, плз.

Перечитайте тему. Я уже устал расжёвывать и пережовывать.

В моем примере вообще можно обращаться к ForeignClass через интерфейс, который этим классом даже не реализуется.

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

Пожалуйста дайте ссылку на свой комментарий где есть пример кода на Java.

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

С недавнего времени появился IO.println()

Это всё мелкие подробности. Основной мой посыл заключался в том, что в Java тащат всякое разное модно-молодёжное почти без разбора. Делают это, скорее всего, просто ради поддержания хайпа дабы народ не уходил на другие языки программирования.

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

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

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

А как бы вы реализовали необходимые вам reduce filter map в вашем языке? Как бы вы сделали это достаточно эффективно, например без необходимости использования дополнительной памяти?

Кстати народ. А давно Жава стала компилятром?

Я прекрасно помню как Шапка пыжилась то делала гсж, то Елефант … из проблем с правами на Жаву.

Поэтому вполне логично

В предсказания вы не можете так же, как и в пруфы, и в примеры кода.

упоминание Rust и в связи с обсуждением утиной типизации

Позволю себе напомнить, что в вашем споре с ya-betmen я всего лишь сторонний наблюдатель, которому не хватает примеров кода с вашей стороны. Своего мнения по поводу этого вопроса я даже и не высказывал.

Перечитайте тему. Я уже устал расжёвывать и пережовывать.

Так мне не ваши пережовывания нужны, а пруфы того, о чем вы говорите. Вы, в частности, говорили, что Пайка брали в Google для разработки Go. Но с пруфами как-то не срослось. Как и с другими вещами, включая наличие у вас мозгов.

Было описание

Т.е. примера кода не было. ЧТД.

Напиши пример кода на C в котором есть две функции с одним именем.

Я вам написал пример кода, где доступ через интерфейсы A и B идет к объекту класса ForeignClass, который про интерфейс B ни сном ни духом.

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

Можно ли это объяснить банальной экономией на найме, когда одни и те же люди делают и бэкэнд и фронтэнд?

Как админ/девопс терпеть ненавижу большинство(не всех, есть хорошие) универсалов, которые пишут и фронт, и бэк. Потому что тут не в языке дело. Это разные вещи, разные среды исполнения, разные требования к управлению модялми, разные знания в работе с данными и много чего другого разного. И моя практика подсказывает, что универсалы чаще всего получаются из фронтэндеров, которые решили, что раз язык один, можно вкатиться в бэк. И притянуть свои подходы на сервера. Ну, точнее они пытаются притянуть, и приходится им долго и нудно бить по рукам. Такая экономия в большинстве своём приводит к тому, что потом ничего не работает или работает плохо и приходится в итоге всё-равно нанимать отдельных людей, которые всё это выкинут и перепишут с нуля(или почти с нуля). И не важно, что там будет за язык. Пусть та же нода останется, но нормальный бэкэндер таки будет всё переделывать. Причём, может быть этот бэкендер перешёл на ноду с того же самого го или какой-нибудь явы. В пакетирование фронтового код мне вникать приходится сильно меньше. Но что-то мне подсказывает, что хорошие фронты на вкатившися бэкендеров ругаются так же. Просто потому что это две совершенно разные области программирования, имхо.

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

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

Алсо, для вашего с бэтманом обсуждения и двух интерфейсов не нужно. Это всё можно редуцировать в один интерфейс и инжект сторонний библиотеки, имеющий необходимые методы, но этот интерфейс не реализующей.

Я думаю МС выкатила ТС как раз для нормальных программеров чтобы они кое как могли писать БАК на жс.

Я вам написал пример кода, где доступ через интерфейсы A и B идет к объекту класса ForeignClass, который про интерфейс B ни сном ни духом.

Это пример какой-то ваше отсебятины, о которой вас никто не просил.

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

Похвальная самокритики - и дебил и болван. Я бы сказал проще - просто дурак. Потому что dependency injection - это вообще не про «инжектинг двух интерфейсов в один класс», который возник в вашем воспалённом мозгу. Dependency injection - это всего лишь отвязка от конкретной реализации. То есть вместо ConcreteClass variable = new ConcreteClass() у вас должно быть ConcreteInterface variable и даже необязательно с инициализацией в этом месте. Затем вы передаёте конкретную реализацию тем или иным образом, например через конструктор, сетер или даже при помощи рефлекшена. Именно так это работает в Spring. Проблема возникает с реализациями сразу нескольких интерфейсов. Типом variable сразу несколько интерфесов быть не могут. Можно сделать свой один интерфейс, который содержит (Go) или наследует (Java) те два интерфейса и объявить, что тип variable - это этот новый интерфейс. В Go, благодаря утиной типизации, это просто будет работать. В Java это работать не будет, поскольку потребует изменение всех конкретных реализаций, которые вовсе необязательно ваши. Но кому я это всё объясняю по кругу уже который раз подряд? Правильно - идиоту @eao197. Сейчас этот идиот вновь потребует пример кода на Java.

терпеть ненавижу большинство(не всех, есть хорошие) универсалов, которые пишут и фронт, и бэк.

Согласен на 200%. Но вот большинство работодателей придерживаются иного мнения. Причём необязательно совмещая frontend и backend, но так же, когда они перекладывют на backend разработчиков те или иные функции QA и DevOps. Настоящий QA вообще стал редкостью. При этом работодателям не жалко тратить время разработчиков на бесконечные совещания и прочие вредительские Agile практики.

Это пример какой-то ваше отсебятины, о которой вас никто не просил.

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

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

Похвальная самокритики - и дебил и болван. Я бы сказал проще - просто дурак.

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

То есть вместо ConcreteClass variable = new ConcreteClass() у вас должно быть ConcreteInterface variable

Что мешает сделать в Java в качестве ConcreteInterface обычный абстрактный класс, который имплементит нужное вам количество интерфейсов? В моем примере таковым является MyWrapper.

Да, он будет определяться с помощью ключевого слова class, а не interface. Но задачу вроде как решает.

вообще не про «инжектинг двух интерфейсов в один класс», который возник в вашем воспалённом мозгу

Помилуйте, это же ваши слова:

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

Так что это возникло в вашем воспаленном мозгу (хотя какой там вообще мозг).

Именно так это работает в Spring.

Приплетание dependency injection вообще и Spring-а в частности в спор о структурной и нормативной типизации выглядит как ненужное усложнение, забалтывание и надувание щек.

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

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

Алсо, для вашего с бэтманом обсуждения и двух интерфейсов не нужно. Это всё можно редуцировать в один интерфейс и инжект сторонний библиотеки, имеющий необходимые методы, но этот интерфейс не реализующей.

Ещё одна глупость. Наверное это передаётся воздушно-капельным способом.

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

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

Я вам дал пример кода на Go, на что вы отреагировали совершенно нерелевантным бредом на Java.

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

Есть такое свойство некоторых людей - идиотия. Это когда и словами с несколькими вариантами формулировок до них ничего донести нельзя и даже конкретным примером.

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

Убедили, они правы. А я так надеялся, что это не так.

Что мешает сделать в Java в качестве ConcreteInterface обычный абстрактный класс, который имплементит нужное вам количество интерфейсов?

То же самое, что мешает использовать интерфейс - всё равно придётся менять все конкретные реализации.

В моем примере таковым является MyWrapper.

Ваш пример вообще нерелевантен поскольку не соответствует условию.

Да, он будет определяться с помощью ключевого слова class, а не interface. Но задачу вроде как решает.

Ну да, это же резко меняет дело - class вместо interface. Закрой воду дурак!

вообще не про «инжектинг двух интерфейсов в один класс», который возник в вашем воспалённом мозгу

Помилуйте, это же ваши слова:

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

Так что это возникло в вашем воспаленном мозгу (хотя какой там вообще мозг).

В каком месте вы тут у меня нашли своё глупое «инжектинг двух интерфейсов в один класс»?

А куда ты собрался инжектить два интерфейса?

Именно так это работает в Spring.

Приплетание dependency injection вообще и Spring-а в частности в спор о структурной и нормативной типизации выглядит как ненужное усложнение, забалтывание и надувание щек.

Я думаю, он тупо не умеет инжектить без спринга - по этому и кода мы не (у-) видим.

Но что-то мне подсказывает, что хорошие фронты на вкатившися бэкендеров ругаются так же.

Да, ещё как. Вот мы как-то взяли и сделали фронт на чистом js без тонн какого-то нелепого говна. Потому что не было на него финансирования. И работает хорошо, верстальщики в ужасе – недобросовестная конкуренция. Но обычно программистам хватает других задач кроме этой параши.

А куда ты собрался инжектить два интерфейса?

Любую конкретную реализацию двух или более интерфейсов, а не сами интерфейсы. Куда именно инжектить - без разницы.

Любую конкретную реализацию двух или более интерфейсов,

И в чём фундаментальная разница между инжектом любой конкретной реализации одного интерфейса?

Приплетание dependency injection вообще и Spring-а в частности в спор о структурной и нормативной типизации выглядит как ненужное усложнение, забалтывание и надувание щек.

Dependency injection - распространённая практика и полезный паттерн проектирования. Утиная типизация в Go снимает одно из ограничений практического использования dependency injection, которе есть в Java. Что же до забалтывания темы, то это про твои неадекватные и глупые комментарии, последовавшие за этим.

Любую конкретную реализацию двух или более интерфейсов,

И в чём фундаментальная разница между инжектом любой конкретной реализации одного интерфейса?

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

Я на всякий, скопирую оригинальное ТЗ, по которому любой джун может написать код на яве, а то хрен найдёшь:

Представь себе что у тебя в Java есть два интерфейса и есть несколько классов, которые реализуют оба эти интерфейса одновременно. Как инжектить эти и будущие реализации двух и более интерфейсов? Как это делать со сторонними библиотеками, изменить которые ты не можешь?

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

по которому любой джун может написать код на яве

Не написать код, а понять почему это написать на Java нельзя, а на Go с утиной типизацией можно. Ты заразился той же идиотией, которой страдает @eao197 и требует дать ему код именно на Java?

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

Ты не можешь объявить типом переменной или поля класса сразу несколько интерфейсов, которые РЕАЛИЗОВАНЫ в сторонней библиотеке.

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

Дерево содержит сотни миллионов узлов? В таком случае, уступаю утверждение «машина не устанет».

Однако, это домен высоких нагрузок, поэтому:

. Go не претендовал быть неоспоримым лидером в этой области.

. Дженерики — не единственное обоснованное решение. Ещё есть кодогенерация.

Компактнее и надежнее. . . . ткну в примитивнейший пример

Цитирую пример:

i, err := strconv.Atoi("bla-bla-bla")
fmt.Printf("unchecked i=%d\n", i)
if err != nil {
	fmt.Printf("still access i=%d\n", i)
}

Я за всю практику ни разу не допустил данной ошибки и ни разу не увидел её в чужом коде.

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

Тот факт, что в Go нет силлогических гарантий, не обозначает, что произвольные ошибки становятся повсеместными. Строго говоря, силлогизмы сами по себе могут быть обманчивы, особенно если пытаться свести на них все гарантии.

Иногда, однако, данный код и не должен являться ошибкой. Read может вернуть неполные данные вместе с ошибкой.

Компактнее — да, я не оспариваю эту пользу. Однако, в вашем же примере используется unwrap. Приведу аналогию: тот факт, что у нас есть достоверная карта казино по всему городу, не сокращает их количество. В действительности, Rust-разработчики намного чаще используют unwrap, чем Go-разработчики игнорируют error.

рассуждения Go-шников о «красоте» должны отправляться [в /dev/null] просто по факту того, что в XXI веке они добровольно и с удовольствием использовали . . . SearchInts . . . в то время, когда у всех вокруг уже были шаблоны/дженерики.

Я ума не приложу, в соответствии с какими эстетическими стандартами можно найти существенную разницу между sort.SearchInts() и sort.Search[int](). Разница настолько маргинальна, что сама попытка раздуть её вызывает подозрения.

> А кто-нибудь кроме Go смог должным образом усвоить уроки Alef и Limbo?

Какой-то странный, мягко говоря, вопрос.

Суть вопроса изложена в следующем абзаце: «Пока опыт из прошлого не был осмыслен, он остаётся релевантным в каждом новом поколении.»

То есть исследования измеряются не в годах, а во влиянии на индустрию.

Небольшой пример. Сегодня идеологические критики GC в Go, в основном, указывают на желание ручного управления, на непредсказуемые латенси и паузы, оверхед CPU, зависимость в рантайме. Всё это правда, только никто не учитывает, что CSP без GC уже был испробован в Alef и именно это было его главной проблемой. В этом отношении индустрия (за пределами Go) не то чтобы переросла Limbo, а не доросла до Alef.

почему на каждый чих делаю цикл for вместо reduce filter map

Функциональный стиль возможен [1], но язык не оптимизирован под него.

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

Это неверная интерпретация. Роб Пайк сказал не «смогу ли я комфортно писать код с использованием filter/map/reduce» (это очевидный straw man), а «впишутся ли эти функции органично в существующую модель языка Go».

Можно было бы заранее предугадать ответ, но Роб Пайк сделал щедрую попытку.

В этой цитате вообще нет ничего удивительного. Попробуй использовать filter/map/reduce в Си — результат будет аналогичный.

[1]: https://github.com/samber/lo

это написать на Java нельзя

Давай попробуем с кода, который написать на ява можно:

interface Beep {
    void beep();
}

interface Boop {
    void boop();
}

class BeepImpl implements Beep {
    
    @Override
    public void beep() {
        System.out.println("Beep.");
    }
}

class BoopImpl implements Boop {
    
    @Override
    public void boop() {
        System.out.println("Boop.");
    }
}

interface BeepBoop extends Beep, Boop {
}

class BeepBoopImpl implements BeepBoop {
    Beep beep = new BeepImpl();
    @Override
    public void beep() {
        beep.beep();
    }

    Boop boop = new BoopImpl();
    @Override
    public void boop() {
        boop.boop();
    }
}

public class main {
    public static void main(String[] args) {
	
        BeepBoop beepboop = new BeepBoopImpl();

        beepboop.beep();
        beepboop.boop();
    }
}

Твои причитания о том, что надо делать класс-враппер " BeepBoop ", верно?

Конкретно на Go такого качества WASM на выходе, что проблема вообще не в отсутствии доступа к DOM (можно уже сейчас решить простой обёрткой на JS). При чём, core team целенаправленно этот кал запилили с мотивацией «на фронте никто Go не использует, нет смысла трястись за размер, пойдём по пути наипростейшей реализации и наибольшего переиспользования кодовой базы GopherJS». А разработчик GopherJS, в свою очередь, имел философию «нет смысла трястить о размере, GopherJS никто не использует в продакшене». Так и родили говно для галочки. Я бы если бы на Go хотел написать реальный фронт для реальных коммерческих пользователей, начал бы со своей реализации транслятора, а на этом фоне не ясно нахрена WASM, проще - подмножество JS.

Конкретно на Go такого качества WASM на выходе, что проблема вообще не в отсутствии доступа к DOM

Можно конкретнее, какие именно там проблемы с качеством? Я просто не в курсе.

Зачем разбирать пример, который совершенно не отражает проблему? Представь себе, что я автор сторонней библиотеки и реализовал оба интерфейса Beep и Boop в одном классе и помимо меня есть ещё несколько других сторонних бибилотек, которые так же реализовали эти два интерфейса в одном классе. Ты не хочешь привязывать свой код к какой-то одной реализации, поэтому хочешь её инжектить. Как ты это сделаешь на Java? Будешь делать костыль в виде обёртки? Будешь делать другой костыль в виде двух полей типов Beep и Boop в своём классе и соответственно будешь инжектить один инстанс дважды? Без таких или иных костылей как ты это сделаешь по-человечески?

Зачем разбирать пример, который совершенно не отражает проблему?

Давай попробуем написать пример, который отражает проблему.

Представь себе, что я автор сторонней библиотеки и реализовал оба интерфейса Beep и Boop в одном классе

Идея моего примера, что некие авторы сторонней библиотеки реализовали два разных интерфейса, как ты и просил. Интерфейсы и реализации в примере - сторонние.

Озвученная тобой проблема:

ты не можешь использовать два интерфейса сразу как тип переменной или поля класса.

Будешь делать костыль в виде обёртки?

Да. В моём примере это решается через wrapper, ровно как ты написал:

наследует (Java) те два интерфейса и объявить, что тип variable - это этот новый интерфейс.

Твой тезис:

Проблема возникает с реализациями сразу нескольких интерфейсов. Типом variable сразу несколько интерфесов быть не могут. Можно сделать свой один интерфейс, который содержит (Go) или наследует (Java) те два интерфейса и объявить, что тип variable - это этот новый интерфейс. … В Java это работать не будет, поскольку потребует изменение всех конкретных реализаций, которые вовсе необязательно ваши.

Вопрос - что и почему не будет работать в Java?

Если язык не лисп, то макросы превращаются в отдельный язык.

Это ни из чего не следует. Вообще нет. Просто нету такого закона. Надо, чтобы на этапе макроподстановки были доступны функции языка. Вот и всё.

можно вытворять всякое сг строками,

Это просто не работает. Семантика, области видимости сразу теряются и за ними приходится следить программисту. А люди не очень-то хороши в этом. Considered harfmful, короче.

ничего кроме строк в скриптухе нет

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

Tcl

Tcl — это лисп для малаграматных.

Давай попробуем написать пример, который отражает проблему.

Возьми мой пример на Go и попробуй точно так же реализовать его на Java - получишь отражение проблемы.

Идея моего примера, что некие авторы сторонней библиотеки реализовали два разных интерфейса, как ты и просил. Интерфейсы и реализации в примере - сторонние.

Я видел. Но каждый интерфейс в твоём примере реализован в отдельном классе, а нужна реализация двух интерфейсов в одном классе. Я уже устал это объяснять снова и снова.

Озвученная тобой проблема:

ты не можешь использовать два интерфейса сразу как тип переменной или поля класса.

В моём примере это решается через wrapper.

В твоём примере изначально не то, что требуется и wrapper притянут за уши.

Твой тезис:

Проблема возникает с реализациями сразу нескольких интерфейсов. Типом variable сразу несколько интерфесов быть не могут. Можно сделать свой один интерфейс, который содержит (Go) или наследует (Java) те два интерфейса и объявить, что тип variable - это этот новый интерфейс. … В Java это работать не будет, поскольку потребует изменение всех конкретных реализаций, которые вовсе необязательно ваши.

Вопрос - что и почему не будет работать в Java?

Смотри выше. Перечитай самый первый пример с LinkedList или пример на Go или implements Beep, Boop. Ну честное слово, я как будто в дурдоме собеседование для джунов провожу.

Ну, тут ещё и человеческий фактор не следует сбрасывать со счетов. Чтобы на С++ писать не отстреливая себе ноги промышленным способом нужно лет пять напряжённо учиться писать на С++. И всё это время мучительно недоумевать и чувствовать себя БE3HOГNM болваном. Поэтому предложение использовать другой язык воспринимается как личное оскорбление. Во-первых, обесценивается весь предыдущий труд. Во-вторых, это что же опять пять лет страдать?! А вот для того, чтобы выдавать идиоматичный код на Go нужно потратить вечер на прохождение a tour of Go. Естественно, этого не хватает на создание сильной эмоциональной связи и гошник легко может согласиться: „Тут Go будет неудачным выбором, давайте возьмём другой язык“.

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

Я вам дал пример кода на Go, на что вы отреагировали совершенно нерелевантным бредом на Java.

На вопросы касательно вашего кода на Go вы не ответили, свой пример на Java не привели. Я всего лишь пытался сформулировать так, как я его понял. Поскольку вы от уточнений устранились.

Это когда и словами с несколькими вариантами формулировок до них ничего донести нельзя и даже конкретным примером.

Очень удобная позиция: сперва сказать, что Пайка наняли в Google чтобы он делал Go, потом забить на все просьбы привести пруфы; привести описание, которое читатели трактуют по разному, а на просьбы проиллюстрировать описание кодом обзывать читателей идиотами.

И да, инжектинг увидел в процитированном куске ваших «описаний»

Чтобы на С++ писать не отстреливая себе ноги промышленным способом нужно лет пять напряжённо учиться писать на С++. И всё это время мучительно недоумевать и чувствовать себя БE3HOГNM болваном. Поэтому предложение использовать другой язык воспринимается как личное оскорбление.

О, чувствуется здесь что-то глубоко личное.