Maybe a dumb question but: Why would we *need* a standard framework? We're currently re-working this at my workplace and in the process, I've looked at both go-kit and micro. Ultimately, at least as far as I can tell, they don't seem to solve any of the problems I'm seeing, though. Both of them tend to try and abstract over transports and backends for microservices. But we don't need an abstraction. We already chose a transport, a monitoring API, a tracking API... All we really need is to make it as simple as possible for service authors to use all of them. At least to me, it seems we're better served with a couple hundred lines of boilerplate in one package which can be shared. And where you don't have to figure out how to get the functionality out of the abstraction first.
Ultimately, that's what I see as the problem with open source solutions in this space. They are forced to abstract over many different solutions to the same problem and as a result can only ever support the smallest common denominator. While rolling your own, specialized solution to the problem let's you do it in a fraction of the code size, while giving you all the power to decide what you use and how, based on your own operational needs. On Sat, Jun 13, 2020, 22:11 <a...@aslam.me> wrote: > Might not be the right place for this discussion but also useful to gauge > the experiences of the community. For the most part Go embodies a standard > library philosophy and most people are opposed to using any full fledged > framework. With Go now being a decade old, I feel as though with that > maturity there needs to be maturity in the development ecosystem as well. > Every language inevitably has a framework to address the common problems of > the platforms they're predominantly used for, whether it was Rails for Ruby > or Spring for Java. I've been working on something similar for Go for the > past 5 years (https://github.com/micro/go-micro) but have started to > shift some of my thinking about how best to approach this for Go. > > It's clear that most organisations compose a "shared library" or "starter > kit" for building applications or distributed systems so they're not copy > and pasting this every time and it gives them one place to change numerous > things. This by any other name is a framework but still also a library > given you import it. But when these things appear as open source e.g > go-micro, there's less inclination for the wider community to adopt. I > think over time the standardisation makes sense but maybe in two parts. I > think we as a Go community need a standard library for distributed systems > development. And it appeared like go-kit might be one of those things but > the development there has largely stalled. I'd argue if go-micro could be > reoriented into that standard library and the interfaces evolved to meet > the needs of developers on top of Go we might have something that > accelerates our development and we can all rally around. In doing so we > shift our rails/spring like framework efforts to a separate project ( > https://github.com/micro/micro). > > All that aside, what is the next layer of abstraction for Go? After a > decade we see a lot of tools built with Go, a lot of different development > models, but unlike ruby, python, java, etc we are not seeing a dominant > framework. Where do we go from here? Where do we end up in the future? Is > this something the Go team would look at themselves? Will it come from a > cloud provider? Interested to hear the thoughts of everyone here. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/bd3be4a2-c737-47ab-8eb2-c516c797be55o%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/bd3be4a2-c737-47ab-8eb2-c516c797be55o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHC%3Dr6baVCs%3DABDrM%3DJL88YRRFCZ-as5a5PoNBNSVCecQ%40mail.gmail.com.
