Что за идиотизм с импортами в гуланге?

Я так примерно про rust рассуждаю :)

Ты сможешь зафиксироваться на последней совместимой версии, и пилить в отдельном бранче под новые версии (если оно тебе реально надо). А завязка на мастер означает, что ты _постоянно_ будешь бросать все дела и пилить совместимость.

Прочти ещё раз, что я написал. По соглашению у Go либы не может быть сломан API.

Новый API — новая либа. That's simple.

PS: если же либа не придерживается compatibility promise — время искать другую (или форкать).

А может первым делом лучше сделать, just works (as intended), и только потом заниматься мутью dependecy hell?

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

По соглашению у Go либы не может быть сломан API.
По соглашению.

Ха-ха-ха!

По соглашению у Go либы не может быть сломан API.

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

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

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

вон, посмотри на разработчиков GTK3/GLIB. у них опыта уже за 20 лет, и API научились не ломать, а существующие программы ломаются в каждом _релизе_, в процессе добавления новых фич, например когда меняется поведение существующих функций, чаще всего из-за непредвиденных побочных эффектов. и это релизы. не транк.

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

ты думаешь что хипсторы гулангеры в этом что-то понимают вообще? я вижу, что вот ты например вообще дупля не отбиваешь.. и если ты являешься типичным представителем - то дело совсем плохо.

Не знаю. Языку уже 6 лет. Я его активно пользую (не профессионально) с версии 1.0 (а это уже более 4 лет). Наступления, описанного тобой, ада ещё не видел. ;)

разработчики gtk3

API научились не ломать,

Просмеялся.

Просмеялся.

это правда, между прочим. ни разу на моей памяти не сломали API, хочешь верь, хочешь нет.

Языку уже 6 лет.

Ха-ха-ха! (2)

и если ты являешься типичным представителем

Я просто хобиист. Пою, что вижу. ;) Содом и Гомору не наблюдаю.

В 1.6 (который кстати намечается 17 декабря) вендоринг будет включён.

Но и без него, для моих мелких поделок, проблем я ещё не имел.

Ещё — GTK — это плохой пример для сравнения. Это гиганская семи-мололитная либа. Тут же мы имеем кучу мелких.

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

Скажи это oxygen-gtk3

Скажи это oxygen-gtk3

давай лучше ты скажешь какие именно API были сломаны, ок?

Большей частью мелкие, т.к. львиную чать потребностей покрывает stdlib.

Из «крупных», чем мне самому доводилось пользваться:

• github.com/BurntSushi/xgb — 66213 LoC — XCB
• github.com/go-gl/gl/v2.1/gl — 31234 LoC — OpenGL
• github.com/go-sql-driver/mysql — 6008 LoC — MySQL драйвер для database/sql
• github.com/mattn/go-sqlite3 — 2525 LoC — sqlite драйвер для database/sql
• github.com/kylelemons/gousb/usb — 1284 LoC — USB стек

30kloc+ это уже вполне достаточно, чтобы случайно что-то отломать. а если умеючи, то и в 5kloc можно заблудиться.

но да, это все мелочь пузатая.. емнип гтк в районе пол-лимона строк.

gtk engines выпилили. и постоянно api тем ломали. да, формально метод apply_theme(css) не сломан, но на деле — говно

Как использовать инструмент - дело программера, а не самого инструмента.

Однако если инструмент имеет неочевидные особенности - использовать его правильно - это искусство

Конечно это не то чтобы плохо, но у некоторых от этого бомбит :-)

Тут же мы имеем кучу мелких

Так это еще хуже. Допустим, ты понаподключал дюжину мелких либ, которые в свою очередь подключают еще россыпь либ, которые... И все это счастье тянется с мастера. Прошло 5 лет, где-то поломали апи (нарушив Соглашение, ай-ай-ай), кто-то самовыпилился с гитхаба (хипсторы непостоянные), и вот ты уже рвешь волосы на ж-пе, пытаясь разрулить весь этот граф. Тянуть с собой все зависимости - это тоже ж-па, потому что тянешь также и все баги, и через n лет столкнешься ровно с той же проблемой синхронизации с далеко улетевшими транками. Выход я вижу только один - писать на го только очень простые фигни, требующие лишь пару библиотек (желательно стандартных). Или так: написать на го вундервафлю и сбежать, сменив фамилию.

Однако если инструмент имеет неочевидные особенности

Perl? ;) Swiss army pocket chainsaw.

да, формально метод apply_theme(css) не сломан

именно.

а про то, что они ломают реализацию того, что сидит за API — так я про то же самое написал выше, с чем ты и начал спорить зачем-то.

Глянь выше — в реальной жизни мы гворим о дюжене либ с 10k LoC по медиану.

Всё остальное делается средствами stdlib (которая очень богата, и для которой действует compatibility promise).

Т.ч. можно рассуждать об эфимерном менеджере пакетов, а можно и shut-up and code!

чтобы случайно что-то отломать

