That is why a senior engineer creates a facade for the specific problem domain.
> On Jun 13, 2020, at 3:29 PM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > > 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. > > -- > 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. -- 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/7772BB01-35F8-4CA3-9719-4FF441637F52%40ix.netcom.com.
