Питон, как мне кажется, на базовом уровне проще, чем Паскаль

Наглядный пример этой "простоты" (за которую хочестя убить) 1) if condition: try: cursor = db.cursor() updateData(cursor) finally: cursor.close() 2) if condition: with db.cursor() as cursor: updateData(cursor) Можно написать и так и так, и никто вас не остановит до тех пор, покуда не будет condition == True. Кто-нибудь скажет нубу, что для курсора не определены методы __enter__ и __exit__? - интерпретатор во время выполнения и только тогда, когда condition будет True! И скажет пользователю программы, отказавшись сохранить его данные.

реально они не нужны, пока не начнеш коллекции писать

Или версионированные структуры

зачем? есть один метод принимающий интерфейс, а дальше рефлект или кодеген) и вообще если проблема исключительно в дублировании кода, то неужели ее нужно перекладывать на ЯП тем самым пздц как усложняя его... почему просто плагин для IDE нe сделать. который их автоматом нагенерирует :)

А потом генерировать код , который использует сгенерированный код, и так до самого main

Нубских вопросов накопилось. Вот посмотрел доклад, вот этот https://youtu.be/me5iyiheOC8 и возникли вопросы, есть net/http там разве не реализовано грэйсфул шутдаун?

Где то смотрел статейку как сделать грейсфул шатдаун

Погугли найдешь

Нубских вопросов накопилось. Вот посмотрел доклад, вот этот https://youtu.be/me5iyiheOC8 и возникли вопросы, есть net/http там разве не реализовано грэйсфул шутдаун?

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

Спасибо.

ответ в одной гифке: https://qph.ec.quoracdn.net/main-qimg-dd2dc3bc72b058b85774ee804a521165

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

и это самое мерзкое, что есть в c++

там много гадости, но эта - самая самая

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

А что такого мерзкого в перегрузке операторов?

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

А что такого мерзкого в перегрузке операторов?

я так понимаю неявность, что ты никогда не знаешь что скрывается за простым + пока в код не посмотришь

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

я так понимаю неявность, что ты никогда не знаешь что скрывается за простым + пока в код не посмотришь

Есть такое, но не так уж и страшно. Просто не надо делать нелогичные вещи. Так то сложение/умножение матриц и векторов или, например, комплексных чисел, очень неплохо делать перегрузкой операторов.

векторное или скалярное произведение v1*v2?

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

Есть такое, но не так уж и страшно. Просто не надо делать нелогичные вещи. Так то сложение/умножение матриц и векторов или, например, комплексных чисел, очень неплохо делать перегрузкой операторов.

++++

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

Это пока у тебя нет сложных конструкций Иначе начинается адок

векторное или скалярное произведение v1*v2?

Очевидно, зависит от типов переменных.

Есть такое, но не так уж и страшно. Просто не надо делать нелогичные вещи. Так то сложение/умножение матриц и векторов или, например, комплексных чисел, очень неплохо делать перегрузкой операторов.

ну вот я недавно проект на 50К строк портировал с с++ на go. чуть с ума не сошел

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

Другой момент если у тебя перегружен оператор для двух разных типов, вот тогда начинается АДЪ

Это пока у тебя нет сложных конструкций Иначе начинается адок

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

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

Это плохо только для cpp В том же русте и хаскеле тебе и типы проверят, и не дадут строку с флоатом сложить

Это проблема самой возможности перегрузки функций с разными параметрами (которой в Го нет). Хотя перегрузка именно операторов немного путаницы тоже добавляет, конечно.

int min(int a, int b) float min(float a, float b)

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

А начинается ад когда у тебя определение функции занимает пару экранов вместо строки(это у меня реальный кейс на го был)

И потом ты пытаешься найти ошибку в математике

в Го же вполне возможно реализовать Stack & Queue?

И тогда начинаешь жалеть что написал не на cpp

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

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

через interface{}? как any в typescript

А начинается ад когда у тебя определение функции занимает пару экранов вместо строки(это у меня реальный кейс на го был)

