Алексей
Причём у го есть также критичные киллерфичи, которых не найдёшь в других языках, и которые как раз заставляют не сбрасывать этот язык полностью со счетов. Если бы их не было, то я даже не посмотрел бы в сторону этого языка.
invariance
Я пропустил. Скинь еще раз
https://github.com/MinterTeam/minter-go-node/search?q=if+err+%21%3D+nil&unscoped_q=if+err+%21%3D+nil
Sergey
https://github.com/MinterTeam/minter-go-node/search?q=if+err+%21%3D+nil&unscoped_q=if+err+%21%3D+nil
Я не могу уловить нить беседы. Что тут нужно увидеть?
Alexey
https://github.com/MinterTeam/minter-go-node/search?q=if+err+%21%3D+nil&unscoped_q=if+err+%21%3D+nil
эээ... там везде if err != nil же
invariance
слабо походит на постоянный копипаст
invariance
invariance
типа
invariance
52 результата
invariance
а не 52 files
Алексей
первый попавшийся файл открыл:
https://github.com/MinterTeam/minter-go-node/blob/master/genesis/genesis.go
Алексей
там одна небольшая функция
Алексей
угадайте что и сколько раз я там увидел?
Илья
обработка ошибок и правда не сильная сторона языка, жить с ней можно, но можно и лучше
invariance
ладно, я был неправ
Алексей
Причём кстати пропозал в go вроде бы внесли даже по поводу решения этой проблемы
Алексей
так что надежда есть
Илья
https://github.com/golang/go/issues/19412
Alexey
обработка ошибок и правда не сильная сторона языка, жить с ней можно, но можно и лучше
ты просил пример псевдокода. ты его видел?
Илья
ты просил пример псевдокода. ты его видел?
да, я правда все равно вижу наследование, а не генерики, but it's just me, выше я тебе ответил как бы я то сделал, и, не поверишь, делал даже более общее решение, когда 1 тип клиент, а есть только underliyng транспорт, и в нем уже реализация метрик/инициализации и прочего
Andrei 🦉
ты просил пример псевдокода. ты его видел?
этот спор идет уже много лет и с другой стороны всегда только один аргумент - «не нужно», как это до недавнего времени было с версионированием и пакетным менеджером, заходи еще года через 3, может что нибудь и надумают
Илья
по певдокоду я понял, что ты за имплисит помойкокод, спасибо, стало понятнее
Алексей
этот спор идет уже много лет и с другой стороны всегда только один аргумент - «не нужно», как это до недавнего времени было с версионированием и пакетным менеджером, заходи еще года через 3, может что нибудь и надумают
Я уверен, что многие из тех, кто говорит "не нужно" будут юзать дженерики по полной, когда (и если) их таки запилят в го.
Anonymous
Всем привет, подскажите, пожалуйста
из своего сервиса делаю запрос к другому
res, err := http.DefaultClient.Do(req)
спецаильно указаываю неверный порт
приходит err но при этом не приходит ответ res.StatusCode (500)
как корректнее обрабатывать подобную ситуацию?
я планировал по res.StatusCode решать что делать дальше
но если адрес неверный то просто приходит err вида connection refused
Andrei 🦉
Я уверен, что многие из тех, кто говорит "не нужно" будут юзать дженерики по полной, когда (и если) их таки запилят в го.
ну да, они даже не вспомнят, как сам Роб Пайк кричал, что дженерики не нужны
Aleksandr
Aleksandr
раз порт неверный
Алексей
ну да, они даже не вспомнят, как сам Роб Пайк кричал, что дженерики не нужны
Про то что кричал Роб Пайк по поводу дженериков я честно говоря не знаю, не следил. Но я смотрел его презенташку по лексическому анализу и понял, что он любит писать код, много кода, даже там, где можно написать мало кода или вообще его сгенерировать по 20-30 строкам с регэкспами.
Dmitry
ну да, они даже не вспомнят, как сам Роб Пайк кричал, что дженерики не нужны
Тащемто его основной посыл был в том что генерики или 1) увеличивают размер кода 2) размер работы компилятора 3) размер работы программиста
Маjко
Тащемто его основной посыл был в том что генерики или 1) увеличивают размер кода 2) размер работы компилятора 3) размер работы программиста
Я вот прямо сейчас убеждаюсь что лучше уж генерики, чем кодогенерация.
Генерю тесты, жду компиляции по 10 минут
Dmitry
Версия Go?
Маjко
Кто сказал что Go?
Илья
ну да, они даже не вспомнят, как сам Роб Пайк кричал, что дженерики не нужны
https://golang.org/doc/faq#generics
Алексей
Тащемто его основной посыл был в том что генерики или 1) увеличивают размер кода 2) размер работы компилятора 3) размер работы программиста
Ну так и есть в принципе. Но увы у дженериков как и у многих других вещей нет идеальной имплементации.
Алексей
Тащемто его основной посыл был в том что генерики или 1) увеличивают размер кода 2) размер работы компилятора 3) размер работы программиста
Тоже самое можно сказать к примеру про управление памятью.
Илья
Я вот прямо сейчас убеждаюсь что лучше уж генерики, чем кодогенерация.
Генерю тесты, жду компиляции по 10 минут
вот поэтому, видимо, го компилируется гораздо быстрее
Dmitry
Ну так и есть в принципе. Но увы у дженериков как и у многих других вещей нет идеальной имплементации.
Вообще основная проблема была именно в скорости компиляции - гуглу нужны были быстрые билды для своих сервисов.
Daniel
Я вот прямо сейчас убеждаюсь что лучше уж генерики, чем кодогенерация.
Генерю тесты, жду компиляции по 10 минут
так а чем генерики отличаются от кодогенерации?
Dmitry
Смотря сколько нагенерено...)
Смотрее смотря сколько перегенерено - начиная с 1.10 там система кеширования довольно умная
Kirill
сложно, но можно
Алексей
Вообще основная проблема была именно в скорости компиляции - гуглу нужны были быстрые билды для своих сервисов.
Ну вообще можно сделать как в джаве и тогда скорость компиляции будет на высоте.
Dmitry
так а чем генерики отличаются от кодогенерации?
А вот это я могу ответить - в текущей модели Go нельзя сделать аналог Vector<List<Vector>>
Маjко
так а чем генерики отличаются от кодогенерации?
Тем что часть языка, например, и семантическая вещь, нежели генерация на основе токенов (синтаксиса)
Daniel
на скорость компиляции это как повлияет?
Dmitry
Ну вообще можно сделать как в джаве и тогда скорость компиляции будет на высоте.
Потеря типа на этапе компиялции? Не работает в модели памяти Go - нет норм иерархии типов, а интерфейсы являются типами сами по себе.
Dmitry
Было кстати обсуждение
Алексей
на скорость компиляции это как повлияет?
Вообще никак не повлиют. Потому что дженерики не нужны и их никто использовать не будет.
Dmitry
на скорость компиляции это как повлияет?
Я имел введу что просто нельзя - это вызовет ор на циклический импорт
Daniel
Вообще никак не повлиют. Потому что дженерики не нужны и их никто использовать не будет.
последнее предупреждение
Dmitry
Вообще никак не повлиют. Потому что дженерики не нужны и их никто использовать не будет.
Спорное утверждение 2 - судя по недавнему общению с Фитзпатриком - генерики хочет сам гугл.
Алексей
Потеря типа на этапе компиялции? Не работает в модели памяти Go - нет норм иерархии типов, а интерфейсы являются типами сами по себе.
А к interface{} и обратно вообще чтоли никак нельзя неявно кастить?
Маjко
на скорость компиляции это как повлияет?
Раскрытие генериков проще кэшировать, например.
Ну а вообще, спич скорее о том что это не взаимозаменяющие друг друга инструменты.
Кодгеном можно сделать то, что нельзя дженериками
Дженериками можно удобнее, нагляднее и типобезопасно можно сделать часть того что можно делать кодогенерацией
Olzhas
Olzhas
Я видел какую-то библиотеку от гугла на пхп
Dmitry
А к interface{} и обратно вообще чтоли никак нельзя неявно кастить?
Можно - но нет инфы про конретные контракты, а в отличии от джавы не у всех типов виртуальная таблица
Olzhas
Я видел какую-то библиотеку от гугла на пхп
Там эти поехавшие буквально все оьмазали геттерами и сеттерами
Dmitry
Вообще никак не повлиют. Потому что дженерики не нужны и их никто использовать не будет.
вторая проблема это implitic boxing - в отличии от джавы где только примитивы таким страдают (Integer и int) в Go придется вообще все - потеря перфоманса. Плюс проблемы для escape analysis
Aleksandr
Там эти поехавшие буквально все оьмазали геттерами и сеттерами
потому что они генерят либы на разных языках на базе схемы
Aleksandr
по крайней мере так сдк у них сделано
Dmitry
Я спрашивал почему не выбрали путь D - там быстрые билды и мощная система шаблонов, но Фитзпатрик не знал про это. Говорит то, что дизайнов генериков было очень много - ни один из них не устроил тогда.
Крылатый
Dmitry
Но это так...
Dmitry
Смотря на тот же Rust - я пытаюсь понять где лежит баланс между бедностью языка и потерей ясности для разработчика.
Алексей
DI нормальный, сложный, не сделать иначе
DI тоже не нужен, это всё джавистская ересь, как и геттеры с сеттерами
Dmitry
DI тоже не нужен, это всё джавистская ересь, как и геттеры с сеттерами
Мне кажется что это передергивание уже...
Крылатый
Не, нафига дженерики и шаблоны? Оно ж только усложняет. Потом будут тексты ошыбок как в плюсах на пару километров.
Алексей
да я же саркастично и утрированно отвечал
Алексей
Смотря на тот же Rust - я пытаюсь понять где лежит баланс между бедностью языка и потерей ясности для разработчика.
а вот это вопрос на миллиард долларов
Kirill
А вот это я могу ответить - в текущей модели Go нельзя сделать аналог Vector<List<Vector>>
зачем это в реальном коде?
Dmitry
Не, нафига дженерики и шаблоны? Оно ж только усложняет. Потом будут тексты ошыбок как в плюсах на пару километров.
Никто не заставляет делать дженерики тьюринг полными
Крылатый
Никто не заставляет делать дженерики тьюринг полными
Совсем не обязательно. Но даже обычные навороты из 100500 уровней это кошмар.
Dmitry
зачем это в реальном коде?
Это гипотетический пример когда обертка 1 является оберткой 2 для обертки 1