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. On Monday, 15 June 2020 at 05:12:31 UTC+2 seghatol...@gmail.com wrote:
> 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/6ef32de2-d0f7-454d-b353-7bd58a77ae71n%40googlegroups.com.
