анонимные ф-ции не подходят?

так это тоже самое по сути. А вызов более “магический”: <-ch()

так это тоже самое по сути. А вызов более “магический”: <-ch()

вызывай ее после того как получил из канала и нчиего магического не будет

кто вам такую чушь сказал?

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

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

вызывай ее после того как получил из канала и нчиего магического не будет

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

вы говорите, что данные должны оказаться в канале ДО запроса

как они там окажутся до?

вы говорите, что данные должны оказаться в канале ДО запроса

это опечатка. Я имею в виду следующее. Задача: есть сенсор в отдельном потоке. Мне надо получить его текущее значение. Сенсор - это не просто число, а результат выполнения некоторой функции.

функция крутится в цикле?

Одним каналом тут не обойтись. Т. к. надо сначала “запустить опрос сенсора” а потом этот результат получить

или она в отдельном потоке выполняется только раз

Ок, ща попонятнее попробую:

1) “клиент” (горутина) хочет получить значение сенсора 2) есть “сервер” (горутина), который это умеет делать 3) сервер получает значение сенсора запуском некой функции (т. к. нужны вычисления) 4) клиент отправляет запрос серверу 5) сервер вычисляет текущее значение 6) отправляет его клиенту

Поскольку в ch <- f() - f выполнится до разблокировки канала, одним простым chan *SensorData не обойтись.

И тут либо два канала, либо вложенный, либо перекидываться функциями

или она в отдельном потоке выполняется только раз

Я сумел внятно изложить постановку задачи?

как выполняется пункт 4?

как выполняется пункт 4?

поскольку мы в go - то через каналы. Если вложенным - то пункты 4-6 покрываются data := <-<-sensorChan Если двумя, то in <- bool, data := <-out

либоя чего-то не пнимаю, либо вы пишете бред

а в чем бредовость?

как sensorServer узнает о том, что ему надо начать собирать данные?

как sensorServer узнает о том, что ему надо начать собирать данные?

если вложенным: <-<-sensorChan - сервер отправляет нам новый канал. Вычисляет значение. Отправляет его в этот новый канал. Каналы без буферов. если двумя: то сигналом служит пришедший из in сигнал. После вычисления результат пишется в out

если вложенным: <-<-sensorChan - сервер отправляет нам новый канал. Вычисляет значение. Отправляет его в этот новый канал. Каналы без буферов. если двумя: то сигналом служит пришедший из in сигнал. После вычисления результат пишется в out

так в чем профит перед одни каналом, куда будут слаться данные от сенсора?

профит чисто косметический. Одна строчка вместо двух.

не, я говорю чем <- <- ch лучше чем <- ch

и сигнатура структуры, где объявлены каналы - тоже на одну строчку меньше

Лучше разделить потоки как выше говорили in out

вы подумайте - это же одно и тоже, только с лишними операциями

не, я говорю чем <- <- ch лучше чем <- ch

ааа) тем, что если на стороне сервера sensorChan <- calculateData() написать, то сначала вычислится calculateData(), а потом будет ожидание разблокировки. Если серверу не слали запросы час - то данные будут на час устаревшими.

а при двух каналах?

почему они будут "свежими"?

а при двух каналах?

при двух вычисления начнутся только при разблокировке первого канала: <-in out <- calcData() или (при вложенных): sensorChan <- innerChan innerChan <- calcData()

значете, если у вас часами он может висеть в ожидании - зачем вам вообще потоки?

чувствуется некий overengineering

значете, если у вас часами он может висеть в ожидании - зачем вам вообще потоки?

Я пишу систему моделирования. У меня “часы” проходят за секунды.

так я понял идею

и вот почему я выказываюсь против такого - сколько времени пришлось потратить, чтобы это объяснить

Лучше разделить потоки как выше говорили in out

Так я не могу услышать объективного довода, почему это лучше? Профиты вложенности: - одна строчка на получение данных вместо двух - меньше переменных в сигнатуре структуры - лучше масштабируется. In/Out будут нормально работать только пока обработка однопоточная. А вот вложенные можно параллелить - мы гарантируем, что возвращаемый канал соответствует только нашему “запросу”.

и вот почему я выказываюсь против такого - сколько времени пришлось потратить, чтобы это объяснить

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

> @ffloyd мы гарантируем, что возвращаемый канал соответствует только нашему “запросу”. хм, а как это ганарнтруется? если я из 10 горутин спрошу один сервер - он отошлет 10 каналов, и каждый ожидающий получит соврешено случайный ответ

на этом прицнипе держится балансировка через каналы

> @ffloyd мы гарантируем, что возвращаемый канал соответствует только нашему “запросу”. хм, а как это ганарнтруется? если я из 10 горутин спрошу один сервер - он отошлет 10 каналов, и каждый ожидающий получит соврешено случайный ответ

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

канал с доступом к серверу один?

канал с доступом к серверу один?

канал запросов один. Он возвращает канал ответа. В случае параллельной обработки - каналы ответа могут быть разными. Это как в вебе считай. IP - один, но подключений много.

Вообще go подбешивает что-то. Generics - да кому они нужны? Immutable types - пиши ручками, если надо. И не забывай, что у тебя нет генериков. Но ты не будешь этого делать ибо у тебя нет времени. Зато будешь молиться, чтобы джуниор случайно не начал менять то, что иммутабельно. Pattern matching - не, не слышали. Circular dependecies - запрет на них с одной стороны дисциплинирует, но с другой иногда крайне неудобен. Итерфейсы - да, классно. Но нельзя тип провернуть вспять. Точнее можно, но только через reflection-магию. select на N каналов - ты не хотел прикасаться к reflection? Ха-ха. В языке есть много классного, но вот эти моменты - бесят.

Про кодогенерацию я знаю. Не считаю это решением годным для production.

