The next layer of abstraction for Go development?

[as...@aslam.me]

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.

[Axel Wagner]

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.

--
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...@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.

[Robert Engels]

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 <golan...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHC%3Dr6baVCs%3DABDrM%3DJL88YRRFCZ-as5a5PoNBNSVCecQ%40mail.gmail.com.

[burak serdar]

I would also question the need for a "full-fledged" framework. The
motivation behind such frameworks is to make development (writing)
easier by either making some choices you otherwise have to make which
would require a deeper understanding of the problem and solution
domains or by deferring those decisions using abstractions. Although
they speed up initial development, they don't make maintenance any
easier. What I like about the Go ecosystem is the emphasis on
readability. Deciphering multiple layers of abstractions is not easy,
and defeats the primary purpose of such frameworks by allowing
developers to quickly write code that can only be maintained by tribal
knowledge.

I remember spending hours trying to diagnose a bug in a web app using
Ruby on Rails. It turned out to be a modification to the behavior of
an elementary function deep in the framework. It makes writing code
easier, but you cannot trust what you read anymore.

[David Skinner]

I am very very old, and very old school, so I always start with UMLs and ERDs and design my apps long before I do any coding. These flowcharts are visual representations that are concise and easy to understand and they are saved as XML which can be parsed by a Go program controlled by +generate in the docs.go file to boilerplate most of my code. Other Go programmers have written parsers that convert Go programs to UML and ERDs. I am stressing these concepts because they are useful abstractions that are quite common and implementation is usually quite consistent. and I design my apps, not at a computer, but rather at a Cajun restaurant using napkins while discussing the issues with the stakeholders. We do have a default standard project framework but it is mostly just empty directories to guide the juniors into placing things in a consistent way. Most frameworks are very opinionated, they may make life easier for a while, but first, you must learn the framework and then you learn how to get around the limitations of the framework. With Go, I can roll my own and we can have something that is ideal for our clients, even if no one else wants to use it.

[Saied Seghatoleslami]

As evidence for not needing the next layer of abstraction, I offer Django class-based-views.  The go approach is much more understandable and easier to follow.

[Anderson Queiroz]

My opinion is that one of the reasons other languages need a framework is that the standard library is too hard to work with. So the frameworks take some of these burden and also take a lot of decisions for the you. In Go the standard library is powerful and simple enough to us to build the abstractions we need on top of it. Of course nothing is perfect and we see some big libs solving some problem such as routing, what is good, and we use them. Also even with frameworks I see companied tend to create another layer on top of them to enforce/facilitate their standards, the same happens in Go, we end up creating libs which no framework will replace as they are company specific. That's why we don't need a big framework for Go, if there was indeed this need we'd see some arising, but again, as the standard lib is so good we don't need one.