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.
On Saturday, June 13, 2020 at 4:11:59 PM UTC-4, Asim Aslam 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/b8d6397e-ab8d-42d2-aa9f-46608a0d75d6o%40googlegroups.com.
