не в этом чате, а в том

точно перепутал

это тут 1705

только постараться себя не зобанить

не-не-не

им надо просто выключать write

это и есть restrict

тогда если что можно и починить

restrict разный бывает

тогда 1847 id

другой разговор ?

https://twitter.com/golang/status/1034471897948454912?s=09

вот такая стата по уникальным id: unique: 2677 ProGo: 972 GoGoland: 830 intersect: 875

что с id делать, непонятно. добавлять от клиента - навреняка бан после десятка жалоб. Отдать боту? Какому боту? Бот не может инициировать общение с юзером.

не

нам нужно апдейтнуть права юзера

которого?

меня?

в том чате?

как-раз таки нет, нам надо будет запустить это от имени @onokonem и пробежаться по списку progo, убрав write у всех подряд

в смысле рид онли сделать у всего списка?

дальше что? предложить перейти сюда?

таки да

ну это таки можно

в этом-то и суть идеи

не в рассылке же спама

И пришпилить там сообщение, что все ушли в Go,go!

И пришпилить там сообщение, что все ушли в Go,go!

ну типа так и хотят. только для мотивации еще ро всем поставить

И пришпилить там сообщение, что все ушли в Go,go!

запостить Морфиуса с 2-мя кнопками - Красная и Синяя таблетки. Синяя снимает ро, Красная редиректит сюда

но синей нет

А тут приставить бота, который всем с того канала будет при подключении сюда говорить: "Добро прожаловать в реальный мир, сынок"

тогда выбор между красной и красной

тогда выбор между красной и красной

вот да

Морфиус, кстати, есть на обоих каналах, но зовут его Даниил. Он всех возвращает в реальный мир :)

Всем привет! Можно где то почитать о кодогенерации в go "на пальцах", с примерами?

Всем привет! Можно где то почитать о кодогенерации в go "на пальцах", с примерами?

godoc?

godoc?

Не совсем понимаю, где это вообще применяется

Ну, и как правильно

go:generate просто запускает команду, которая генерит файлики

фсё

https://twitter.com/golang/status/1034471897948454912?s=09

Все же generics будут

https://m.youtube.com/watch?v=6wIP3rO6On8#

Go 2 Draft Designs (Score: 109+ in 47 minutes) Link: https://readhacker.news/s/3PH9V Comments: https://readhacker.news/c/3PH9V

https://m.youtube.com/watch?v=6wIP3rO6On8#

ООП не завезли?

ООП не завезли?

А зачем в go наследование?

А зачем в go наследование?

А почему бы и нет, если оно есть в большинстве языков?

(PHP,Python,Ruby, C++, Java)

Ну это застрелится

оппа, error handling

А почему бы и нет, если оно есть в большинстве языков?

Ну с таким аргументом можно и по другому, «зачем в других языках есть наследование»? Если можно и без него, например как в go)

Давайте выпилим)

коллега

остановитесь

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

кое-что при этом впилено, и это еще лучше

А почему бы и нет, если оно есть в большинстве языков?

https://habr.com/post/243593/ https://habr.com/post/225907/ пожалуйста, не делайте из Go "клон большинства языков"! Большинство языков это вечный легаси который тянули ради совместимости десятилетиями, не надо начинать новый язык с легаси!! Дело не в том, что авторы Go были недостаточно компентентны чтобы впилить в Go наследовательность имплементации, а наоборот, они были достаточно компетентны чтобы НЕ включать сиё чудовище в новый свежый язык без легаси. Автор Java James Gosling сам заявил, что если бы смог начать разработку Java сначала - он бы убрал наследовательность типов и оставил только интерфейсы (https://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html)

Коллеги, а есть у кого-то примеры передачи через cgo char**?

нужно из сишки салоцированую строку вернуть

Вот это наброс на вентилятор https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md

Вот это наброс на вентилятор https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md

вы аргументировать собираетесь, сударь?)) или вам бы лишь свои 2 копейки обмазанные в, извиняюсь, шоколаде вставить

Чем вам включение типов не наследование

Чем вам включение типов не наследование

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

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

Ну, по-моему это наследования никак не касается

Ну, по-моему это наследования никак не касается

по-моему это одна из ключевых разниц между наследованием и встраиванием

по-моему это одна из ключевых разниц между наследованием и встраиванием

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

ERROR: S client not available

Я же правильно понимаю, предок должен быть осведомлён о потомке, и мочь вызывать его методы и всякое такое?

Вот это наброс на вентилятор https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md

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

Я же правильно понимаю, предок должен быть осведомлён о потомке, и мочь вызывать его методы и всякое такое?

https://travix.io/type-embedding-in-go-ba40dd4264df

что-то навскидку лучше не нагуглилось, а сам не могу что-то адекватное придумать)

что-то навскидку лучше не нагуглилось, а сам не могу что-то адекватное придумать)

Спасибо, теперь понял что искать )

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

вы аргументировать собираетесь, сударь?)) или вам бы лишь свои 2 копейки обмазанные в, извиняюсь, шоколаде вставить

Какие аргументы хотите? Технические? Мне нравится предложение, действительно сократит кол-во копипасты. Хотя конечно надо понимать, чтоб до релиза оно может доехать в совсем другом виде. Но пока выглядит достойно, читаемо. Гораздо интереснее наблюдать какие бурления ваших шоколадов начнутся в сообществе. Ну а во что макать - думаю, сами разбиретесь;)))

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

Git )

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

