« Rev
@gogolang   1248
Fwd »


Pawel
нигде, очевидно же не нужны людям никакие деревья и стеки это всё от дьявола
ну поскольку ты пример не привёл, ты то точно не используешь. а всё туда же
Pawel
вопрос из разряда, "а где используется logrus"
нормальный вопрос. Если ты считаешь что это вот прям всем нужно, покажи пример где оно интенсивно юзается. Иначе все эти заявления про то как мы не можем жить без двоичных деревьев - чёс
Pawel
у вас логика сломана
это у вас. Вы не в состоянии показать ни одной полезной строчки кода в подтверждение своих слов.
Pawel
Кароч не интересно с вами. Вы демагоги
Alexander
если вам хватает из коробки тех контейнеров, которые есть в го, не значит что остальным не нужно большего
саша
Если бы не гоферы, то я бы и не знал, что существуют люди, которые считают, что в статически типизированном языке не нужны дженерики
Алексей
Вообще Go сейчас напоминает Java до появления дженериков, там тоже есть супертип Object, которому можно приводить любое значение. Только дженерики в Java всё таки ввели, хоть и порезанные немножко.
Pawel
Если бы не этот чат, я бы не знал что для некоторых джененрики имеют ценность сами по себе без относительн опрактичекой применимомсти
Alexander
а твои бинарные деревья где? покажи
я кажется довольно неплохим русским языком написал, без какой сильно не стандартной структуры я бы не обошелся
Cat
а твои бинарные деревья где? покажи
Вот тут согласен на все 100% Деревья не нужны!
саша
func (ep *BaseEndpoint) ParseBody(r *rest.Request, v interface{}) error У нас на проекте есть функция с такой сигнатурой. Она парсит JSON из тела запроса и помещает его в v. Надо ли говорить зачем тут нужен дженерик?
Vladislav
Как это решит?
Cat
То что вы там хотите использовать дженерики не значит, что они нужны!
Cat
— дженерики не нужны!
Alexander
😁 вообще банить за упоминание дженериков, кажется не такой уж плохой идеей.
Chebyrash
Если бы не этот чат, я бы не знал что для некоторых джененрики имеют ценность сами по себе без относительн опрактичекой применимомсти
Генерики имею очень большую ценность. Они позволяют писать код, который такие дауны не поймут. Что позволяет их сразу отсечь от процесса разработки.
Andrii
а по какой, собственно, причине их в Го нет? Просто еще не запилили или есть другие причины?
Cat
а по какой, собственно, причине их в Го нет? Просто еще не запилили или есть другие причины?
Потому что очень сложно для программистов, в гугле решили что не надо
саша
Как это решит?
Очень просто, дженерик обеспечил бы здесь типобезопасность, ибо тогда мы бы не смогли попробовать распарсить во что-то, что не удовлетворяет интерфейсу UnmarshalJSON. А так из сигнатуры непонятно что за v я могу туда передать и как оно его из какого формата будет парсить.
Alexander
а по какой, собственно, причине их в Го нет? Просто еще не запилили или есть другие причины?
самое смешное что есть. просто создатели языка решили что прикладным разработчикам не надо
саша
Эмм. Что. Тогда на вход интерфейс надо принимать.
Зачем вообще на вход вообще что-то принимать? Почему нельзя сделать по человечески: func (ep *BaseEndpoint) ParseBody<T>(r *rest.Request) (T, error) where T: UnmarshalJSON ?
Pawel
а по какой, собственно, причине их в Го нет? Просто еще не запилили или есть другие причины?
их нормально невозможно реализовать чтобы не пострадала скорость компиляции и не выросла когнитивная нагрузка дженерики нужны не настолько чтобы этим жертвовать все действительно нужные обощённые структуры данных встроены в Го. Остальное нужно настолько редко, что ни каких проблем самому реализовать. Но прокрастинирующих монадистов это бесит - для них если нет боли, то это не настоящее программирование
саша
Парсинг и дженерики - это всегда мимо. При парсинге нужно смотреть что внутри структуры. Дженерики этого не дадут.
Код парсинга может быть спокойно сгенерирован во время компиляции при помощи, например, макросов.
Ingitore
Привет! Я рекрутер, админы, по правилам группы здесь можно постить вакансии? спасибо
Chebyrash
Роб Пайк не осилил запилить дженерики и сказал нинужно
Ну он их запилил же для коллекций в языке
саша
И зачем, что это дает?
Типобезопасность, самодокументироемость, удобство использования.
Алексей
Типобезопасность, самодокументироемость, удобство использования.
это слишком сложно для Go программистов походу
Pawel
роб пайк тупой, это известный факт. куда ему до Alexander Kramov по уму
Alexander
Привет! Я рекрутер, админы, по правилам группы здесь можно постить вакансии? спасибо
@twentydraft <- спросите в личке, например. так-то отдельный канал/чат есть, но бывает и тут постят
Vladislav
Типобезопасность, самодокументироемость, удобство использования.
В каком месте то безопасность относительно передачи аргумента?
Алексей
роб пайк тупой, это известный факт. куда ему до Alexander Kramov по уму
действительно роб пайк не может ошибаться, если он сказал, что дженерики не нужны, значит они не нужны
Slava
Привет! Я рекрутер, админы, по правилам группы здесь можно постить вакансии? спасибо
По правилам запрета нет ;) главное чтобы вакансия профильная была и с вилкой
Je
роб пайк тупой, это известный факт. куда ему до Alexander Kramov по уму
роб пайк слишком консервативен и не считает, что прикладные программисты со времен паскаля двинулись в требованиях к ЯП
Vladislav
А в каком языке нормально реализованы дженерики то?
Pawel
Ну он их запилил же для коллекций в языке
ну то есть между понятиями "дженерики" и встроенными обощёнными структурами данных вы разницы не видете. Ок, так и запишем
саша
В каком месте то безопасность относительно передачи аргумента?
В том, что если ты попытаешься распарсить что-то, для чего не реализован парсинг жсона, то программа не скомпилируется, вместо того, чтобы в лучше случае упасть во время тестов.
саша
Kotlin, Swift
саша
Тебе интерфейсы нужны.
Это тоже не сработает, ибо стандартный анмаршалинг жсона работает на тегах структур и магии рефлексии, что тоже плохо.
Pawel
показать код, который на C# лучше - это мы не можем конечно. Главное - это своё веское слово вставить. Вдруг найдётся дурак который поверит
саша
И как ты без макросов это обойдешь?
По хорошему никак. Но в адекватной системе макросов тоже ничего плохого нет.
Vladislav
По хорошему никак. Но в адекватной системе макросов тоже ничего плохого нет.
Ну так с макросами и без дженериков то тоже работает.
саша
Не совсем, функция не может вернуть T
саша
И поэтому переменную нужно объявлять предварительно и передавать указатель на неё в качестве аргумента
Vladislav
Да какая разница. Что внутрь t положить, что вернуть?
Алексей
ну то есть между понятиями "дженерики" и встроенными обощёнными структурами данных вы разницы не видете. Ок, так и запишем
На самом деле разницы особой не должно быть. Но так как великий роб пайк настолько великий, что не осилил запилить нормальные дженерики, то встроенные обобщённые типы - это магические сущности.
Vladislav
И поэтому переменную нужно объявлять предварительно и передавать указатель на неё в качестве аргумента
И что в этом такого. Учитывая что обычная структура без указателя интерфею не соответсвует.
Pawel
На самом деле разницы особой не должно быть. Но так как великий роб пайк настолько великий, что не осилил запилить нормальные дженерики, то встроенные обобщённые типы - это магические сущности.
я правильно понял. что ни какого полезного кода с обощёнными структурами данных,которых нет в Го, ты показать не можешь, но тем не менее считаешь что джененрики в Го всё равно нужны?
саша
func (t *TaskManager) Command(task *models.Task, account *models.Account, params interface{}) error Или вот, попробуйте, называется, догадаться что там за параметры могут быть в params
саша
О. Это API дурацкий.
Нет, это отсутствие типов сумм.
Vladislav
Начиная от пакета models. Заканчивая использованием не интрефейсов.
Je
Начиная от пакета models. Заканчивая использованием не интрефейсов.
С интерфейсами код не перестает дублироваться, внезапно
« Rev
@gogolang   1248
Fwd »