Show HN: Go Micro – A distributed systems development framework • Hacker News Board

Re: Show HN: Go Micro – A distributed systems development framework

#31

Post by konart » Sun, May 31, 2020, 2:02 PM UTC

pfalafel wrote: post #29

asim wrote: post #26

Earlier quoted context omitted.

Go Micro is a framework/library as opposed to a binary or server. You import the framework in code and it gives you the ability to add additional plugins via new imports. These can then be swapped out via environment variables or flags. We make use of Go interfaces to define the abstractions so all you have to do is create a plugin that implements the interface and that effectively makes it pluggable. Here's the comm…

What exactly does it mean to say that plugins "can then be swapped out"? I assume a binary Go plugin can not in fact be unloaded from memory. So modifying and reloading a Go plugin will result in multiple versions of it to then stay in memory. This is a shortcoming of the current Go implementation. Is my understanding correct?

I think you are confusing whatever go micro is offering with https://golang.org/pkg/plugin/

I'm pretty sure go micro's plugins are just additional packages each for its purpose ready to be imported and used in your project.

Basically a collection of community maintained packages for the most common utils\middleware\MQ clients etc

Re: Show HN: Go Micro – A distributed systems development framework

#32

Post by asim » Sun, May 31, 2020, 2:03 PM UTC

pfalafel wrote: post #29

asim wrote: post #26

Earlier quoted context omitted.

Go Micro is a framework/library as opposed to a binary or server. You import the framework in code and it gives you the ability to add additional plugins via new imports. These can then be swapped out via environment variables or flags. We make use of Go interfaces to define the abstractions so all you have to do is create a plugin that implements the interface and that effectively makes it pluggable. Here's the comm…

What exactly does it mean to say that plugins "can then be swapped out"? I assume a binary Go plugin can not in fact be unloaded from memory. So modifying and reloading a Go plugin will result in multiple versions of it to then stay in memory. This is a shortcoming of the current Go implementation. Is my understanding correct?

Do not assume "Go Plugin" in this context. We are not using the Go plugin system. Plugin is a name used to describe something that can be "plugged in" or that is "plug and play". In our case as mentioned, we use the Go interface as an abstraction and the "Plugin" is an implementation of that interface which can replace what you're using.

You will import plugins for rabbitmq, kafka, etc as a Go import. You can then use env vars and flags to choose which you want to use. Internally we are taking an initialiser for New[Plugin] from a list and executing it to set it up. There is no Go language plugin loading, its all still compiled code. Its just how we use the abstraction.

Please see the readme for our plugins for more detail https://github.com/micro/go-plugins

Re: Show HN: Go Micro – A distributed systems development framework

#33

Post by literallycancer » Sun, May 31, 2020, 2:03 PM UTC

asim wrote: post #15

mrath wrote: post #12

Earlier quoted context omitted.

Sorry I intend to say, does anyone use micro in production?

Production users of Micro! https://dev.micro.mu/users

You probably want to present this list somewhere on the landing page.

Re: Show HN: Go Micro – A distributed systems development framework

#34

Post by ryanpetrich » Sun, May 31, 2020, 2:04 PM UTC

pfalafel wrote: post #29

asim wrote: post #26

Earlier quoted context omitted.

Go Micro is a framework/library as opposed to a binary or server. You import the framework in code and it gives you the ability to add additional plugins via new imports. These can then be swapped out via environment variables or flags. We make use of Go interfaces to define the abstractions so all you have to do is create a plugin that implements the interface and that effectively makes it pluggable. Here's the comm…

What exactly does it mean to say that plugins "can then be swapped out"? I assume a binary Go plugin can not in fact be unloaded from memory. So modifying and reloading a Go plugin will result in multiple versions of it to then stay in memory. This is a shortcoming of the current Go implementation. Is my understanding correct?

It's pluggable in that large parts of it can be replaced or disabled at compile time. Runtime reconfiguration isn't well supported.

Re: Show HN: Go Micro – A distributed systems development framework

#35

Post by npiit » Sun, May 31, 2020, 2:09 PM UTC

Dunno why the adversity in the comments. Great job, OP. I think there is a real need for something like this as the GitHub stars show, I considered using Kubernetes itself as a distributed infrastructure but it may be a bit heavy for many use cases. I think this can be a serious alternative for distributed systems that do not have intention to be built over Kubernetes.

Re: Show HN: Go Micro – A distributed systems development framework

#36

Post by giancarlostoro » Sun, May 31, 2020, 2:38 PM UTC

asim wrote: post #3

throwerawa174 wrote: post #2

Not dissing your efforts, but you keep posting your Go Micro stuff, under different account names (chunk) in Show HN and normal threads. 90% of these posts add nothing and are just duplicates. Maybe add a blog post or something of value instead of the same old link every time.

