ну то есть между понятиями "дженерики" и встроенными обощёнными структурами данных вы разницы не видете. Ок, так и запишем

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

И поэтому переменную нужно объявлять предварительно и передавать указатель на неё в качестве аргумента

И что в этом такого. Учитывая что обычная структура без указателя интерфею не соответсвует.

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

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

func (t *TaskManager) Command(task *models.Task, account *models.Account, params interface{}) error Или вот, попробуйте, называется, догадаться что там за параметры могут быть в params

func (t *TaskManager) Command(task *models.Task, account *models.Account, params interface{}) error Или вот, попробуйте, называется, догадаться что там за параметры могут быть в params

О. Это API дурацкий.

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

они не нужны, роб пайк же сказал, что не нужны, значит не нужны

О. Это API дурацкий.

Нет, это отсутствие типов сумм.

Начиная от пакета models. Заканчивая использованием не интрефейсов.

func (t *TaskManager) Command(task *models.Task, account *models.Account, params interface{}) error Или вот, попробуйте, называется, догадаться что там за параметры могут быть в params

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

Начиная от пакета models. Заканчивая использованием не интрефейсов.

С интерфейсами код не перестает дублироваться, внезапно

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

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

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

Ты не структуры приводи а их использование.

С интерфейсами код не перестает дублироваться, внезапно

Эмм. У меня он обычно не начинает.

мне кажется, что наш лагерь разбился на тех, для кого golang первый язык и они не понимают, зачем дженерики, и тех, кто видел/писал на плюсах/java/c#

мне кажется, что наш лагерь разбился на тех, для кого golang первый язык и они не понимают, зачем дженерики, и тех, кто видел/писал на плюсах/java/c#

+Rust, SML, OCaml, Scala...

Главное не забывать про то, что без типов сумм программировать нельзя. Не спрашивайте, что это значит. Это первая заповедь программиста! Она не подлежит обсуждению.

мне кажется, что наш лагерь разбился на тех, для кого golang первый язык и они не понимают, зачем дженерики, и тех, кто видел/писал на плюсах/java/c#

в C# дженерики только дураки используют, ведь дженерики не нужны же, все нормальные пацаны в C# используют исключительно object в джаве тоже

Ты не структуры приводи а их использование.

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

мне кажется, что наш лагерь разбился на тех, для кого golang первый язык и они не понимают, зачем дженерики, и тех, кто видел/писал на плюсах/java/c#

я писал всю жизнь на плюсах и C#. После Го меня от них тошнит

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

Если это очень большая очередь то ты делаешь 2 сервиса, RabbitMQ например и поднимаешь кучу экземпляров.

"микросервисы"

я писал всю жизнь на плюсах и C#. После Го меня от них тошнит

Так, а всю жизнь это сколько лабораторок?)

Так, а всю жизнь это сколько лабораторок?)

Дада. Типичная аппеляция к "я просто более опытный" без каких либо оснований.

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

Дада. Типичная аппеляция к "я просто более опытный" без каких либо оснований.

Так тут же была аппеляция к авторитету роба пайка

Так тут же была аппеляция к авторитету роба пайка

Это был ответ на попытку просто принизить его непонятно зачем.

Дада. Типичная аппеляция к "я просто более опытный" без каких либо оснований.

Так в этом же сосоит весь цимес! Придать своим словам убедительности, самоутвердиться как-то

Ты не структуры приводи а их использование.

зачем? это же многабукф, куча саршип-опреаторов и прочего срашного говнокода, не убедительно будет совсем Чтобы не быть голословным, возьмем для примера код heap’а на Scala или на Go. Какой из них проще понять и рефакторить? Зачем в реализации heap’а на Scala такие абстракции, как stream, forest, fold, rank, flatten, map, singleton, monoid? Без них никак нельзя? :) https://github.com/scalaz/scalaz/blob/series/7.3.x/core/src/main/scala/scalaz/Heap.scala https://golang.org/src/container/heap/heap.go на этом савим жырную точку в этом базаре

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

