I believe most cloud providers don't support multicast, meaning mDNS would not work there. It's also quite slow and/or very chatty in large networks.
Looks there is support for other service discovery mechanisms via plugins, though.
For wiw multicast/mDNS works fine on top of ZeroTier.
Although, if the underlying network doesn't, I assume you get a lot of overhead (ie: it probably wouldn't be very beneficial to try and share a video stream via multicast on top of ZeroTier on top of a network without multicast support).
Would it work with Flannel/Calico, etc? Inefficient, but probably okay since it would be just service resolution.
Edit: Looks like no for Calico, Yes for recent Flannel, but Weave Works is probably a better choice, designed to support it from the start.
> PubSub is built in as a first class citizen for asynchronous communication and event driven architectures.
Would be interested to see how this is implemented and what it’s consistency and reliability dynamics are.
I might agree, but it's not the only core pattern.
What if one needs (distributed) transactions? The fact that pub/sub is advertised as a prominent feature makes me think that asynchronous models are preferred, at least in design and philosophy of the framework.
"the Go _community_ is very anti-framework and pro-library"
There is nothing about the language, which is general purpose, that makes it anti-anything really.
(I know that the absence of generics is temporary)
Also, lots of dependency injection patterns everywhere, which is actually a great way when dealing with larger projects.
Can you elaborate on this? I'm not super-familiar with Go but I haven't yet seen anything that suggests it's a poor language choice for frameworks.
This also makes me curious about your definitions of "framework" and "library". Frameworks are just curated collection of libraries that work well in harmony, plus conventions for handling common patterns. No?
Frameworks are often architecture-first and functionality-second, which is vice-versa for libraries. Instead of learning to “do X” you are now learning to “do X using Y”, and that Y often prevents you from knowing and using the full potential of X.
Also, when I say that Go is idiomatically anti-framework, I mean that most idiomatic Go code I've seen, in the stdlib and in the code of the prolific gophers, tends to shun the structure of frameworks. It's in the “Zeitgeist”, if you will. In fact, in my experience most frameworks are written by people who come to Go from other languages and try to take their habits with them. A good example of that is the Martini HTTP framework, the author of which later acknowledged that he was trying to “write Go as if it were another language” and started creating stdlib-compatible middlewares instead.
[1] https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/
It's not that you can't do it, it's just that the entire ecosystem and excellent stdlib encourages you to develop your own code, and makes it very easy to refactor, catching most non-logical bugs at compile time if there are any.
