Спасибо. Да, я на самом деле я понимаю в чем разница между наследованием и композицией. Просто хотел узнать best practices in go

https://www.youtube.com/watch?v=zzAdEt3xZ1M

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

потому что iPhone если я не ошибаюсь был дороже, и ничем не лучше

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

пример реализации микросервиса

А чо там в примере писать? Смотри, тебе надо abc, bcd, cde обрабатывать разными "плагинами". И у тебя УЖЕ есть сервер с https, вероятно, nginx. Ты делаешь 3 приложения abc, bcd, cde, каждое слушает свой порт. Нжынксом настраиваешь locatoin'ы с прокси эндпоинтов на нужные порты

Это и будет "микросервисная архитектура")))

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

ценность Го в том, что он скрывает event loop от программиста. В то время как большинство хайповых технологий его навязывают (async/await, tEA, redux, промисы, callbacks, frp, ). Людям надоело писать конечные автоматы, хочется простого синхронного кода

у меня была идея использовать nginx, написать модуль - чтобы по своему протоколу общался и потом возвращал результат. Так вот никак не подберусь к nginx

у меня была идея использовать nginx, написать модуль - чтобы по своему протоколу общался и потом возвращал результат. Так вот никак не подберусь к nginx

А зачем тебе модуль nginx?

зачем модуль? в nginx все есть уже ровно для задачи фронта к микросервисам

ценность Го в том, что он скрывает event loop от программиста. В то время как большинство хайповых технологий его навязывают (async/await, tEA, redux, промисы, callbacks, frp, ). Людям надоело писать конечные автоматы, хочется простого синхронного кода

Мне очень нравится читабельность кода на го

Код, который действительно очень просто читать.

зачем модуль? в nginx все есть уже ровно для задачи фронта к микросервисам

Получить через nginx запрос в json -> завернуть в свой протокол - передать локально по сокету сервису, подождать результат - развернуть протокол в json ответ и отдать клиенту

Например? Мне вот что-то а сетевое взаимодействие в го оч нравится (лет 7 писал телеком на сях, есть с чем сравнить)

например, хочу я recvmmsg/sendmmsg, ну или вот splice

а где не странно?

а еще хочу я произвольные fd добавлять во внутренний поллер, который в internal

ну вот json-завернуть и json-развернуть это уже не совсем задача фронта, имхо... оно тебе фронт по производительности в гумно просадит...

ну и, собственно, изобретать свой протокол - тоже "так себе" задача, которую еще, пожалуй, обосновать стоит...

например, хочу я recvmmsg/sendmmsg, ну или вот splice

зачем?!

у тебя есть json, xml - искаропки, protobuf - с полпинка...

ценность Го в том, что он скрывает event loop от программиста. В то время как большинство хайповых технологий его навязывают (async/await, tEA, redux, промисы, callbacks, frp, ). Людям надоело писать конечные автоматы, хочется простого синхронного кода

хоть я и одепт концепции неявного event loop, но async/await все-таки куда более мощная концепция и куда более эффективная с точки зрения потребления ресурсов.

а еще хочу я произвольные fd добавлять во внутренний поллер, который в internal

OMG

зачем?!

пакетики отправлять/получать быстро без лишних контекст-свитчей.

сейчас для udp надо по сисколлу на пакет

пакетики отправлять/получать быстро без лишних контекст-свитчей.

ну вот это не на Go, вероятно, делать надо, если реально прирост производительности нужен...

*mmsg амортизирует стоимость

ну вот это не на Go, вероятно, делать надо, если реально прирост производительности нужен...

ну почему же?

оно у тебя один хрен в ядро упрется же...

оно у тебя один хрен в ядро упрется же...

с чего вдруг такой тезис и без профайлинга? )

ну и, собственно, изобретать свой протокол - тоже "так себе" задача, которую еще, пожалуй, обосновать стоит...

уже реализовал, один класс. передаешь буффер и пишеш любые структурированные данные, и потом их читаешь. разные типы данных. без приготоввлений типа protobuf - просто пишеш и читаешь потом. Ограничение на пакеты 128кб, чтобы не садить производительность

ну почему же?

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

сейчас для udp надо по сисколлу на пакет

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

В конечном итоге все делает либа на сях

Тоже думаю, что в итоге придётся пользоваться библиотекой на сях. А как там по скорости?

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

