Даже не пытайтесь в реактивное программирование в Go. Язык для этого совершенно не годится.

оно здесь особо и не нужно по сути

оно здесь особо и не нужно по сути

Конечно, когда стейтлес апишку пишешь оно не нужно.

А для остального го как бы и не годен.

Конечно, когда стейтлес апишку пишешь оно не нужно.

причём тут stateless?

А для остального го как бы и не годен.

холивар тригер детектед

холивар тригер детектед

Меня самого чувак затригерил своим вопросом про обсервбл. У го есть своя (узкая) ниша и реактивное программирование в нее не вписывается.

причём тут stateless?

Потому-что реактивное программирование это про сложную работу с состоянием.

хм?

Го работает с асинхронным (неблокирующим) IO. При этом когда горутина делает IO вызов го скедулер укладывает её спать.

Чтобы это все работало под капотом нужен евентлуп.

да ладно.. просто попробуйте))

да ладно.. просто попробуйте))

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

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

для консоли, честно тебе говорю, не парься... это тебе не 3d движок с гарантией на 16.6 миллисекунд на кадр... просто зафигать горутину, которая спит 50мс, читает данные и выводит их на экран, эдакий rendering loop

?

?

ну а что?))

Народ, у меня объявление: Каждый месяц я буду разыгрывать по от $50 до $100 за: - самую популярную статью об https://github.com/gramework/gramework на таких платформах, как medium, habr.com, digitalocean (если вы хотите опубликовать статью на другой платформе вам нужно написать мне, чтобы я сначала проверил, можно ли автоматически проверить всё нужное для нахождения самой популярной статьи). Автор самой популярной статьи месяца получит деньги. ВНИМАНИЕ: статьи, которые просто копируют примеры из ридми проекта и не дают новых знаний о grarmework читателям, не участвуют в акции. - самого активного контрибьютора. Я добавлю специальные баллы в названия тикетов и контрибьютор, собравший наибольшее количество баллов (при этом не меньше 4), получит деньги. Вы можете создавать новые тикеты с вашими пожеланиями, я буду ставить баллы на них. Я сам не участвую в этом рейтинге и не считаю свои же баллы.

не зря говорят что гитхаб это инстаграмм

не зря говорят что гитхаб это инстаграмм

в каком-то плане да ?

Нет, чувак серьезен

Хай всем

Хай всем

хайль)

Здесь писали, мол мьютекс тормозит систему, есть ли из вашего опыта библиотеки, которые вы используете для реализации, скажем, конкурентной карты. И ещё, вы говорите state? Такой диалект обычно используют жаваскриптеры, если так, вы можете подсказать, что в го мне может помочь реализовать некое подобие observable из mobx js?

Мутекс тормозит систему?!

в го работа с массивами goroutine-safe?)

нет

ых

любое изменение - не goroutine-safe

любое изменение - не goroutine-safe

с числами же вроде как-то можно, разве нет?

с числами тоже рейсы возможны

лан, спасибо всё равно

если вы изменяете данные

если только читаете - то никаких проблем нету

@rvasily привет, это не ты случайно роликах про обучение го снимался? )

@rvasily привет, это не ты случайно роликах про обучение го снимался? )

да, я

Goroutine-safe только каналы, atomic

да, я

респект, ролики агонь!

Уже об sync.Mutex можно споткнуться

Здесь писали, мол мьютекс тормозит систему, есть ли из вашего опыта библиотеки, которые вы используете для реализации, скажем, конкурентной карты. И ещё, вы говорите state? Такой диалект обычно используют жаваскриптеры, если так, вы можете подсказать, что в го мне может помочь реализовать некое подобие observable из mobx js?

"мьютекс тормозит систему" - это бред и абсурд. Это всё равно что сказать "массив тормозит систему" или "канал работает не правильно" ни какой аналог observable из mobx js вам в голанге не нужен

Goroutine-safe только каналы, atomic

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

буферизированные каналы?

Буферизованные каналы

Буферизованные каналы

но они же не могут быть бесконечно большими?

не могут

точнее расширяться

а я не могу заранее знать количество задач

они вообще не могут расширяться, это не слайс

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

особенно если вы туда передаёте указатель на структуру, например

так, канал на 10к указателей будет в памяти примерно 80 кб занимать

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

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

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

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

пул запускается и отключается асинхронно

зачем?

лучше просто сделать его синхронным?

зачем?

я заядлый nodeист

что значит "сделать синхронно"?

ожидать выполнения всех задач после запуска

запускаете пул и он работает, нет задач - ждёт

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

наверное я просто говнокодер

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

Привет, у меня protoc перестал добавлять // Server API for service и // Client API for service

и дожидаться вы будете именно своей группы

ERROR: S client not available

Привет, у меня protoc перестал добавлять // Server API for service и // Client API for service

Код не менял

наверное я просто говнокодер

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

Сейчас код генерируется просто без них. Я хз что делать

лан, спасибо за помощь

Сейчас код генерируется просто без них. Я хз что делать

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

лан, спасибо за помощь

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

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

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

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

protoc --go_out=../src/number -I ../src/number/ number.proto

protoc --go_out=../src/number -I ../src/number/ number.proto

забыли

да

Блин, спасибо огромное. Сейчас час тупо смотрел на код, не понимал что происходит

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

1. бинарный протокол, как формата, так и транспорта( http2 ) 2. за счет http2 оно в 1 соединение много запросов шлёт 3. генерация клиента и сервера для большого количества языков

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

ок, гляну потом

а, да, ещё генерация структур тоже дял всех языков

1. бинарный протокол, как формата, так и транспорта( http2 ) 2. за счет http2 оно в 1 соединение много запросов шлёт 3. генерация клиента и сервера для большого количества языков

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

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

це-ж вроде как Thrift? т.е. есть IDL?

да

но Thrift от фейсбука, гуглу не комильфо было его использовать :)

Уже об sync.Mutex можно споткнуться

Расскажите пожалуйста почему RWMutex безопаснее Mutex

он не безопаснее

просто оптимальнее для чтения

Расскажите пожалуйста почему RWMutex безопаснее Mutex

безопаснее? никак не безопаснее, суть в том, RWMutex позволяет не блокировать одновременные чтения, это shared и exclusive locking, почитайте

я текст выше не так понял, сорян

1. бинарный протокол, как формата, так и транспорта( http2 ) 2. за счет http2 оно в 1 соединение много запросов шлёт 3. генерация клиента и сервера для большого количества языков

– не надо писать API клиенты (кто это любит) – соблюдается контракт (proto файл он же дока) PS. REST != JSON RPC

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

удобно дебажить (нет)

я бы конечно про контракт рассказал * gql кхм *.. но не буду)

Расскажите пожалуйста почему RWMutex безопаснее Mutex

он не безопаснее, он просто позволяет взять больше одного RLock параллельно

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

Чисто мне зашёл за счёт: Кодогенерации Пусть и странной, но версионности

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

И ещё он не привязан к http-verb'ам

Расскажите пожалуйста почему RWMutex безопаснее Mutex

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