Кстати, «случайно что-то отломать» не получится a priori — оно просто не соберётся. (В Go компиляторе нет «warning», есть только «error».) Т.ч. мы говорим только о логических ошибках в коде.

мы говорим только о логических ошибках в коде.

Мало этого что ли? У вас получается при _каждой_ сборке неиллюзорные шансы добавить багов и регрессий. Т.е. вообще невозможно добиться воспроизводимой сборки, если не тянуть все зависимости в vendor. Некий vasyan сделает по-пьяни кривой коммит и изменит 100500 сборок во всем мире. Нифига себе инженерия.

Т.ч. можно рассуждать об эфимерном менеджере пакетов, а можно и shut-up and code!

«Чо тут думать, трясти надо» (ц)

А вот тут вот опять выплывает, ранее в треде осмеяный, go test.

Итого, что мы имеем?

• Синтаксичечкие ошибки невозможны — за этим следит go build.
• Логические ошибки тоже невозмоны — за этми следит go test.
• Ergo: в HEAD всегда рабочий и корректный код.
• Смена API — смена либы.
• Так о чём тогда весь сыр-бор?

Так о чём тогда весь сыр-бор?

о реальном мире

Meanwhile in real world ...

Ладно, зайдём с другого направления: назовите мне конкретный пример, когда что-то было сломано. Или когда фиксация версий имела под собой какие-либо иные причины, кроме «боязни изменений» (а не то мой Г-код сломается!).

Логические ошибки тоже невозмоны — за этми следит go test

Тесты го сам пишет? До чего дошел прогресс!

Логические ошибки тоже невозмоны — за этми следит go test.

Там реализован искусственный интеллект? Или верификатор?

хипстеры
хипстер

Ты хоть знаешь, что это слово означает? Или ты просто следушь моде разбрасываться этим словом где попало?

Да посыл понятен: если все делать правильно, то будет зашибись. Программист на го не будет же говнокодить, как это вообще возможно? Манифест совместимости прочитал, go format, go build, go test => идеальный код. Налицо синдром фанбойства, хотя казалось бы beasty не пионэр.

Вот что ты проверяешь — то и тестит. В общем случае соответсвие поведения спецификации. (Или как там это раньше называлось? Unit-test?)

В любом случае иметь такое в самом языке — приятная и полезная плюшка.

Не пали контору! ;) Я просто пытаюсь понять причины появления тенденции «всё заморозить!». И имеет ли это и в самом деле ту ценность, про которую тут говорят. Особенно учитывая доступный функционал (и ограничения).

Манифест совместимости прочитал, go format, go build, go test => идеальный код.

Называй меня фанбоем, но это и в самом деле способстует. ;)

Вот что ты проверяешь — то и тестит.

Я правильно понимаю, ты предлагаешь писать тесты для ВСЕХ используемых библиотек на соответствие спецификациям?

Я просто пытаюсь понять

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

Наброшу малость. Я тут полистал букварь под впечатлением от треда, так вот весь язык производит впечатление игрушечного и наколенного, а не только импорт. Сломался на специальных кейвордах (range, append, make) только для отдельных _встроенных_ типов. Полиморфизм через пустой интерфейс тоже песня конечно. Теперь уже желание отпало даже палочкой тыкать. Почему то считал, что го - это что-то вроде сисярпа или в худшем случае типизированного питона. Вот так облом, бросок на три десятилетия назад.

Нет, не тебе, это задача составителя библиотеки. (И этаблированная good practice в go экосистеме.)

• Ошибки невозможны — за этим следит намагниченная иголка и твердая рука.

О чем тогда весь сыр-бор? Программное обеспечение вообще переоцененное.

В треде разжеван подход «как обычно», мне же интересно «как надо было бы».

Нет, не тебе, это задача составителя библиотеки. (И этаблированная good practice в go экосистеме.)

Но если автор библиотеки поменял и поведение библиотеки, и тесты, как я об этом узнаю?

По ответам своих тестов (на свой код), которые ты тоже должен был бы писать.

Но вообще, где тут провести линию? Авторитетного комитета по корректности кода ещё нет. IMHO каждый в ответе за свой код.

Но если автор библиотеки поменял и поведение библиотеки

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

По ответам своих тестов (на свой код), которые ты тоже должен был бы писать.

А что делать, если тесты фейлятся из-за несовместимости? Ты же не знаешь даже какая у тебя версия либы. Искать тот коммит, с которым еще все работало? А как его подключить, если у вас только на мастер ссылки? Откатывать руками и вендорить? По-моему это уже хелл в полный рост. Вы там наверно все мастера гита 80 левела, а без гитхаба разработка на го невозможна как я понял.

https://youtu.be/PAAkCSZUG1c

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

Java не самый лучший пример.

завязка на мастер это детский сад какой-то

Согласен. Go вообще не производит впечатление серьезного инструмента. Но свою нишу он видимо нашел. А это главное.

то сколько копий библиотеки foo у тебя будет?

ты давно пользовался npm? в npm3, будет 1 библиотека, если у тебя явно не указаны разные версии жестко которые не совместимы

В Perl это сразу обговаривается