4 ms·

To those who say frameworks are needed because the stdlib is not enough: No, the stdlib defines very clear interfaces that libraries can implement. The result i

by SPBS 6y ago

To those who say frameworks are needed because the stdlib is not enough: No, the stdlib defines very clear interfaces that libraries can implement. The result is that you can drag and drop middlewares from multiple packages into your codebase, because they all conform to the universal middleware signature `func(http.Handler) http.Handler`. Want CSRF? Want Sessions? Want Auth? They all exist as separate packages (check out the Gorilla toolkit), but the beauty is that they all work without needing to know the existence of each other. Frameworks like Echo and Gin eschew the universal middleware signature `func (http.Handler) http.Handler` for their custom built ones, and as a result cannot tap into the ecosystem of middlewares that target Go's net/http. Between a stdlib package and a third party package, which do you think is more stable? You are not constrained to net/http's router. Chi is a good example of a third party router that implements features not in net/http but still conforms to the `func(http.Handler) http.Handler` interface, and as a result middlewares that work for net/http will also work for Chi. https://justinas.org/embrace-gos-http-tools https://justinas.org/embrace-gos-http-tools

mmgutz 6y ago
A much needed interface in stdlib is logging.
- johnisgood 6y ago
  Yeah I made a library for that. I am not sure if people are actually using it but it got over 70k goddamn hits in my access.log!
cdent 6y ago
Agree. I wasn't at all convinced by the examples showing the Echo was somehow better than using the "built in" signatures, especially since there's quite a bit of handling that Echo (and things like it) makes implicit that you'll probably want to be explicit in some edge case. Coming from WSGI, I found go's middlwares familiar and positively pleasant. I too ended up on Chi as the router that worked well without getting in the way.
morelisp 6y ago
> Frameworks like Echo and Gin eschew the universal middleware signature `func (http.Handler) http.Handler` for their custom built ones, and as a result cannot tap into the ecosystem of middlewares that target Go's net/http. Between a stdlib package and a third party package, which do you think is more stable? I think you're overstating the cost of using "proprietary" middlewares. I'm most familiar with Gin; it is trivial to wrap a "universal" middleware in a Gin middleware (gin.WrapH). It is not trivial to make a universal middleware that does the equivalent of gin.Context#AbortWithError. I don't fully disagree either - obviously `gin.WrapH` everywhere is noise, but so is e.g. `chi.URLParam(req, "abc")` compared to `c.Param("abc")` in Gin, and Gin's parameters are much cheaper for a middleware to tweak. (I choose chi here because it's one I'm familiar with that tries hard to keep the standard Handler signature at the expense of interfaces to its own features.) A lot of problems would go away if the standard signature was `func (Context, ResponseWriter, Request) error`. Sometimes a minimal universal option is nice because minimalism is also a virtue; but also sometimes it's just missing necessary features.
nickjj 6y ago
> To those who say frameworks are needed because the stdlib is not enough: No, the stdlib defines very clear interfaces that libraries can implement. Yeah, I'm not much into Go development but I've talked to a few devs who built real web apps with it and they rarely use any libraries, but do use "interface style" libs like Gorilla Mux. Here's a snippet from my podcast where I talked to Jon Calhoun on using mostly the standard library and about 15k lines of code to build a video course platform in Go: https://runninginproduction.com/podcast/42-creating-a-video-course-hosting-platform-to-learn-go#19:54 https://runninginproduction.com/podcast/42-creating-a-video-...
- morelisp 6y ago
  > they rarely use any libraries... He mentioned some of the Gorilla packages that he used too, such as Mux for routing. Gorilla is perhaps the most maximalist Go web library "system", and its mux is by far the most complex of common routers. Using Gorilla for a site is about as far as being outside the Go stdlib as you can be before reimplementing core protocol handling.
sjroot 6y ago
Came in here to say this. I helped many teams move from Java to Go, and came across this so many times. Everyone wanted to find the Spring equivalent for Go (or Django, Ruby on Rails, etc) when it doesn’t actually exist. That’s by design. No ill feelings toward the developers of Echo, or other similar frameworks (Go Micro specifically). However, touting their framework as the way to build APIs in Go is disingenuous and leads to software that is difficult to maintain. Just my two cents.
- coldtea 6y ago
  >I helped many teams move from Java to Go, and came across this so many times. Everyone wanted to find the Spring equivalent for Go (or Django, Ruby on Rails, etc) when it doesn’t actually exist. That’s by design. I'm not sure how it's "by design". Go, by itself, doesn't give much more than e.g. Java gives with its Servlet base libs, etc. And yet Java has Spring, and some popular framework could very well emerge as the "THE" framework for Go. Whether that framework would conform to the stdlib interfaces / middleware is another question. It might not, if it's compelling enough (there are lots of popular Java non-servlet API conforming frameworks, e.g. Play, Vert.x, etc). It's only because of fragmentation (and small still market, with lots of NIH) that one hasn't emerged as such, not some special Go design. Many/most Go-ers like to keep it simple, so they don't adopt any big framework lib (after all, if they didn't keep it simple, they wouldn't be using Go).
