зачем мне это потом при сборке )

Ребят у меня в монге проблема unknown top level operation: $expr

Монга 4.0

Куда где искать? Откуда эта проблема?

Какого хрена я вообще начал на монге это всё делать?

https://play.golang.org/p/iFd1ld5iLT6

@onokonem https://github.com/romshark/Go-2-Proposal---Immutability#310-why-do-we-need-the-distinction-between-immutable-and-mutable-reference-types

Товарищи коллеги, помогите до конца разобраться пожалуйста) почему таки https://play.golang.org/p/KTQUsHo6Be- &n2 убегает в кучу?

а зачем ты хоронишь структуру

Так middleware нужен

решил попрактиковаться.Вопрос по gorilla/sessions после удачной аутентификации запускается сессия и в sessions.Value ["user"] = userid в userid хранится что?токен или просто login пользователя и для чего непосредственно нужен session.Value?

решил попрактиковаться.Вопрос по gorilla/sessions после удачной аутентификации запускается сессия и в sessions.Value ["user"] = userid в userid хранится что?токен или просто login пользователя и для чего непосредственно нужен session.Value?

Шли токе в хедер, который есть, если все ок, middleware берет из токена id юзера и пихает его куда надо

Так middleware нужен

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

/

Добрый день. Хотел бы уточнить небольшой вопрос по поводу мьютексов и слайса данных. У меня стоит мьютекс на запись данных и на удаление. А вот на чтение слайса - нет. Будут ли проблемы если при фориче слайса в него будет добавляться элемент или удаляться? Нужно ли ставить мьютекс и на чтение?

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

https://ru.coursera.org/lecture/golang-webservices-2/osnovy-middleware-dlia-http-BSs7A

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

Ну если ты гориллу пользуешь

https://medium.com/@matryer/writing-middleware-in-golang-and-how-go-makes-it-so-much-fun-4375c1246e81

На медиумеме хорошо было

Я как то глянул go-chi и очень нравится

https://ru.coursera.org/lecture/golang-webservices-2/osnovy-middleware-dlia-http-BSs7A

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

Я как то глянул go-chi и очень нравится

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

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

Все равно ну, без gorilla mux тяжело вытаскивать параметры url

А так да

Думаю хороший вариант писать на net/http

Добрый день. Хотел бы уточнить небольшой вопрос по поводу мьютексов и слайса данных. У меня стоит мьютекс на запись данных и на удаление. А вот на чтение слайса - нет. Будут ли проблемы если при фориче слайса в него будет добавляться элемент или удаляться? Нужно ли ставить мьютекс и на чтение?

Будут проблемы, на чтение тоже нужно мьютексом закрыть. Можно rwmutex взять для производительного чтения)

Будут проблемы, на чтение тоже нужно мьютексом закрыть. Можно rwmutex взять для производительного чтения)

Спасибо, гляну

О! https://www.youtube.com/watch?v=rWJHbh6qO_Y Фитцпатрик говорит, что мы не будем убивать уже существующий код - it always will be usable. Типа, код из Go1 будет продолжать нормально комплироваться в Go2

ну норм че

а потом сделают "дефолтную имплементацию интерфейса"

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

О! https://www.youtube.com/watch?v=rWJHbh6qO_Y Фитцпатрик говорит, что мы не будем убивать уже существующий код - it always will be usable. Типа, код из Go1 будет продолжать нормально комплироваться в Go2

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

Ну, ни про какой такой интерфейс речи не было, вроде. Просто сказал, что определеннно не собираются убивать существующий код и экосистему Go

еще раз - есть множество способов это обеспечить и не тянуть с собой обратную совместимость

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

Я и с первым-то еще не до конца разобрался. :)

стоп

так ведь go2 = go1 + новые фичи

этого мы не знаем

я вот вообще думаю, что go2 не будет в обозримом будущем

я вот вообще думаю, что go2 не будет в обозримом будущем

Почему?

так ведь go2 = go1 + новые фичи

но поопасаться-то надо? Уж лучше переопасаться, чем недо...

не нужен

ну или можно предположить, что go2 = go1 + новые фичи + небольшие незначительные изменения

не нужен

go не нужен?

не нужен

ага, конечно

go2 не нужен

не нужен

А Фитцпатрик и сказал, что еще не решили, может быть будет Go 1.12 и так далее, а никакой не 2

у go1 есть недостатки, но в общем он покрывает всю поляну

go2 окажется конкурентом go1, и этоне нужно никому. поэтому будет go1+новые_совместимые_фичи

у go1 есть недостатки, но в общем он покрывает всю поляну

Не буди лихо... :)

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

конечно

у go1 есть недостатки, но в общем он покрывает всю поляну

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

ведь краткий проброс ошибок - это так тупо

ведь краткий проброс ошибок - это так тупо

тупо мусолить эту тему в этом чате в сотый раз (я вот думаю, что нам таки нужны checked exceptions, но не сообщаю об этом всем постоянно)

не я начал

go2 не нужен

тупо мусолить эту тему в этом чате в сотый раз (я вот думаю, что нам таки нужны checked exceptions, но не сообщаю об этом всем постоянно)

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

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

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

ERROR: S client not available

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

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

а какие недостатки 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

а