Ну так го - обрубок от ЯП с нулевыми возможностями для расширения. Есть стандартная библиотека и всё, шаг вправо, шаг влево - растрел.

Лучше уж рубанком делать реальные проекты, чем ваять в подвале для себя :)

Лучше уж рубанком делать реальные проекты, чем ваять в подвале для себя :)

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

зачем? это же многабукф, куча саршип-опреаторов и прочего срашного говнокода, не убедительно будет совсем Чтобы не быть голословным, возьмем для примера код heap’а на Scala или на Go. Какой из них проще понять и рефакторить? Зачем в реализации heap’а на Scala такие абстракции, как stream, forest, fold, rank, flatten, map, singleton, monoid? Без них никак нельзя? :) https://github.com/scalaz/scalaz/blob/series/7.3.x/core/src/main/scala/scalaz/Heap.scala https://golang.org/src/container/heap/heap.go на этом савим жырную точку в этом базаре

Чем меньше абстракций - тем лучше?

Чем меньше абстракций - тем лучше?

Го - против бесполезных абстракций и монадирующих программистов. тут подробности https://medium.com/@kaveh.shahbazian/abstractions-the-costs-b0c00835aa8d

зачем? это же многабукф, куча саршип-опреаторов и прочего срашного говнокода, не убедительно будет совсем Чтобы не быть голословным, возьмем для примера код heap’а на Scala или на Go. Какой из них проще понять и рефакторить? Зачем в реализации heap’а на Scala такие абстракции, как stream, forest, fold, rank, flatten, map, singleton, monoid? Без них никак нельзя? :) https://github.com/scalaz/scalaz/blob/series/7.3.x/core/src/main/scala/scalaz/Heap.scala https://golang.org/src/container/heap/heap.go на этом савим жырную точку в этом базаре

Чтобы использовать heap там, где от объекта требуется быть только стримом, лесом, свёртываемым объектом, функтором или моноидом, очевидно же.

Го - против бесполезных абстракций и монадирующих программистов. тут подробности https://medium.com/@kaveh.shahbazian/abstractions-the-costs-b0c00835aa8d

И как же мы выбираем какая абстракция полезная, а какая нет?

Го - против бесполезных абстракций и монадирующих программистов. тут подробности https://medium.com/@kaveh.shahbazian/abstractions-the-costs-b0c00835aa8d

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

Чем меньше абстракций - тем лучше?

Конечно, ведь чем меньше абстракций, тем выше шанс, что они уместятся в голове типичного гофера

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

Ну дженерики и монады это же одно и то же, ненужные абстракции

И как же мы выбираем какая абстракция полезная, а какая нет?

Какие абстракции Роб Пайк встроил в Go - такие полензые, остальные - нет

Company: Bitfury (Blockchain) Position: Senior Go / Golang Developer Short Description: We are looking for a Go programming language expert to join our team to design APIs, functionality and solutions for the next-gen financial services based on cutting edge blockchain technologies. Location: Novosibirsk Salary: $3+K Net depending on skills Full JD: https://spb.hh.ru/vacancy/25674491 #вакансия

Ну дженерики и монады это же одно и то же, ненужные абстракции

примерно так. Дженерики мало кому нужны. Для особо упоротых есть github.com/ncw/gotemplate . Только почему-то дальше парочки стандартных структур (list, ring, set, heap) и алгоритмов (sort) дело не пошло. Причем необходимость list и ring высосана из пальца: — вместо list проще и эффективнее использовать стандартный слайс — ring используется чуть меньше, чем в одном проекте на миллион, где проще написать один раз реализацию этого ring под конкретный тип в 10 строчек. Set тоже легко заменяется стандартной map[key]struct{}, хотя синтаксический сахарок тут уже поприятнее. Остается лишь дженерики для heap и sort, которые необходимы лишь в небольшом проценте оптимизированных по скорости программ, где стандартные heap и sort на интерфейсах не подходят из-за накладных расходов на вызов интерфейсных функций. Приведите примеры из настоящих программ, где еще могут понадобиться эти дженерики? вот только если у вас есть трудности с пониманием того, чем настоящая программа отличается от академического плана - лучше не надо