- jeffnappi 6y ago
  I think it's only a matter of time before there's a solid choice full featured Go web framework that rivals Rails/Django.
  - teleforce 6y ago
    I might be wrong but it seems that Go needs to have a proper generic support for that ever to happen and that's one of the main reasons why there is no equivalent of RoR in the C world. For a very good perspective on this check out this excellent article by the creator of Stanza language responding to his friend's request of not creating any more new languages but just libraries: https://jaxenter.com/stop-designing-languages-write-libraries-instead-126738.html https://jaxenter.com/stop-designing-languages-write-librarie...

by SPBS 6y ago

mmgutz 6y ago

A much needed interface in stdlib is logging.

johnisgood 6y ago
Yeah I made a library for that. I am not sure if people are actually using it but it got over 70k goddamn hits in my access.log!

cdent 6y ago

Agree. I wasn't at all convinced by the examples showing the Echo was somehow better than using the "built in" signatures, especially since there's quite a bit of handling that Echo (and things like it) makes implicit that you'll probably want to be explicit in some edge case. Coming from WSGI, I found go's middlwares familiar and positively pleasant. I too ended up on Chi as the router that worked well without getting in the way.

morelisp 6y ago

> Frameworks like Echo and Gin eschew the universal middleware signature `func (http.Handler) http.Handler` for their custom built ones, and as a result cannot tap into the ecosystem of middlewares that target Go's net/http. Between a stdlib package and a third party package, which do you think is more stable? I think you're overstating the cost of using "proprietary" middlewares. I'm most familiar with Gin; it is trivial to wrap a "universal" middleware in a Gin middleware (gin.WrapH). It is not trivial to make a universal middleware that does the equivalent of gin.Context#AbortWithError. I don't fully disagree either - obviously `gin.WrapH` everywhere is noise, but so is e.g. `chi.URLParam(req, "abc")` compared to `c.Param("abc")` in Gin, and Gin's parameters are much cheaper for a middleware to tweak. (I choose chi here because it's one I'm familiar with that tries hard to keep the standard Handler signature at the expense of interfaces to its own features.) A lot of problems would go away if the standard signature was `func (Context, ResponseWriter, Request) error`. Sometimes a minimal universal option is nice because minimalism is also a virtue; but also sometimes it's just missing necessary features.

nickjj 6y ago

> To those who say frameworks are needed because the stdlib is not enough: No, the stdlib defines very clear interfaces that libraries can implement. Yeah, I'm not much into Go development but I've talked to a few devs who built real web apps with it and they rarely use any libraries, but do use "interface style" libs like Gorilla Mux. Here's a snippet from my podcast where I talked to Jon Calhoun on using mostly the standard library and about 15k lines of code to build a video course platform in Go: https://runninginproduction.com/podcast/42-creating-a-video-course-hosting-platform-to-learn-go#19:54 https://runninginproduction.com/podcast/42-creating-a-video-...

morelisp 6y ago
> they rarely use any libraries... He mentioned some of the Gorilla packages that he used too, such as Mux for routing. Gorilla is perhaps the most maximalist Go web library "system", and its mux is by far the most complex of common routers. Using Gorilla for a site is about as far as being outside the Go stdlib as you can be before reimplementing core protocol handling.

sjroot 6y ago

Came in here to say this. I helped many teams move from Java to Go, and came across this so many times. Everyone wanted to find the Spring equivalent for Go (or Django, Ruby on Rails, etc) when it doesn’t actually exist. That’s by design. No ill feelings toward the developers of Echo, or other similar frameworks (Go Micro specifically). However, touting their framework as the way to build APIs in Go is disingenuous and leads to software that is difficult to maintain. Just my two cents.

coldtea 6y ago
>I helped many teams move from Java to Go, and came across this so many times. Everyone wanted to find the Spring equivalent for Go (or Django, Ruby on Rails, etc) when it doesn’t actually exist. That’s by design. I'm not sure how it's "by design". Go, by itself, doesn't give much more than e.g. Java gives with its Servlet base libs, etc. And yet Java has Spring, and some popular framework could very well emerge as the "THE" framework for Go. Whether that framework would conform to the stdlib interfaces / middleware is another question. It might not, if it's compelling enough (there are lots of popular Java non-servlet API conforming frameworks, e.g. Play, Vert.x, etc). It's only because of fragmentation (and small still market, with lots of NIH) that one hasn't emerged as such, not some special Go design. Many/most Go-ers like to keep it simple, so they don't adopt any big framework lib (after all, if they didn't keep it simple, they wouldn't be using Go).
jeffnappi 6y ago
I think it's only a matter of time before there's a solid choice full featured Go web framework that rivals Rails/Django.
- teleforce 6y ago
  I might be wrong but it seems that Go needs to have a proper generic support for that ever to happen and that's one of the main reasons why there is no equivalent of RoR in the C world. For a very good perspective on this check out this excellent article by the creator of Stanza language responding to his friend's request of not creating any more new languages but just libraries: https://jaxenter.com/stop-designing-languages-write-libraries-instead-126738.html https://jaxenter.com/stop-designing-languages-write-librarie...