A JavaScript interpreter in Go https://github.com/robertkrimen/otto

Вообще go подбешивает что-то. Generics - да кому они нужны? Immutable types - пиши ручками, если надо. И не забывай, что у тебя нет генериков. Но ты не будешь этого делать ибо у тебя нет времени. Зато будешь молиться, чтобы джуниор случайно не начал менять то, что иммутабельно. Pattern matching - не, не слышали. Circular dependecies - запрет на них с одной стороны дисциплинирует, но с другой иногда крайне неудобен. Итерфейсы - да, классно. Но нельзя тип провернуть вспять. Точнее можно, но только через reflection-магию. select на N каналов - ты не хотел прикасаться к reflection? Ха-ха. В языке есть много классного, но вот эти моменты - бесят.

Этот язык не для того что ты перечислил а создавать новый джава или с с тремя плюсами в этом смысла нет? имхо

Этот язык не для того что ты перечислил а создавать новый джава или с с тремя плюсами в этом смысла нет? имхо

Не, я несмотря на критику, считаю го хорошим. Но вот генерики бы ему не повредили. Не нужно супернаворотов как C++ и тем более Scala. Я просто хочу написать алгоритм для сбалансированного дерева и иметь возможность его использовать с разными типами. Что в этом плохого?

Этот язык не для того что ты перечислил а создавать новый джава или с с тремя плюсами в этом смысла нет? имхо

Если забить на pattern matching и circular dependencies и починить оставшиеся пункты - то язык не превратится в Java или очередной Rust. Станет немного сложнее, но зато мощнее. Если в двух словах - видимо go слишком простой на мой вкус)

Не, я несмотря на критику, считаю го хорошим. Но вот генерики бы ему не повредили. Не нужно супернаворотов как C++ и тем более Scala. Я просто хочу написать алгоритм для сбалансированного дерева и иметь возможность его использовать с разными типами. Что в этом плохого?

Есть мнение что генерики не нужны

нужны

очень даже

потому что приведение типов очень задалбливает

Есть мнение что генерики не нужны

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

Возьми хаскель сделай то что хочешь и через ffi свяжи и дальше наслаждался го?

Возьми хаскель сделай то что хочешь и через ffi свяжи и дальше наслаждался го?

чаще всего haskell впсоминают люди, которые на нем не писали

Советую прочитать http://codeblog.shank.in/poor-mans-generics-in-golang/

Да нет так балуюсь но да там слёзы а вот то что роман хочет мне кажется там просто а даже очень просто

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

Или ленятся

Советую прочитать http://codeblog.shank.in/poor-mans-generics-in-golang/

v := st.Pop().(MyStruct) // need to convert the interface{} to MyStruct вот эти need to convert по идее очень нужны?

Но отсутствие генериков это плюс имхо

и в секции in conlusion

ERROR: S client not available

Но отсутствие генериков это плюс имхо

Это минус, пока нет эффективного механизма решать задачи без них. Решение генерик-задач через reflect - это боль.

Но отсутствие генериков это плюс имхо

раз советуешь прочиать - сам прочитал секцию in conlusion?

This leads to decrease in performance. For example a stack of int type was 15 times faster in my personal benchmarks. And thats a lot !

вот это радует

давайте либо дергать типы туда и обратно, либо иметь по 3-4 одинаковых алгоритма

Но отсутствие генериков это плюс имхо

Например, было бы ок, если б можно было на уровне compile-time использовать интерфейсы, а не тупо [T], но с возможностью выпилить обратно в исходный тип чем-то простым, например original(variable)

В Go 2 будет вам решение

В Go 2 будет вам решение

Пруфы есть?))

Есть обсуждения на гугл группс и гитхабе)

Просто нельзя взять и просто запилить генерики как в остальных языках

Я все-таки ставлю на то что го взлетит, хотя он и так взлетает

Я все-таки ставлю на то что го взлетит, хотя он и так взлетает

Он уже взлетел. Посмтри на докер, на продукты hashicorp и на какой-то бешенный хайп, который порождает монстров вроде beego.

Он уже взлетел. Посмтри на докер, на продукты hashicorp и на какой-то бешенный хайп, который порождает монстров вроде beego.

почему монстр?

почему монстр?

Мое личное мнение: go хорош для микросервисов, обработки логов, аналитики, но не для вещей типа Django/Rails. Хочешь адовое количество запросов обрабатывать и соединения держать - есть Phoenix. Быстро напрототипить, чтобы работало - rails/django. Сайт на пару страниц - тут хоть на lua пиши. Но вот полноценный фреймворк на go - это болезнь.

Юзал лично феникс?

Как по перфомансу относительно го?

Как по перфомансу относительно го?

все упрется в производительность хранилища и ширину канала

как в go, так и в elixir

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

И трейдофф скорость сервиса / скорость разработки?

В общем у меня есть вопрос, задавал в комьюнити эликисира, толком не ответили

Сек

И трейдофф скорость сервиса / скорость разработки?

elixir сложнее go, но мощнее и выразительней erlang. На go может и быстрее прототип напишешь, но вот приложение на elixir/phoenix будет стабильней (иммутабельные типы данных, OTP и супервизоры). Сам в феникс еще не настолько глубоко вник, чтобы найти и прочувствовать его проблемы.

А как можно сделать приложение, которое не теряет соединения по http при перезагрузке? Вообще возможно такое?

Но зачем?

при деплое

и? зачем не терять соединения? они атомарны в 144% случаев

А как можно сделать приложение, которое не теряет соединения по http при перезагрузке? Вообще возможно такое?

может будет достаточно cookies ?

т.е при убийстве процесса и запуске нового я не потеряю соединения?

зачем тебе сохранять их?

чтобы обработать каждый запрос

https://github.com/facebookgo/grace