я умею в kernel bypass и даже его делал на go :) но давайте смотреть правде в глаза: сисколл стоит 42ns без включенного аудита, ~73ns - со включенным. если у нас dns-сервер, то это больно.

с чего вдруг такой тезис и без профайлинга? )

ну, тут, какбэ, два забавных наблюдения: 1. оно не будет быстрее, чем ему позволит его нижележащая платформа 2. оно не будет быстрее, чем ему позволит сборщик мусора например Как правило, заради производительности, в первую очередь, отказываются именно от GC...

уже реализовал, один класс. передаешь буффер и пишеш любые структурированные данные, и потом их читаешь. разные типы данных. без приготоввлений типа protobuf - просто пишеш и читаешь потом. Ограничение на пакеты 128кб, чтобы не садить производительность

ну а чем тебя, в таком случае, nginx не устраивает. Вот он какой набор байт примет, такой набор байт и отдаст нижележащему сервису... А вот сериализовать/десериализовать - оно на сервисе, например, может

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

на самом деле вполне получится. надо лишь интерфейс, который оперирует массивом из []byte, а вот эти read/write/send - это лишь частный случай, где массив из одного элемента )

я умею в kernel bypass и даже его делал на go :) но давайте смотреть правде в глаза: сисколл стоит 42ns без включенного аудита, ~73ns - со включенным. если у нас dns-сервер, то это больно.

ну, т.е. на го сильно быстро, один хрен, не получится? Вы про это?

ну а чем тебя, в таком случае, nginx не устраивает. Вот он какой набор байт примет, такой набор байт и отдаст нижележащему сервису... А вот сериализовать/десериализовать - оно на сервисе, например, может

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

я умею в kernel bypass и даже его делал на go :) но давайте смотреть правде в глаза: сисколл стоит 42ns без включенного аудита, ~73ns - со включенным. если у нас dns-сервер, то это больно.

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

Тоже думаю, что в итоге придётся пользоваться библиотекой на сях. А как там по скорости?

Возьмем тот же TensorFlow от гугла. Сама либа написана на C++, хотя используется чаще всего на Python. В том же пайтоне или go задается только логика вычислений, а сами вычисления производит уже сама либа на проце или видеокарте. По этому выбор языка здесь не критичен, он не должен быть обязательно быстрым.

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

смотри, получится у тебя примерно так: Приложуха abc висит на локалхосте на порту 5555 bcd - там же на 5556 cde - ну, там список продолжи. В конфиге нджинкса пишешь: location /abc { proxy_pass localhost:5555; } И так повторяешь для каждого эндпоинта с нужными портами.

смотри, получится у тебя примерно так: Приложуха abc висит на локалхосте на порту 5555 bcd - там же на 5556 cde - ну, там список продолжи. В конфиге нджинкса пишешь: location /abc { proxy_pass localhost:5555; } И так повторяешь для каждого эндпоинта с нужными портами.

спасибо, попробую. не особо хотелось заморачиваться с tls и писать свой https сервер, когда уже есть. nginx. Спасибо. за совет

ну, т.е. на го сильно быстро, один хрен, не получится? Вы про это?

получится. просто речь о том, что придется кучу всего делать самому. это печаль =(

ну можно же один раз сделать и заопенсорсить!

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

2-3 млн в секунду )

3 миллиона сисколов по 73ns занимают примерно 0.22 секунды.

Чего там, лучше уж тогда напечатать ASIC под свои нужды ?

хоть я и одепт концепции неявного event loop, но async/await все-таки куда более мощная концепция и куда более эффективная с точки зрения потребления ресурсов.

async/await уродует код, прервращая каждую функцию в конечный автомат. Это 100%-ный костыль. Про эффективность вы лукаваите. Конечные автоматы дают пенальти на каждый вызов каждой асинхронной функции. Это помимо того, что их фиг заинлайнишь. И живут они в куче, а не в стеке.

Господа, такой вопрос. Как лучше сделать вывод изображений на клиент? По средствам обработки запроса в golang? Или пробрасывать к файлу по nginx?

async/await уродует код, прервращая каждую функцию в конечный автомат. Это 100%-ный костыль. Про эффективность вы лукаваите. Конечные автоматы дают пенальти на каждый вызов каждой асинхронной функции. Это помимо того, что их фиг заинлайнишь. И живут они в куче, а не в стеке.

Г-ну хайлсбергу, которые это придумал и вреднил - дорога в ад

асинк авейт удобные штуки

не гоните

3 миллиона сисколов по 73ns занимают примерно 0.22 секунды.

