Daniil
)
Vladimir
те же йайтса, тока в профиль
Daniil
помоему самая большая проблема только в том что ошибки должны быть объявлены (пускай даже повторно) в той библиотеке, которую ты используешь. А так же к каждому из методов должно быть описание какие ошибки он возвращает.
Про его предложение насчет давайте завернем все ошибки в супер-штуку, которая умеет печатать стэк-трейсы. Ну вроде удобно, но граздо убдобнее было бы знать какие ошибки может вернуть ф-я, а не открывать для себя эту фичу после изучения стэктрейса.
Daniel
и стектрейс было бы удобно иметь сразу вместе с ошибкой
Daniel
и не смешивать ошибки и возврат
Daniil
если это стектрейс до ошибки в твоем коде - да. Если нет - уже не столь важно.
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
Чего-то читал сейчас про kubernetes (он же k8s) и прикольное название придумалось для чего-то, типа honeypot-ов или race checker-ов : b8s (а произносится baits)
Мерль
Господа, а что вы думаете за плагины в Go?
Constantine️
что за плагины?
Lev
... через какой-нть RPC
Vladimir
Господа, а что вы думаете за плагины в Go?
Что-что? "думаете за плагины"?
Oleg
Господа, а что вы думаете за плагины в Go?
Знаю что Хашимото сделал вот это - https://github.com/hashicorp/go-plugin на основе rpc, с подменой соединения.
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
https://github.com/go-interpreter/proposal/issues/1
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
Наврал про 1.8 - это просто proposal
Мерль
https://www.youtube.com/watch?v=yeetIgNeIkc&utm_source=golangweekly&utm_medium=email
A.
Тут на тостере парень про гоу приспрашивается https://toster.ru/q/354220
ros
манагер тостера?
ros
или как там нонче SEO
A.
Ам?
ros
как объяснить попытки привлечь народ в тостер?
давайте здесь обсудим
Sergey
Chief
A.
как объяснить попытки привлечь народ в тостер?
давайте здесь обсудим
Ты спайсами уделанный чтоль7
A.
Ты в интернете
A.
Это ссылкой называется
Vladimir
Тут на тостере парень про гоу приспрашивается https://toster.ru/q/354220
Зачем вообще следить за каким-то там аналагом SO от петухабра, если есть SO?
A.
Ребят вы с утра не принимаете на грудь? Мне чет за вас беспокойно стало.
Sergey
Ребят вы с утра не принимаете на грудь? Мне чет за вас беспокойно стало.
Все пидарасы а ты д'артаньян?
A.
оО
Sergey
Который вопрос на тостера задаем
A.
Короче. Я не понимаю что вы тут за хуйню пишете. Но ещё одна неадекватная реакция на ссылку - буду раздавать баны всем поклонникам Александра Дюмы и его творчества. По ссылке вопрос про гоу, этот чат про гоу. Зачем я должен спамить про этот чат совсем не понял.
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
Чувак спросил про go?-про go. Чят про go?-про go. Почему б не пообсуждать вопрос. Согласен с @shpaker
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
Тут на тостере парень про гоу приспрашивается https://toster.ru/q/354220
На мой взгляд, если все горутины делают одно и то же, типа распиливают большую пачку не связанных данных, в которых не важен порядок - то один общий буфферезированный канал - самое оно
A.
Чувак спросил про go?-про go. Чят про go?-про go. Почему б не пообсуждать вопрос. Согласен с @shpaker
Это они почему злые - потому что у них порнохаб отобрали.
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
Это они почему злые - потому что у них порнохаб отобрали.
Кто по утрам на порнхаб ходит? - это разочарование настигнет попозжее
ros
> При этом данных много, пишутся быстро
Больше подходит общение через диспетчер очередей чтоб сдерживать напор тех кто добывает данные.
Медленная обработка в основной рутине либо залочит по записи всех кто туда пишет, либо израсходует всю оперативку, в которую будут пихаться все задания.
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
> При этом данных много, пишутся быстро
Больше подходит общение через диспетчер очередей чтоб сдерживать напор тех кто добывает данные.
Медленная обработка в основной рутине либо залочит по записи всех кто туда пишет, либо израсходует всю оперативку, в которую будут пихаться все задания.
Но если он данные не может так быстро обработать - зачем их так быстро писать? Надо тогда эти данные получать - куда-то времено сохранять, а потом подсасывать и обрабатывать с той скоростью, которая возможна
ros
так он заранее не угадать в каком объеме будут результаты
можно просто поставить сервак на колени
в основной рутине раздал пачку заданий в диспетчер
обработал первый результат пихнул ещё одно задание
это позволит синхронизировать скорость сбора данных и обработки
потом уже можно гибко путем наращивания числа воркеров нагружать сервак до приемлемой скорости, не боясь завалить
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
так он заранее не угадать в каком объеме будут результаты
можно просто поставить сервак на колени
в основной рутине раздал пачку заданий в диспетчер
обработал первый результат пихнул ещё одно задание
это позволит синхронизировать скорость сбора данных и обработки
потом уже можно гибко путем наращивания числа воркеров нагружать сервак до приемлемой скорости, не боясь завалить
Просто это зависит от планируемой нагрузки. Можно себе позволить буф канал который отожрет оперативку. А если данных реально так много, что это не решение - ну то да, можно и диспетчера. А если данных все время так много - то лучше временное хранение прикрутить
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
так он заранее не угадать в каком объеме будут результаты
можно просто поставить сервак на колени
в основной рутине раздал пачку заданий в диспетчер
обработал первый результат пихнул ещё одно задание
это позволит синхронизировать скорость сбора данных и обработки
потом уже можно гибко путем наращивания числа воркеров нагружать сервак до приемлемой скорости, не боясь завалить
Просто я не знаю диспетчеров готовых в go, по своей неопытности, и исходя из того что его писать самому придеться, хотелось бы избежать кода, который можно избежать
ros
не нужно ничего писать самому RabbitMQ + https://github.com/streadway/amqp
Oleh
редис так же можноюзать
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
не нужно ничего писать самому RabbitMQ + https://github.com/streadway/amqp
Я просто думал что речь идет про одно го приложение а не про архитектуру распределенного приложения в общем.
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
Ну если брать сторонние, рядом стоящие, я б тоже редис взял. Рэбит - слишком жирно если не планировать все вокруг рэбита строить
ros
у мну просто несколько кластеров кроля поэтому больше с приходится стыковаться
ros
редиска тоже вариант не отрицаю
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
редиска тоже вариант не отрицаю
Ну а если оставаться в рамках отдельно взятого го приложения - то просто буф канал. Ну и если оперативки мало - какое-то промежуточное хранение на диск
ros
один буф.канал будет эффективней множества
ктому же как-то из этого множества нужно будет читать
это либо цикл по мапу либо огроменный select
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
один буф.канал будет эффективней множества
ктому же как-то из этого множества нужно будет читать
это либо цикл по мапу либо огроменный select
И я про то же. А если разные горутины производят данные в которых порядок важен, то надо много каналов и лист
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
Но это как-то криво данные в которых порядок важен в разных горутинах пилить, если обработка тормозит
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
https://toster.ru/q/354220
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
Он сам разобрался в себе 😂😂😂
ros
про мап он видать не слышал
ros
срез?
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
срез?
Ну да, slice. Типа пихаешь в него каналы и потом берёшь канал, забираешь все, потом следующий
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
Никак не привыкну к slice вместо list после питона. Slice в мозгу укоренился как кусок листа или чего-то подобного
ros
по мопу имхо проще
прочитал удалил ключ (если нет множественного использования каналов)
по срезу удобно идти с головы, но выкинуть значение из середины напряжно
𝕲𝖎𝖗𝖆𝖋𝖋𝖊
Ну эти свистопляска с множеством каналов имют хоть какой-то смысл если надо упорядоченные данные. А если данные упорядоченные, то и не надо id из середины удалять
ros
вобщем, мы толком не знаем всей задачи
потому вариантов тьма
Leonid Kalneus
http://pbs.twimg.com/media/CnL0OF4UkAAPWTq.jpg
Slava
чтобы удалять из середины, можно взять двусвязанный список
Slava
кто на DotGo будет?
Daniil
А тут кстати много людей на работе используют го как главный язык программирования(если ваша работа вообще связана с программированием)?
ros
я с perl постепенно на go переписываю
Daniel
На этот вопрос ответ строго "не знаю"
ros
голосовая связь, чаты, удаленный доступ
ros
на go например, сервак проксирующий через себя трафик удаленного доступа. изначально был на делфе написан.
после переписывания на go ресурсов почти не ест
благодаря этому ушли на более дешевые VDS