ИМХО нужны не инструменты, а умение выполнять и заканчивать проекты в рамках бизнес-требований заказчика

Какие аргументы хотите? Технические? Мне нравится предложение, действительно сократит кол-во копипасты. Хотя конечно надо понимать, чтоб до релиза оно может доехать в совсем другом виде. Но пока выглядит достойно, читаемо. Гораздо интереснее наблюдать какие бурления ваших шоколадов начнутся в сообществе. Ну а во что макать - думаю, сами разбиретесь;)))

технические) ибо деструктивная критика это лишнее, раз утверждаешь так поясни ?

вообще - пока даже задачу, в которой генерики были бы уместны (кроме коллекций) никто не сформулировал

последняя попытка была про тип-сумму, а не про генерики

вообще - пока даже задачу, в которой генерики были бы уместны (кроме коллекций) никто не сформулировал

самое очевидное это контейнерные типы

да вот я не очень понимаю, зачем они нужны именно в генерализованном виде

это же про code reuse

да вот я не очень понимаю, зачем они нужны именно в генерализованном виде

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

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

было бы конечно прикольно если они придумали языковую конструкцию для сокращения кода обработки ошибок, но я чёт пока это вообще не представляю, как это возможно и возможно ли вообще

да вот я не очень понимаю, зачем они нужны именно в генерализованном виде

пока они не нужны вообще — то конечно не нужны и в генерализованном типе вы их не видите, потому что на Go их никто не пишет почти, кроме некоторых фанатиков а как только нужны какие-нибудь графы направленные, где у тебя ноды могут быть ещё и разного типа, так у тебя Go превращается в мешанину кастов, тайп свитчей и пустых интерфейсов да и просто можно поглядеть на такие прекрасные конструкции как map[string]interface{} на каждом месте, где надо работать с динамическими данными, и которые взрывается потому что где-то в глубине вместо int кто-то положил json.Number и ты не поймёшь в чём дело пока не пересмотришь большую часть кода приложения глазами а писать самому под конкретный тип бывает нетривиальной задачей в случае некоторых алгоритмов я понимаю что для CRUD это не нужно, но невозможность писать такие вещи просто и приятно как раз и ограничивает Go в CRUD

пока они не нужны вообще — то конечно не нужны и в генерализованном типе вы их не видите, потому что на Go их никто не пишет почти, кроме некоторых фанатиков а как только нужны какие-нибудь графы направленные, где у тебя ноды могут быть ещё и разного типа, так у тебя Go превращается в мешанину кастов, тайп свитчей и пустых интерфейсов да и просто можно поглядеть на такие прекрасные конструкции как map[string]interface{} на каждом месте, где надо работать с динамическими данными, и которые взрывается потому что где-то в глубине вместо int кто-то положил json.Number и ты не поймёшь в чём дело пока не пересмотришь большую часть кода приложения глазами а писать самому под конкретный тип бывает нетривиальной задачей в случае некоторых алгоритмов я понимаю что для CRUD это не нужно, но невозможность писать такие вещи просто и приятно как раз и ограничивает Go в CRUD

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

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

ну а вообще, то конечно дженерики и типы суммы не нужны, так же как и непустые интерфейсы нет ничего такого, чего нельзя было бы сделать с помощью interface{}, switch и рефлексии вопрос в том, сколько убитых нервов и часов работы будет стоить вам отладка всего этого недо-питона

ну и кто смотрел на kubernetes с его рантайм дженериками — тот больше в цирке не смеётся, а плачет

пока они не нужны вообще — то конечно не нужны и в генерализованном типе вы их не видите, потому что на Go их никто не пишет почти, кроме некоторых фанатиков а как только нужны какие-нибудь графы направленные, где у тебя ноды могут быть ещё и разного типа, так у тебя Go превращается в мешанину кастов, тайп свитчей и пустых интерфейсов да и просто можно поглядеть на такие прекрасные конструкции как map[string]interface{} на каждом месте, где надо работать с динамическими данными, и которые взрывается потому что где-то в глубине вместо int кто-то положил json.Number и ты не поймёшь в чём дело пока не пересмотришь большую часть кода приложения глазами а писать самому под конкретный тип бывает нетривиальной задачей в случае некоторых алгоритмов я понимаю что для CRUD это не нужно, но невозможность писать такие вещи просто и приятно как раз и ограничивает Go в CRUD

а еще это мешает нормальному оптимизирующему компилятору

https://m.youtube.com/watch?v=6wIP3rO6On8#

ну все, смена парадигмы. теперь похоже генерики нужны. та же история что с менеджером пакетов.

ну а вообще, то конечно дженерики и типы суммы не нужны, так же как и непустые интерфейсы нет ничего такого, чего нельзя было бы сделать с помощью interface{}, switch и рефлексии вопрос в том, сколько убитых нервов и часов работы будет стоить вам отладка всего этого недо-питона

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

но

не будет ли лекарство горше болезни?

я, в общем, очень ценю возможность легко понять, где же именно определено поведение того объекта, на который я сейчас гляжу

не будет ли лекарство горше болезни?

если это будет сделано в стиле го – минимализм и единство стиля, то думаю нет в любом случае, если этого не делать, то го просто помрёт

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

если это будет сделано в стиле го – минимализм и единство стиля, то думаю нет в любом случае, если этого не делать, то го просто помрёт

go 1 помрет в любом случае и пускай но мне бы хотелось ему на замену язык не хуже