херь нечитаемая эти чеки

питонистам понравится, логика задом на перед

херь нечитаемая эти чеки

Она в какой то мере делает код проще

а какие недостатки go вы считаете самыми опасными?

опасными? хороший вопрос 1. обработка ошибок. она сделана плохо, и вокруг нее появляется масса говнокода, от игнорирования ошибок до логирования их на всех уровнях вложенности 2. система типов. нам, как выяснилось, очень нужны типсуммы. сейчас мы эмулируем их на интерфейсах с тайпсвитчами, или делаем динамику на рефлексии. (тайпсвитч - тоже рефлексия.) 3. концептуальная неконсистентность. например, генерики, которые есть в языке, но не для программера. и еще масса всего. тут ничего поделать нельзя

питонистам понравится, логика задом на перед

не, check норм, вот handle уже несколько сомнительно

не, check норм, вот handle уже несколько сомнительно

об этой связке и речь

а раз уж начали про checked exceptions, то это скорее всего будет приводить к throws Exception или аналогу во многих местах

будет. то, что сейчас, тоже ко всякой херне приводи

да все читаемо когда привыкаешь, сейчас все спокойно читают код с err != nil и ниче, главное чтоб новая система решала имеющиеся проблемы имх

об этой связке и речь

ну вообще можно check и без handle юзать

трай тоже можно без кетча)

трай тоже можно без кетча)

ну не совсем, либо try finally, либо try catch

да и check - это не try

вопрос в том, нафиг нужен трай, если нет кетча, и зачем чек без хендела?

а где ты try увидел в гоу?

я ещё раз повторяю, try != check check без handle уже в принципе позволяет сократить код

заменив три строки одним словом

спасибо капитан, что бы я без тебя делал!

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

спасибо капитан, что бы я без тебя делал!

ну видимо запутался бы, учитывая твоё сравнение try и check

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

наверх пробрасывать же

без обработки

(ну если нужна обработка, то тогда уж handle или if err != nil)

Можно я немного офтопну? :) Никак не решу, как лучше хранить данные в реляционной бд (постгря). Данные - это связи между устройствами (сетевые линки). Самое простое - это табличка, скажем, links, в которой лежат интерфейсы (порты) обоих устройств. Ну, что-то вроде link: port1_id, port2_id Но тут вылазит дикое неудобство в том, что кто-то должен быть port1, а кто-то port2. Как это определять? Никак. То есть, все запросы по поиску будут вида where (port1=X and port2=Y) or where (port1=Y and port2=X) Как обычно такие задачи решаются? :)

можно при интсерте сортировать ид по возрастанию и вставлять соответственно в поля, доставать по тойже логике

тоже как-то через жопу

сохраняй как "port1_id:port2_id", "port2_id:port1_id"

и будут запросы вида where col1="X:Y" or col2="Y:X"

тоже как-то через жопу

а в чем проблема делать OR?

а в чем проблема делать OR?

что такое or?)

и будут запросы вида where col1="X:Y" or col2="Y:X"

ну так один фиг колхозить or/or

что такое or?)

WHERE cond1 OR cond2

а

лишнее неудобство

лишнее неудобство

fuuuuuuuuu

и неднозначность

ненормализованность)

работай дальше, реализацию потом всегда можно переделать 😂

ненормализованность)

А вот это очень спорно

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

работай дальше, реализацию потом всегда можно переделать 😂

ну примерно так и решил, да)

просто что-то в голове засело, что "вот неудобно, и всё"

> Данные - это связи между устройствами Это граф. Зачем было брать реляционную модель?

затем, что любая известная нам модель хорошо эмулируется в реляционной

В любом случае, храни и обратывай это как граф

затем, что любая известная нам модель хорошо эмулируется в реляционной

ну, есть и спец базы для этого, тем не менее

https://github.com/Champii/og

вот до чего мухоморы доводят!

В любом случае, храни и обратывай это как граф

это будет процента полтора от всех данных в постгре. Буквально несколько тысяч строк. Городить для этого отдельную БД? Лишаться нативных связей, форейн ключей, и обрабатывать всё софтом?

это будет процента полтора от всех данных в постгре. Буквально несколько тысяч строк. Городить для этого отдельную БД? Лишаться нативных связей, форейн ключей, и обрабатывать всё софтом?

http://devsonia.ru/2012/12/19/%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B3%D1%80%D0%B0%D1%84%D0%B0-%D0%B2-%D0%B2%D0%B8%D0%B4%D0%B5-%D1%80%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD/

не

Чятик, а есть какой-то внятный тлдр по модулям? Не мыслью по дереву о том зачем это, а как теперь с этим жить

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

а если вершины - равные, то и их оконечности равнозначны, и portX и portY могут меняться местами произвольно

https://github.com/Champii/og

ЗОЧЕМ

Чятик, а есть какой-то внятный тлдр по модулям? Не мыслью по дереву о том зачем это, а как теперь с этим жить

https://habr.com/post/421411/

https://habr.com/post/421411/

Такое себе чтиво, осталась дофига вопросов. Во-первых, это нифига не тлдр. Во-вторых, по одному вопросу к этой статье гуглить – проще другую найти. В-третьих, на русском что-то читать это моветон.

а если вершины - равные, то и их оконечности равнозначны, и portX и portY могут меняться местами произвольно

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

а причем тут индексы? я только о том, что при наличии pointX и pointY заранее неизвестно, какая вершина будет в pointX, а какая - в pointY, и придется перебирать/усложнять/OR`ать

а причем тут индексы? я только о том, что при наличии pointX и pointY заранее неизвестно, какая вершина будет в pointX, а какая - в pointY, и придется перебирать/усложнять/OR`ать

Храни две связи сразу. В обе стороны. При поиске одну из них найдешь, как бы не искал. А вобще просто погуглируй про работу с графами в SQL - тема не новая

угу, гуглю

А я вот от лени утилитку себе накорябал: https://github.com/aadz/unix-misc#tls-cert-info, чтобы не вспоминать постоянно ключики OpenSSL. Гляньте, что еще нормальному человеку бывает нужно знать про сертификат?

А я вот от лени утилитку себе накорябал: https://github.com/aadz/unix-misc#tls-cert-info, чтобы не вспоминать постоянно ключики OpenSSL. Гляньте, что еще нормальному человеку бывает нужно знать про сертификат?

curl -v "https://example.com/" почти тоже самое выдаёт

правда?

Только не ругайтесь на код сильно, если что. Я ведь Go только учить начал и вобще не настоящий программист :)

curl -v "https://example.com/" почти тоже самое выдаёт

нет, мне этого бывает мало, что curl показыват. И он не про сертификат, а сразу страницу тащит в случае -v - много лишнего.

Playing with Go module proxies https://roberto.selbach.ca/go-proxies/

https://open.microsoft.com/2018/08/28/announcing-project-athens-gophersource-go-community/ https://docs.gomods.io/ https://github.com/gomods/athens

https://github.com/scylladb/go-set

https://github.com/scylladb/go-set

👍

прикооооольна, лол

в дотнет чате зикурат школоло

админы тут приводят в чувство сообщество, это прекрасно

в дотнет чате зикурат школоло

ахахаха

ахахаха

я был там, не смог

я был там, не смог

)