Но зачем?..

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

Вот обсуждение на стековерфлоу.

https://stackoverflow.com/questions/20380333/cyclic-dependencies-and-interfac...

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

Это всё, что я могу сделать для объяснения. На практике случаи с циклической зависимостью встречаются. Когда рекурсивный импорт нельзя, возникает геморрой. Снижается производительность труда, надёжность, и понятность программы. Но это всё такие резоны, которые не для всех резонны. Поскольку я начинал с Паскаля, для меня это дико :)

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

Он фейл уже хотя бы из-за названия

Голанг, лол. Умудриться назвать язык негуглируемым словом - и это умудрился сделать гугл. Это даже не фейл, это фрактал фейла.

недостатка выразительности
с чем в Go проблемы нет

/0. Тупее и примитивнее Go наверное только... Да ничего, такое днище в качестве серьёзного языка ещё никто не брал на себя стыд предлагать.

а приведи пример, когда это нужно. Я хз как у вас там в продакшоне, но у меня го заменил петон для внутренних разработок и мелких скриптух, которые можно еще собрать и дать вендузятнкам как один бинарник и им не нужно больше ныть про «этожы пееетооон ставитиить!»

Слышу жалобный стон неосилятора.

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

Я на примере классов проиллюстрирую.

https://stackoverflow.com/questions/553682/when-can-i-use-a-forward-declaration

Вот, 551 пользователь SO счёл ответ на вопрос про циклические зависимости между определениями классов полезным. При этом, модуль отличается от класса не так уж сильно - это тоже элемент декомпозиции задачи на подзадачи, со своими нюансами.

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

Это какой например?

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

циклические зависимости

Увы тебе, их ещё с прошлого тысячелетия начали выпиливать, потому-что говнокод.

хм. Зачем это нужно в С++ оно понятно. Накой такое же нужно в го, если там и так

type A struct {
	b *B
}

type B struct {
	a *A
}

func main() {

	b := new(B)
	b.a = new(A)
	b.a.b = new(B)
	b.a.b.a = new(A)

	fmt.Printf("{}", b)
	fmt.Printf("{}", b.a)
	fmt.Printf("{}", b.a.b)
	fmt.Printf("{}", b.a.b.a)
}

Докер написан на Го. Где твой бог сейчас?

Докер

Не нужно. Уже даже хипстеры про него забывают, а нормальные люди даже не прикасались.

Не нужно. Уже даже хипстеры про него забывают, а нормальные люди даже не прикасались.

Утверждения, основанные ни на чем.

корпоративный стандарт де факт.

goatsex будет?

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

By design

Это сделано осмысленно - https://talks.golang.org/2012/splash.article .

D

И, кстати, можно использовать как скриптовый.

Поскольку я начинал с Паскаля

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

Ты небось закинул всё в глобалы и поперезависел везде. Заснуь их в common-модуль и его везде импортируй.

Это проблема импорты vs форварды. В форвардах можно просто объявить, что где-то будет икс, и линкер его находил сам. А в импортах такое не канает. Хотя почему нельзя циклоимпорт в языке, где при импорте не выполняется кода никакого - хз. Он там выполняется или нет?

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

У go как раз очень большие проблемы с этим. Я вообще не понимаю, как в 21 веке могло возникнуть и распространиться такое...

Но фанатикам го ничего не объяснить. Их не смущает отсутствие элементарных вещей в языке. Они готовы копипастить код для разных типов, использовать interface{}, копипастить «обработку ошибок» и т.д. и т.п.

Слышу жалобный стон неосилятора.

Это не C++ и не Scala. Там нечего осиливать. Язык действительно скудный. В конце 70х - начале 80х был бы хорош.

Это не очень объективно, потому что у того паскаля были проблемы со скопами, типами, строками и битоепством, как минимум. А потом еще и с совместимостью диалектов - куча вендоров с разными идеями. Как язык сам по себе он лучше сишки, ноу дабт, но не для околосистемщиков. Почему его нет сейчас - непонятно, ведь можно было пофиксить все проблемы и выкатить, но выкатили го и почти-д, но они тоже аутсайдеры по большому счету. Ява сегодня паскаль видимо. Не факт, что будь паскаль на коне, он не стал бы монстром с практически значимым хелловордом в 15кб бойлерплейта.

на самом деле, если исходить из того что это не полнофункциональный язык, а хрень для быстрого написания небольших утилиток и обучения программированию, то все «недостатки» (фактически переупрощение) гуглоязыка становятся понятным и объяснимым. весь хайп по его поводу обычный гуглопеар, хотя язык имно не очень его достоин.

Зачем тогда гугл на нём пишет свой цубернетес?

У гугла сейчас целые ряды совершенно «обычных» программистов. Go очень хорош для больших компаний, на самом деле.

Потому что ему некуда девать кучу бабла?

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

Как там пофиксить проблему богомерзкого синтаксиса?

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

Согласен. Рукожопие и недостаток выразительности в Go присутствует на высоком уровне. :)

Паскаль взлетел и даже нельзя сказать, что упал. Например, я недавно стал пользовать Double Commander и в линуксе, и в офтопике. На чём он написан? А уж сколько энтырпрайза на нём до сих пор крутится...

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

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

Согласен. Рукожопие и недостаток выразительности в Go присутствует на высоком уровне. :)

Тоже хотел написать, но сдержался :)

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

Ты просто не проник мыслью сквозь слой маркетинга.

но выкатили го и почти-д

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

Собственно, голанг-то взлетел, а д - нет. Судя по вакансиям.

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

выполняется init, если такой есть.

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

Выпилить такое решение можно было только из чистого идиотизма.

Так, короче, я всё сказал.

Есть и другие мнения же.

Ты чья реинкарнация? Судя по жирноте, ты уже давно накапливал её на лоре.

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

По сути в си таким же образом это работает.

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

Декомпозиция через интерфейсы тоже очень годный совет, да. ТС, внемли)

Целая одна программа, ну офигеть теперь. Причём довольно ненужная.

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

негуглируемым

https://pic4a.ru/93/wbL.png

ЧЯДНТ?

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