There are, but Go's type system doesn't really accommodate them very well. `interface{}` tends to abound, and it tends to feel less magical because you're still generally wiring things up yourself (i.e. you still have to explicitly unmarshal the request JSON).

In some ways, that explicitness is better because you know what's happening. In other ways, I'm incredibly tired of typing out 'if err := req.Bind(myStruct); err != nil { return err }'.

> But...you are comparing a web framework with a Go's standard library. I mean, it's not a fair comparison.

Why do you feel that the comparison isn't fair? Aren't we talking about modules that provide the features necessary to implement a type of application? Would it make any difference if tomorrow there was a PEP making Flask a standard component?

Unless you are aware of any Go module that addresses the downsides of Go with regards to Python, your observation is mute and unhelpful.

doesn't go stdlib contain an http server library "that you are supposed to use in prod"?

It does. It's rock solid and most people use it in production. But the parent is more concerned about quick and handy functions. IMHO, such functionality is usually part of third-party libraries and is certainly an option in Go. It's just idiomatic Go favors KISS principles, less external dependancies and a more self-contained software. The benefit is that pretty much all the Go source code is more-or-less identical, regardless of an author. It makes it super simple to understand and deep dive into a random complex piece of software.

Go is not about abstractions, Go is about solving problems here and now.