LINUX.ORG.RU

почему голанг - это кул

 


1

3

Голенгу никогда не догнать сишечку, потому что в нём нельзя циклические зависимости. В Си можно, в Паскале можно. Это, наверное, самая плохая новость для меня за всё время его изучения.

★★★★★

Ответ на: комментарий от den73

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

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

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

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

den73 ★★★★★ ()

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

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

anonymous ()
Ответ на: комментарий от WitcherGeralt

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

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

den73 ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

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

anonymous ()
Ответ на: комментарий от den73

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


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)
}
вполне валидный код.

anonymous ()
Ответ на: комментарий от den73

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

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

anonymous ()
Ответ на: комментарий от den73

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

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

anonymous ()
Ответ на: комментарий от WitcherGeralt

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

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

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

anonymous ()
Ответ на: комментарий от WitcherGeralt

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()

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

vtVitus ★★★★★ ()
Последнее исправление: vtVitus (всего исправлений: 2)
Ответ на: комментарий от WitcherGeralt

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

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

Deleted ()
Ответ на: комментарий от anonymous

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

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

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

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

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

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

feofan ★★★★★ ()
Ответ на: комментарий от feofan

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

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

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)

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

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

derlafff ★★★★★ ()
Последнее исправление: derlafff (всего исправлений: 1)
Ответ на: комментарий от den73

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

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

WitcherGeralt ★★ ()
Ответ на: комментарий от feofan

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

anonymous ()