Thanks for your comment. I post a link to the github repo periodically because the project is moving incredibly fast and actively evolving to become something that's fundamentally valuable to those building distributed systems, cloud services and want to build applications with Go using a framework. People also come and go on HN so don't always get a chance to see it or dont' remember the project. I'm also always act…

> the project is moving incredibly fast and actively evolving

Not that I'm hating, but one of the comments above made a valid point that this part of your comment suggests is correct: maybe you should be blogging about progress of the project and gain plenty of eyeballs?

One thing I saw that fascinated me is you guys are using mDNS for discovery, I was debating this discovery approach for a small microservices foundation for D but I couldnt even find a decent library so I havent really attempted much work in that approach. I did something that in a sense feels like a micro service architecture entirely with mDNS but in Python, then months later I worked with microservices in Java and it felt so bloated and overcomplicated compared to mDNS.

Re: Show HN: Go Micro – A distributed systems development framework

#37

Post by city41 » Sun, May 31, 2020, 2:53 PM UTC

jiofih wrote: post #22

parhamn wrote: post #17

Earlier quoted context omitted.

If you can only confront someone using a throwaway account, you’re probably being unnecessarily mean. Glad they’re trying to get word out there on what they’re working on. Let the voting do the voting. Thank for your OS work OP, upvote from me. Looks like a cool project!

I understand the positive viewpoint, but don’t feel it’s in the spirit of HN to repost your own project every couple months. Back in the day even just posting your own stuff (instead of someone else who found it interesting) was frowned upon. IMO a culture of curiosity vs blatant promotion is an asset for this board and should be preserved. I counted at least 26 reposts of go-micro. At what frequency should we just c…

When has self promotion here been frowned upon? It’s even officially supported with “Show HN” posts.

Re: Show HN: Go Micro – A distributed systems development framework

#38

Post by lowmagnet » Sun, May 31, 2020, 3:00 PM UTC

pfalafel wrote: post #29

asim wrote: post #26

Earlier quoted context omitted.

Go Micro is a framework/library as opposed to a binary or server. You import the framework in code and it gives you the ability to add additional plugins via new imports. These can then be swapped out via environment variables or flags. We make use of Go interfaces to define the abstractions so all you have to do is create a plugin that implements the interface and that effectively makes it pluggable. Here's the comm…

What exactly does it mean to say that plugins "can then be swapped out"? I assume a binary Go plugin can not in fact be unloaded from memory. So modifying and reloading a Go plugin will result in multiple versions of it to then stay in memory. This is a shortcoming of the current Go implementation. Is my understanding correct?

The runtime you build will have all plugins micro supports by default at time of compile, and any custom plugins you create that implement the interface. They are hot-loaded at runtime, but you are correct in that you cannot unload them. Since the switching is done by environment variables, you'd have to restart to reload with other plugins.

Plugins are really specific by platform combinations and support, so you're unlikely to change them much after initial launch. It's only useful if you're going from metal to cloud provider or changing the method of interaction between you API layers.

Re: Show HN: Go Micro – A distributed systems development framework

#39

Post by lowmagnet » Sun, May 31, 2020, 3:02 PM UTC

ryanpetrich wrote: post #34

pfalafel wrote: post #29

Earlier quoted context omitted.

What exactly does it mean to say that plugins "can then be swapped out"? I assume a binary Go plugin can not in fact be unloaded from memory. So modifying and reloading a Go plugin will result in multiple versions of it to then stay in memory. This is a shortcoming of the current Go implementation. Is my understanding correct?

It's pluggable in that large parts of it can be replaced or disabled at compile time. Runtime reconfiguration isn't well supported.

Well if you pack in a new communication bus plugin, you'd still have all of the defaults (rabbitmq, and so on) available in addition to the one you add. You can use Environment variables to pick the one you want by its name.

Re: Show HN: Go Micro – A distributed systems development framework

#40

Post by lowmagnet » Sun, May 31, 2020, 3:06 PM UTC

atmosx wrote: post #11

asim wrote: post #8

Earlier quoted context omitted.

I think the Go community in its early years advocated for libraries over frameworks. 1. Because of the very powerful standard library which dictated the development model and culture of the community. 2. Because Go was still such a young project. I think its only natural over time that frameworks and tools emerge to simplify the development experience in every language. We realistically cannot ask people to piece tog…

The “powerful standard library” to my experience is a myth that holds no water. Even trivial projects use external packages to handle trivial things like an HTTP server or logging. No project I saw, however small, uses just the standard library.

I've written several services in my line of work where I was able to stick completely within the standard libraries. Half of my personal go projects likewise use the stdlib only. One of the projects that doesn't conform could do with a little coaxing, I only use afero for test convenience of creating a virtual fs. I'm likely to remove it in a future update.