Отключаюсь, резюмируйте потом, пожалуйста- чем закончился очередной флейм и кто победил

Отключаюсь, резюмируйте потом, пожалуйста- чем закончился очередной флейм и кто победил

резюмирую: все присвоем, никто не победил

примерно так. Дженерики мало кому нужны. Для особо упоротых есть github.com/ncw/gotemplate . Только почему-то дальше парочки стандартных структур (list, ring, set, heap) и алгоритмов (sort) дело не пошло. Причем необходимость list и ring высосана из пальца: — вместо list проще и эффективнее использовать стандартный слайс — ring используется чуть меньше, чем в одном проекте на миллион, где проще написать один раз реализацию этого ring под конкретный тип в 10 строчек. Set тоже легко заменяется стандартной map[key]struct{}, хотя синтаксический сахарок тут уже поприятнее. Остается лишь дженерики для heap и sort, которые необходимы лишь в небольшом проценте оптимизированных по скорости программ, где стандартные heap и sort на интерфейсах не подходят из-за накладных расходов на вызов интерфейсных функций. Приведите примеры из настоящих программ, где еще могут понадобиться эти дженерики? вот только если у вас есть трудности с пониманием того, чем настоящая программа отличается от академического плана - лучше не надо

вместо list проще и эффективнее использовать стандартный слайс интересно почему это?

Отключаюсь, резюмируйте потом, пожалуйста- чем закончился очередной флейм и кто победил

какая разница? Человечество спасут монадирующие программисты. Инфа 100%

Флейма не было бы если бы все в чате имели одинаковые скиллы)

какая разница? Человечество спасут монадирующие программисты. Инфа 100%

ДА ПРИЧЁМ ТУТ МОНАДЫ?????

зачем? это же многабукф, куча саршип-опреаторов и прочего срашного говнокода, не убедительно будет совсем Чтобы не быть голословным, возьмем для примера код heap’а на Scala или на Go. Какой из них проще понять и рефакторить? Зачем в реализации heap’а на Scala такие абстракции, как stream, forest, fold, rank, flatten, map, singleton, monoid? Без них никак нельзя? :) https://github.com/scalaz/scalaz/blob/series/7.3.x/core/src/main/scala/scalaz/Heap.scala https://golang.org/src/container/heap/heap.go на этом савим жырную точку в этом базаре

лул. во-первых толсто. во-вторых не в scala, а в scalaz, если не знаете разницу - не позорьтесь. в третьих, скала и тем более скалаз - отдельная тема, люди действительно могут немного упороться по матану.

ладно, ребятки, давайте 5 минут на завершение, или я принудительно завершу

Флейма не было бы если бы все в чате имели одинаковые скиллы)

s/Флейма/чата/g

лул. во-первых толсто. во-вторых не в scala, а в scalaz, если не знаете разницу - не позорьтесь. в третьих, скала и тем более скалаз - отдельная тема, люди действительно могут немного упороться по матану.

ух ты ж ёшкин кот как это важно - скала и скалаЗЗ, этож совсем другое, простите

ух ты ж ёшкин кот как это важно - скала и скалаЗЗ, этож совсем другое, простите

Ну, вообще-то да

какая разница? Человечество спасут монадирующие программисты. Инфа 100%

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

ух ты ж ёшкин кот как это важно - скала и скалаЗЗ, этож совсем другое, простите

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

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

чет вы так нервничаете и почерк какой-то кривой. дышите ровно бро

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

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

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

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

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

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

о, я не буду себя ограничивать

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

Поднять базу ради контейнера? Это мощно

Поднять базу ради контейнера? Это мощно

Так стейтлесс и микросерисы. Скейлится хорошо зато.

Так стейтлесс и микросерисы. Скейлится хорошо зато.

Кхм. По твоему, если состояние выносится в БД — это stateless?

