gddo

I agree that it would have been better to design these a little differently. In the first case the go-import meta tag is totally unnecessary. The go tool and module proxy can discover git repos from an import path just fine. It’s only required for “custom” import paths where the path is some domain but the code lives somewhere else, like github. In the latter case the decision to use go-source was actually made by the original author of godoc.org, not a google employee, and was done in coordination with another non-google initiative (gopkg.in) to make their source links work. So nothing to do with the go team really, sorry. https://github.com/golang/gddo/commit/864b1c0aba009e37d30136... If pkg.go.dev isn’t respecting go-source meta tags then that should probably be fixed. It would also imo be worth considering devising a more general, wel

Without making grand pronouncements about The Right Way, I at least get why the Go community shies away from all-inclusive frameworks after years of using Django. An all-inclusive framework is super helpful for getting started quickly, but the way its components can be deeply tied with each other can make life tricky when you want to do some things that weren't quite what the framework authors envisioned. If you glued the components together yourself, you at least know they're separable and where they fit together. There are popular packages for the sorts of things that a lower-level Python framework might: - http://www.gorillatoolkit.org/ has a more flexible router, sessions, and some other basics on the Web side - Built-in html/template is a pretty good place to start. (The context-aware escaping is something I wish I had.) - Popular da

> Anon the intern needs to be able to open up Programmingâ„¢ and click 'New Web Form' are adequate for people who usually don't program, and extremely inadequate for people who usually do. Let's change the example to "Start Web Server" instead. I think the best solution for this is the way Go does it. It takes the best of both worlds. http.ListenAndServe(":8080", nil) That's one line to start a web server on port 8080. It's as easy as pressing a 'Start Web Server' button, yet it scales to dl.google.com. The problem is when you press 'Start Web Server' or 'New Web Form' and it generates 300+ lines of boilerplate code that you now have to look at, maintain, and waste your attention on. Advanced users don't want that, and novice users aren't happy about it either. Instead, take high level things and make them available via high le