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

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

#51

Post by aloknnikhil » Sun, May 31, 2020, 5:12 PM UTC

asim wrote: post #48

aloknnikhil wrote: post #46

> Service Discovery - Automatic service registration and name resolution. Service discovery is at the core of micro service development. When service A needs to speak to service B it needs the location of that service. The default discovery mechanism is multicast DNS (mdns), a zeroconf system. > Load Balancing - Client side load balancing built on service discovery. Once we have the addresses of any number of instanc…

Not everything is k8s centric but also k8s also has very rudimentary models for discovery and load balancing, this is why things like service mesh have emerged to handle those challenges. As a framework Go Micro builds in client side discovery and load balancing which are completely separate to any third party system. You can imagine the next distributed database to be written with Go Micro which can operating indepe…

Agreed. I'm not saying that this needs to be integrated w/ k8s. I'm merely comparing it to k8s which promises the same abstraction albeit declaratively. The biggest plus point, IMO, for k8s is it makes managing deployments across physical hosts easy. So, I was asking if there was anything equivalent in micro that would help manage my deployments. And your comment on client side discovery and Load balancing partly addresses my original question. My main point here being, I don't see anything in the linked doc on why I'd choose micro over existing frameworks.

EDIT: https://github.com/micro/micro/blob/master/README.md

This page is more informative on why Micro over anything else. So I think this answers my second question.

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

#52

Post by asim » Sun, May 31, 2020, 5:17 PM UTC

bad_op3rator wrote: post #47

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…

Go is already an intentionally simple language with an excellent standard library, and dictates how to do things in the right way. Do we really need something on top of it? Not to mention, it's quite common that engineers like to reinvent the wheel, at least a little bit. It's just part of the fun, no one can blame them for that)

With all due respect I think thats a bit of a short sighted statement. To say a language offers enough is to negate all of the tools built on top which others have leveraged to build other pieces of software. If you imagine all the things you import are they purely the standard library? Very unlikely. In the same way, Go Micro is built on not just Go but many other libraries.

I think if you find value in using the pure standard library, good for you and I commend you on the effort of the not invented here syndrome. But for the rest of us it is much easier when someone else helps us out by laying the foundations for the next thing.

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

#53

Post by jen20 » Sun, May 31, 2020, 5:56 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 dozens of Go programs which use only the standard library - including very large ones. However, there are two primary areas where it is deficient (necessitating pulling additional packages) to my mind:

- Logging - a lack of ability to do structured logging is the main downside here.

- The `syscall` replacements - almost inevitably for larger projects it's necessary to pull in the x/sys/unix or x/sys/windows since package `syscall` was frozen.

The lack of "wrapped" errors also used to be an issue, but this has mostly been resolved with the new "%w" formatting directive to `fmt.Errorf`.

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

#54

Post by atmosx » Sun, May 31, 2020, 6:31 PM UTC

frou_dh wrote: post #24

atmosx wrote: post #11

Earlier quoted context omitted.

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.

Well objective data on this is out there if anyone can be bothered trawling through it: https://github.com/search?o=asc&p=4&q=language%3Ago&s=stars&...

I don't see any useful info there, do you mind translating that for me as it would be interesting to know what % of golang projects uses only the stdlib.

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

#55

Post by atmosx » Sun, May 31, 2020, 6:32 PM UTC

jen20 wrote: post #53

atmosx wrote: post #11

Earlier quoted context omitted.

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 dozens of Go programs which use only the standard library - including very large ones. However, there are two primary areas where it is deficient (necessitating pulling additional packages) to my mind: - Logging - a lack of ability to do structured logging is the main downside here. - The `syscall` replacements - almost inevitably for larger projects it's necessary to pull in the x/sys/unix or x/sys/wind…

I'm not saying that it is not possible I'm saying that it's not happening to the extend that would make that argument true. If 10% of the golang projects were based on stdlib, then I'd buy that argument, but I expect that number for be a lot smaller.

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

#56

Post by solarkraft » Sun, May 31, 2020, 6:43 PM UTC

Why is "microservice" not mentioned anywhere on the page? Sure, it's not a great term, but it would make identification of its goal immediate instead of taking a few seconds.

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

#57

Post by wpietri » Sun, May 31, 2020, 6:50 PM UTC

asim wrote: post #44

wpietri wrote: post #43

Earlier quoted context omitted.

Are these things necessarily opposed? It doesn't seem impossible to me that a "full-fledged framework" also addresses the most common uses cases in ways that don't leave people befuddled.

I think its really a matter of opinion and choice of development. Some people want to build it themselves, others would prefer to use a standard. Its the difference between using Spring or writing tools around Java. Using small libraries or Ruby on Rails.

Again, I don't think they are necessarily opposed. The examples you give are, sure, but that's a library vs framework distinction.

As a contrary example, take a lot of Unix command-line tools. Things like ls and ps have very sensible defaults that cover up very complex models. Or my experience with Python's Twisted is that it is very rich, but it's simple to do simple things. And cryptography libraries are a great example of where well-chosen defaults are absolutely vital. Same with Wireguard. Is what it's up to very complex? Definitely. Do I need to understand the details to get good results? No.

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

#58

Post by bad_op3rator » Sun, May 31, 2020, 8:13 PM UTC

asim wrote: post #52

bad_op3rator wrote: post #47

Earlier quoted context omitted.

Go is already an intentionally simple language with an excellent standard library, and dictates how to do things in the right way. Do we really need something on top of it? Not to mention, it's quite common that engineers like to reinvent the wheel, at least a little bit. It's just part of the fun, no one can blame them for that)

With all due respect I think thats a bit of a short sighted statement. To say a language offers enough is to negate all of the tools built on top which others have leveraged to build other pieces of software. If you imagine all the things you import are they purely the standard library? Very unlikely. In the same way, Go Micro is built on not just Go but many other libraries. I think if you find value in using the pu…

Jeez... with all due respect, not sure it's a great idea to cover yourself with "the rest of us"... but back to the idea of frameworks that make life easier. One of the problems with frameworks is that sooner or later, you start hacking them, breaking the ideas behind them, and make your life complicated. So it's better to think twice before start using any framework. BTW Why do you call it a framework?