не вижу никакого ада тут.

в Го же вполне возможно реализовать Stack & Queue?

Либо пиши велосипед, либо через пустые интерфейсы Стек хорошо через слайс, очередь — в зависимости от конкретного случая

через interface{}? как any в typescript

типа type A interface{}?

Либо пиши велосипед, либо через пустые интерфейсы Стек хорошо через слайс, очередь — в зависимости от конкретного случая

сижу алгоритмы учу, вот и думаю как сделать

при чем тут интерфейс?

типа type A interface{}?

func (s * Stack) Push(item interface{}) {}

Так и думал

Спасибо

не надо так делать

совсем не надо

Ну можно не через интерфейс

типа Stack с конкретным типом

не вижу никакого ада тут.

Ну это потому что не нужно было видимо ( Я имел счастье писать более менее сложную математику и cpp, питончеге и go Из этой тройки go хуже всего подходит для такой эквилибристики

По крайней мере по моему опыту

Ох уж эти гоферы. Перегрузка видете ли усложняет, а передавать в параметры функций интерфейсы - это норм!..

не надо так делать

а как надо?

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

Ох уж эти гоферы. Перегрузка видете ли усложняет, а передавать в параметры функций интерфейсы - это норм!..

не норм, конечно

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

Ну это потому что не нужно было видимо ( Я имел счастье писать более менее сложную математику и cpp, питончеге и go Из этой тройки go хуже всего подходит для такой эквилибристики

Это пожалуй единственный случай когда golang вынуждает писать совершенно неподдерживаемый код

вот например популярная вроде либа https://godoc.org/github.com/oleiade/lane через interface сделана

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

не хочется, а надо.

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

Тут тебе придется дублировать Привыкай

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

На самом деле чтобы именно изучать алгоритмы, то писать свои велосипеды — это даже правильно и полезно, имхо

Это пожалуй единственный случай когда golang вынуждает писать совершенно неподдерживаемый код

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

вот захочешь ты себе какой-нибудь mq кеш, который за 5 мин нормально наверно не напишешь, не будешь же ты под каждый тип сидеть дублировать. Либо придется через интерфейсы, либо какую-то обертку чтобы он внутри хранил только какие-то id объектов, и говорил тебе когда удалять их, а ты ему говорил когда добавил id и когда считал id, а сам объекты по id в мэпе хранить. Тот еще изврат

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

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

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

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

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

Неа, как раз big int — это не слишком страшно, в тех же пакетах криптографиии в стандартной библиотеке полюбопытствуйте, там по божески Самое страшное начинается когда нужна линейная алгебра сложнее "перемножить три матрицы"

ну там же и сама математика не простая

синтаксического сахара не хватает, я так понял

А как разряженные матрицы хранятся ? дикт из позиции и значения ?

встроенного типа для них нет

блин, походу реально сделать кеш, который хранит только айдишники это неплохое решение, типа Push(id) Touch(id) OnRemove(func(id)). А внутри уже любой алгоритм навороченный

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

1. Мало пакетов для математики 2. Нет перегрузки операторов, очень громоздкие нечитаемые выражения 3. Большую часть проверок на размерность и прочее приходится делать в рантайме Скорость как правило не важна, на самом деле

ну там же и сама математика не простая

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

А как разряженные матрицы хранятся ? дикт из позиции и значения ?

Лучше сделай сам, хотя я видел вроде готовые имплементации для float64

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

Для разреженных матриц лучше из numpy спереть, в доках описаны несколько форматов и кейсы применения, там под конкретный случай лучше выбирать

https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.csr_matrix.html

что еще для ml юзают помимо python / R ? scala ?

только не надо что для ml пофиг какой язык, важнее модель )

что еще для ml юзают помимо python / R ? scala ?

Если только начинаешь, то я бы взял питон (с R работал мало) так как большая часть курсов и книг заточена под него, + масса хороших библиотек и документации, + гигантское сообщество А потом всё равно выберешь что нужно