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.
On Saturday, June 13, 2020 at 3:11:59 PM UTC-5, 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/c48e65e1-8c2e-46cb-8ae5-0c4eeaf5bcb8o%40googlegroups.com.