Кхм. По твоему, если состояние выносится в БД — это stateless?

ну это еще не все, конечно. Просто контейнеры - один из стейтов.

Кст ни у кого не возникало задачи получения id докер контейнера в котором запущен скрипт?

Возникало

ну это еще не все, конечно. Просто контейнеры - один из стейтов.

Пошел полный бред дальше, извините. Но чтоб контейнеры называли стейтом в контексте стейтлесс-приложений это я еще не видел

ERROR: S client not available

Возникало

Как решили?

Как решили?

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

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

У меня он тоже не только для этого прокинут

Ну тогда вот решение

Весело у вас тут

Там в итоге можно даже курлом и jq обойтись

вместо list проще и эффективнее использовать стандартный слайс интересно почему это?

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

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

это был риторический вопрос

нуну

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

это наброс. слайс не всегда "лучше" использовать, есть задачи, для которых linked list в разы лучше

Здравствуйте, никто не хочет побыть ментором? Мне нужен ментор\помошник возможно консультант, не знаю как правильнее будет звучать - проконсультировать по архитектуре и так далее, выслушать мои мысли и скорректировать их в нужном направлении. Не задаю вопросов не прогуглив всё что только можно, неплохо знаю английский, буду задавать только конкретные вопросы касаемо направления и лучшего решения в той или иной ситуации. Не бесплатно конечно. И не слишком часто. Буду рад фидбеку, спасибо

чат в том числе для этого. бесплатно. велкам

Здравствуйте, никто не хочет побыть ментором? Мне нужен ментор\помошник возможно консультант, не знаю как правильнее будет звучать - проконсультировать по архитектуре и так далее, выслушать мои мысли и скорректировать их в нужном направлении. Не задаю вопросов не прогуглив всё что только можно, неплохо знаю английский, буду задавать только конкретные вопросы касаемо направления и лучшего решения в той или иной ситуации. Не бесплатно конечно. И не слишком часто. Буду рад фидбеку, спасибо

Не бесплатно - это сколько?

У кого-нибудь возникала необходимость засунуть в reflect.Value у которого к примеру *int внутри и засунуть в него другой reflect.Value c типом int внутри и наоборот. бьюсь на этим вопросом уже пятый час и не помогли многократное чтение документации, гугл. Может кто справлялся с подобной проблемой? https://play.golang.org/p/OpYQHIocNF2

path, id, err = list[0], strconv.Atoi(list[1]) Как записать это правильно? ./scan.go:356: multiple-value strconv.Atoi() in single-value context ./scan.go:356: assignment count mismatch: 3 = 2

Ты хочешь заполнить 3 переменные, а кладешь всего 2

path, id, err = list[0], strconv.Atoi(list[1]) Как записать это правильно? ./scan.go:356: multiple-value strconv.Atoi() in single-value context ./scan.go:356: assignment count mismatch: 3 = 2

в две строки?

Ты хочешь заполнить 3 переменные, а кладешь всего 2

path, id = list[0], strconv.Atoi(list[1]) /scan.go:356: multiple-value strconv.Atoi() in single-value context

path, id, err = list[0], strconv.Atoi(list[1]) Как записать это правильно? ./scan.go:356: multiple-value strconv.Atoi() in single-value context ./scan.go:356: assignment count mismatch: 3 = 2

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

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

питон

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

Питон

даже питон вот конкретно так не умеет

Крч как мне изящнее поступить чтобы не заводить кучу переменных?

даже питон вот конкретно так не умеет

Умеет

Крч как это можно сделать изящно?

Подскажите

в любом случае раскидать в 2 строки, в одной определить path, в другой id и err

Умеет

https://repl.it/repls/DifferentTiredCoordinate не умеет

ну с оговорками a, (b, c) = 1, return_tuple()

в любом случае в голанге так не выйдет

ну с оговорками a, (b, c) = 1, return_tuple()

ну так ты фактически распаковываешь на две переменные, а потом вторую переменную еще на две, это именно сахар