cannot find package

в итоге путь у меня /home/develop/projects/go/src/_/home/develop/projects/go/src/shop/.... :D

1. как ты импортируешь пакеты из вендора? 2. где находится vendor относительно твоего проекта

в корне проекта

импортирую стандартно: ... "github.com/micro/go-micro/errors" "gopkg.in/dgrijalva/jwt-go.v3"

в корне проекта

access-token где находится?

/home/develop/projects/go/src/shop/srv/access-token тут GOPATH /home/develop/projects/go

/home/develop/projects/go/src/shop/srv/access-token тут GOPATH /home/develop/projects/go

и ты запускаешь go build изнутри access-token/ ?

go run / go build не пашет ошибки повторяются: cannot find package

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

какую проблему ты хочешь решить и зачем?

и ругается на зависимости

dep ensure чего говорит?

ничего не ругается все зависимости успешно падают в vendor

go run / go build не пашет ошибки повторяются: cannot find package

про go run забудь) откуда вызываешь go build? из какой папки?

из корня проекта

из корня проекта

/home/develop/projects/go/src/shop/srv/access-token ?

верно

какую проблему ты хочешь решить и зачем?

прочитал https://habr.com/company/badoo/blog/420407/ и задумался. Там про акторы упоминали, как решение проблемы. Хочу понять можно-ли(и насколько это оправдано) их в Го использовать + сравнить с моделью использования в erlang.

верно

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

он пытается по GOPATH найти либу в /home/develop/projects/go/src/_/home/develop/projects/go/src/shop/srv/access-token/vendor/github.com/golang/protobuf/proto префикс примешивает в виде /home/develop/projects/go/src/_

я не понимаю по какой логике он это делает :D

нашел proto.actor, но есть сомнения

да и хочется про реальный опыт узнать

прочитал https://habr.com/company/badoo/blog/420407/ и задумался. Там про акторы упоминали, как решение проблемы. Хочу понять можно-ли(и насколько это оправдано) их в Го использовать + сравнить с моделью использования в erlang.

чёт слишком абстрактно, о чём конкретно идёт речь?)

об использовании модели акторов в го. Насколько это оправдано и личный опыт

прочитал https://habr.com/company/badoo/blog/420407/ и задумался. Там про акторы упоминали, как решение проблемы. Хочу понять можно-ли(и насколько это оправдано) их в Го использовать + сравнить с моделью использования в erlang.

"параллельное" программирование не сложно, "конкурентное" программирование уже сложнее, вся сложность кроется в shared state'е

вроде как акторы эту проблему и решают

об использовании модели акторов в го. Насколько это оправдано и личный опыт

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

вот вам пример, как uuid можно генерить, если ваша БД этого не умеет https://play.golang.org/p/4FkNSiUDMg

я пользуюсь https://github.com/satori/go.uuid очень удобно

я пользуюсь https://github.com/satori/go.uuid очень удобно

аналогично

прочитал https://habr.com/company/badoo/blog/420407/ и задумался. Там про акторы упоминали, как решение проблемы. Хочу понять можно-ли(и насколько это оправдано) их в Го использовать + сравнить с моделью использования в erlang.

когда-нибудь тебе откроют тайну про акторы в го

ну или ты сам их найдёшь

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

тут задача обратная - понять какие проблемы можно решить с помощью акторов в Го (и нужно-ли вообще их так решать)

тут задача обратная - понять какие проблемы можно решить с помощью акторов в Го (и нужно-ли вообще их так решать)

зачем тратить время?))

парни, а вы новому совсем не учитесь?

или готура для вас достаточно?

ты ведь не понял что такое актор

парни, а вы новому совсем не учитесь?

я лично учусь на практике решая конкретные задачи)

тут задача обратная - понять какие проблемы можно решить с помощью акторов в Го (и нужно-ли вообще их так решать)

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

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

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

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

чушь какая-то)

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

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

https://habr.com/post/138700/

https://habr.com/post/138700/

а как это к акторам относится?

https://medium.com/@ostvp/parallelism-models-actors-vs-csp-vs-multithreading-f1bab1a2ed6b

а как это к акторам относится?

никак, они просто похожи

видимо до смешения...

видимо до смешения...

за экторами тебе явно в другой чатик)

похоже на то... но мало-ли.

от языка оно всё 1 чёрт не зависит.

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

не будет-ли это overengineering'ом?

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

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

а, я думал ты за подход в целом спросил под занавес

но это мои сомнения, точно я не знаю, поэтому тут и спрашиваю

в целом, у го вполне себе неплохой сборщик.

подход прекрасно себя зарекомендовал в эрланге, за это я не переживаю. Но вот за попытку имплементации модели в Го как-то неуверен

не уверен, что используя модель экторов ты в него упрёшься

в целом, у го вполне себе неплохой сборщик.

В целом мама считает что я красивый....

я к тому, что хочется тестов )

с цифрами и замерами

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

но это я многого хочу, да )

видимо придется, раз никто этого еще не делал

я пользуюсь https://github.com/satori/go.uuid очень удобно

А оно разве не deprecated? https://github.com/satori/go.uuid/issues/84

ну ибо гц - не самая большая проблема экторов)

если вообще проблема

а в чем бОльшая проблема? )

А оно разве не deprecated? https://github.com/satori/go.uuid/issues/84

о спасибо возможно

ты не поверишь...) в локах. Это медленно, дорого и аще фу :)

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

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

ну возьми тот же аукцион и прикинь, где они там могут возникнуть

именно локи - не представляю

если нет shared state'а, откуда локи?

за что они биться начнут?

разве что из-за лока на мапу пидов

это если в тупую реализовывать

если подумать и использовать другие СД, то локов не будет вообще

если нет shared state'а, откуда локи?

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

так это шедулер рулит. Локов там все-равно не будет

и как этим шедулер рулит?

есть данные для актора - работаем. Нет - спим

все как у взрослых )

весь вопрос в IPC )

если сделать его эффективным, асинхронным и на правильных СД, то модель будет работать "на ура"

тот-же fsm

саги (читай, fsm твой) не гарантируют тебе согласованности) ну вот прям совсем никак.

ты не путаешь локи с блокировками?

ты не путаешь локи с блокировками?

нет, ибо это одно и то же)

видимо, мы с тобой немного про разные участки вещаем :)

ваще да )) обратная сторона.

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

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

и мапа пидов

локи на инсертах и делитах