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. On Sat, Jun 13, 2020 at 2:11 PM <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/CAMV2RqrqrRtsNjN-wT%2BvaZohzotov3JvCDaXxvxxT4jHghCwmA%40mail.gmail.com.