Да, только надо ещё что-то полезное поделать

Господа, такой вопрос. Как лучше сделать вывод изображений на клиент? По средствам обработки запроса в golang? Или пробрасывать к файлу по nginx?

зависит от размера и количества. мелкие - строго пофиг. крупные имеет смысл отдавать через nginx

зависит от размера и количества. мелкие - строго пофиг. крупные имеет смысл отдавать через nginx

Збазиба

а, да, https - строго пофиг, потому что все равно будет чтение блоками и передача в шифратор

async/await уродует код, прервращая каждую функцию в конечный автомат. Это 100%-ный костыль. Про эффективность вы лукаваите. Конечные автоматы дают пенальти на каждый вызов каждой асинхронной функции. Это помимо того, что их фиг заинлайнишь. И живут они в куче, а не в стеке.

А гошный вариант корутин словно бесплатен

для читателя - да

впрочем, async/await тоже недорогой

но дороже

Возьмем тот же TensorFlow от гугла. Сама либа написана на C++, хотя используется чаще всего на Python. В том же пайтоне или go задается только логика вычислений, а сами вычисления производит уже сама либа на проце или видеокарте. По этому выбор языка здесь не критичен, он не должен быть обязательно быстрым.

Думаю сейчас сделать так, тренерую на питоне, после, когда нашел норм модель, запускаю на го. Вроде бы тензорфлоу позволяет + есть библиотеки, которые облегчат биндинг библиотеки.

Можно и так

Похоже, самый оптимальный вариант. Кстати, всегда интересовал вопрос, как вы справляетесь с json объектами?)

А что с ними справляться? Если есть четкая структура - легко.

ERROR: S client not available

А что с ними справляться? Если есть четкая структура - легко.

Я про то, когда нет

Очень любят такую херню большие крипто биржи. У меня случались проблемы, когда они просто брали и добавляли какую-нибудь маленькую переменную и у меня уже бот переставал работать.

Крипта разная бывает) что тебя интересует?

Ещё массивы с разными типами вызывают проблемы.

Я через интерфейсы решал эту проблему

Ещё массивы с разными типами вызывают проблемы.

А как ты решал это проблему в других языках?

Проверкой конкретного поля?

А как ты решал это проблему в других языках?

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

Проверкой конкретного поля?

Да, просто провожу итерацию проверяю на тип.

Там ещё с интерфейсами играться надо. Вроде бы по этому поводу куча статей в интернете, но с другой стороны проблема вечная и из-за недобросовестных парней, которые пишут свое API не думают о разрабах, которые пишут на строго типизированных.

А гошный вариант корутин словно бесплатен

дешевле, но это к слову. гошный вариант - это просто писать код, а не думать о том, какой кусок "сделать аиснхронным". соответственно его и писать и читать легко

а вообще кто-то видел более или мене серьёзный бэкенд на async-await-ах? я - нет. Уверен,что это в принципе невозможно. Вот фронт - это можно, там и так адок.

дешевле, но это к слову. гошный вариант - это просто писать код, а не думать о том, какой кусок "сделать аиснхронным". соответственно его и писать и читать легко

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

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

сейчас это сделано на си шарпе и работает фигово, проблема с памятью, работой гц

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

все кроется в слове "взаимодействовать"

ну там логика ифы и арифметика

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

а нагрузки какие?

и как часто меняются сами наборы?

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

Подскажите, можно ли в fmt.Sprintf заигнорить % ? Хочу сформатировать строку с процентами типа 0.5%, естественно передать %s% не работает. Долепить знак процента уже вне темплейта?

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

Подскажите, можно ли в fmt.Sprintf заигнорить % ? Хочу сформатировать строку с процентами типа 0.5%, естественно передать %s% не работает. Долепить знак процента уже вне темплейта?

ещё один % вот так %%

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

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

ещё один % вот так %%

благодарствую

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

это цена утилизации многоядерности. Сам по себе async-await от этого не избавляет, для синхронизации shared state в промисах/фьючерсах/тасках дополнительно требуются ещё более жуткие вещи, например, фреймворк акторов

ну или теже мьютексы.

это цена утилизации многоядерности. Сам по себе async-await от этого не избавляет, для синхронизации shared state в промисах/фьючерсах/тасках дополнительно требуются ещё более жуткие вещи, например, фреймворк акторов

акторы тут причем вообще?

@pragus , а про 3М udp ответов в секунду что скажешь?